本文分享我在部署OpenClaw面板时，如何通过mTLS（双向认证）和Nginx构建企业级零信任安全网关的实战经验，从证书生成到服务器配置的完整解决方案。

1. 引言

OpenClow 正以前所未有的速度席卷 AI 应用领域。作为新一代自主智能体运行环境，它让开发者能够快速构建可调用工具、访问数据库甚至与第三方 API 交互的“数字员工”。一时间，社区里掀起了“养虾”热潮——无数人像培育电子宠物一样部署着自己的 OpenClow 实例，用智能体替代繁琐的人工操作或是打造自己的 AI 女友。一些前沿团队甚至高调宣称：我们不再招聘人类员工，只招募数字员工。然而，当这股热潮从实验台涌向生产环境时，一场隐形的安全风暴也在悄然酝酿。

2. 安全挑战：为什么需要mTLS？

近日，一个名为“OpenClaw Exposure Watchboard”的公开监控页面揭开了这层繁荣下的隐患：超过 22 万个 OpenClaw 实例毫无防护地暴露在公网上，遍布美国、新加坡、中国大陆等地，托管在腾讯、阿里、华为、甲骨文等主流云平台。更触目惊心的是，大量实例的“Auth Required”字段为空——意味着它们连最基本的访问认证都没有开启；而“Has Leaked Creds”一栏中，不少被标记为“Leaked”，表明可能已有明文凭证或 API Key 泄露。

在这里插入图片描述

OpenClaw 并非普通 Web 服务，作为自主智能体的运行环境，它天然具备调用外部工具、操作数据库、执行代码以及与第三方 API 交互的能力。更有甚者，为图省事直接将其部署在物理机上，关闭沙盒限制，甚至赋予 root 权限。一旦未经鉴权的实例暴露在公网，攻击者便能轻松接管这些“数字员工”，进而渗透内部系统、窃取敏感数据，甚至反向操控业务后端。

监控页面的数据揭示了一个残酷的现实：智能体部署量正爆炸式增长，安全治理却严重滞后。尤其在当下，各类教程和直播将OpenClaw吹捧为“风口”，吸引大量普通用户跟风部署，他们缺乏安全经验，贪图方便，直接开放公网端口、忽略鉴权，让Agent在互联网上“裸奔”。

面对这一安全缺口，我们急需为 OpenClaw 部署穿上“防弹衣”。本文将基于零信任理念，以 mTLS（双向 TLS 认证）为核心，手把手带你打造一个安全可靠的 OpenClaw 网关，让数字员工在公网上也能安全履职。

3. 为什么选择mTLS？

OpenClaw 功能强大，虽然官方已经提供了访问控制和鉴权机制，但在网络层面，仍然存在被暴力破解、凭证泄露等风险。默认的WebUI端口18789如果直接开放在公网，攻击者可以轻易扫描到这个端口，尝试各种攻击手段，如暴力破解、利用已泄露的凭证进行入侵等。因此，官方明确不建议用户监听0.0.0.0并直接暴露在公网。

那如果想要鱼与熊掌兼得，安全地暴露 OpenClaw，最有效的方式就是在其前面部署一个安全网关，利用 mTLS 实现双向认证。

mTLS（Mutual TLS）是一种基于 TLS 协议的双向认证机制，不仅服务器需要提供证书证明身份，客户端也必须提供有效证书才能建立连接。这种机制为 OpenClaw 提供了一个强有力的安全屏障：没有合法证书的设备，连建立连接的机会都没有。这种零信任架构特别适合需要暴露在公网但又包含敏感操作的服务。

4. 生成自签证书体系

与 SSL/TLS 证书类似，我们可以使用 OpenSSL 来生成这些证书。不同的是 mTLS 证书自签是完全没有问题的，不像 HTTPS 证书需要被浏览器信任。

我们使用OpenSSL构建一套单层（1-Tier）的私有证书体系，即自己创建根证书（Root CA），然后直接用它签发客户端证书。

4.1 生成根证书（Root CA）

根证书是整个信任体系的基石，我们生成一个有效期10年的根证书：

# 生成根证书私钥 (ca.key) 和 公钥 (ca.crt)
openssl req -x509 -newkey rsa:4096 -days 3650 -nodes -keyout ca.key -out ca.crt -subj "/CN=ClawGuard_Root_CA"

4.2 生成客户端证书

接下来为每个需要访问的设备生成客户端证书：

# 生成客户端私钥和证书签名请求
openssl req -newkey rsa:2048 -nodes -keyout client.key -out client.csr -subj "/CN=Claw_Admin_Device"

# 使用根证书签发客户端证书
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 -out client.crt

4.3 导出为可用的格式

将客户端证书打包成.pfx格式，方便导入到各种设备：

# 打包客户端证书与私钥
openssl pkcs12 -export -out claw_client.pfx -inkey client.key -in client.crt -certfile ca.crt

执行时会要求设置导出密码，这个密码在导入设备时需要用到。

4.4 实际部署中的注意事项

在生成证书时，有个值得注意的问题：

如果你已经有了自己的证书架构，并且环境更复杂，使用了子CA（Sub CA）来签发客户端证书，配置 Nginx 时需要将 Sub CA 和 Root CA 拼接：cat subca.crt ca.crt > full_chain.pem，并将ssl_verify_depth设置为2。

5. 配置Nginx零信任网关

有了证书体系，接下来配置Nginx作为安全网关。针对OpenClaw需要WebSocket长连接的特性，我优化了配置：

# OpenClaw零信任安全网关配置
server {
    listen       443 ssl http2;
    listen       [::]:443 ssl http2;
    server_name  claw.yourdomain.com;

    # 常规HTTPS证书
    ssl_certificate      ../ssl/web.pem;
    ssl_certificate_key  ../ssl/web.key;
    ssl_protocols        TLSv1.2 TLSv1.3;

    # 核心：开启mTLS客户端双向认证
    ssl_verify_client on;
    ssl_client_certificate ../ssl/ca.crt;
    ssl_verify_depth 1;

    # 优雅拦截未提供证书的请求
    error_page 496 = @no_cert;
    location @no_cert {
        default_type text/html;
        return 403 '<!doctype html><html><head><title>Access Denied</title></head><body style="background:#121212; color:#00E676; display:flex; height:100vh; justify-content:center; align-items:center; margin:0; font-family:monospace;"><div style="border:1px solid #00E676; border-radius:8px; padding:20px; white-space:nowrap;"><h1>403 Forbidden</h1><p>Valid Client Certificate Required</p></div></body></html>';
    }

    # 反向代理到OpenClaw
    location / {
        proxy_pass   http://127.0.0.1:18789;
        
        # WebSocket支持
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        
        # 传递客户端信息
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # 长连接超时设置
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

配置完成后，执行nginx -s reload重载服务。此时浏览器访问，会看到403 Forbidden: Valid Client Certificate Required的提示。

只有安装了正确客户端证书的设备，才能成功连接到OpenClaw。这就实现了真正意义上的零信任访问控制。

6. OpenClaw 配置

在配置Nginx的mTLS防护之前，需要确保OpenClaw本身的安全部署。在我的实际部署中，OpenClaw运行在本地Ubuntu主机上，通过FastTunnel进行反向代理：

公网用户 → 云服务器(FastTunnel) → 本地Ubuntu(OpenClaw)

如果直接在云服务器上部署OpenClaw，可以省略FastTunnel这一步骤。

在OpenClaw的配置文件中，有几个关键设置：

{
  "gateway": {
    "trustedProxies": ["xxx.xxx.xxx.xxx"]  // 反向代理服务器IP，如果使用
  },
  "controlUi": {
    "allowedOrigins": ["https://claw.yourdomain.com"]  // 只允许特定域名
  },
  "auth": {
    "mode": "password"  // 使用密码认证
  }
}
  • trustedProxies：确保请求来源可信
  • allowedOrigins：防止跨站请求
  • auth.mode：建议使用password模式，设置自己可以记住的复杂密码，并定期更换

密码建议使用 OPENCLAW_GATEWAY_PASSWORD 环境变量设置，确保不在配置文件中明文存储。

7. 访问测试

完成上述配置后，我们的防线已经构建完成。要想访问我们还需要进行以下操作。

7.1 导入客户端证书

在 Windows 上，可以通过双击.pfx文件导入证书，直接下一步输入密码就可以了。

在这里插入图片描述

导入完成后，在浏览器访问https://claw.yourdomain.com，会弹出选择证书的窗口，选择刚才导入的客户端证书即可成功连接。

在这里插入图片描述

如果访问成功，说明我们的mTLS配置已经生效，只有持有合法证书的设备才能访问OpenClaw。

8. 最后

这套mTLS+Nginx的方案虽然配置稍显复杂，但提供了企业级的安全保障。在PC端，只需将.pfx证书导入系统即可访问；但在移动端，可能会遇到一些挑战，我试了多款浏览器，均不支持直接使用客户端证书进行mTLS认证。

在下一篇文章中，我将分享如何使用.NET MAUI开发一个内置mTLS支持的"安全套壳浏览器"，解决移动端证书管理的痛点，实现一次配置、终身无感的安全访问。敬请期待！

# 安全 # 数据库
Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

DeerFlow环境配置：Docker内Python 3.12+与Node.js 22+共存方案

本文介绍了如何在星图GPU平台上自动化部署DeerFlow镜像，该镜像集成了Python 3.12+与Node.js 22+环境，为深度研究AI助手DeerFlow提供稳定运行基础。通过该方案，用户可快速搭建一个支持多智能体工作流与Web交互界面的AI应用环境，适用于自动化研究、数据分析与报告生成等场景。

avatar 龙虾开发者社区

Qwen3-0.6B-FP8部署教程：Intel优化FP8模型CPU/核显纯本地推理完整步骤

本文介绍了如何在星图GPU平台上自动化部署⚡ Qwen3-0.6B-FP8极速对话工具镜像，实现轻量级AI对话助手的快速搭建。该镜像基于Intel优化的FP8量化技术，可在CPU或核显上纯本地运行，适用于构建无需联网、保护隐私的智能对话应用，如个人知识问答、创意写作辅助等场景。

avatar 龙虾开发者社区

Neeshck-Z-lmage_LYX_v2开发者指南：LoRA自动扫描与热加载机制解析

本文介绍了如何在星图GPU平台上自动化部署Neeshck-Z-lmage_LYX_v2镜像，该镜像是一个基于Z-Image模型的轻量化AI绘画工具。其核心亮点在于实现了LoRA权重文件的自动扫描与热加载机制，用户只需将风格文件放入指定文件夹，即可在Web界面实时切换并应用于图片生成，无需重启程序，极大提升了创作灵活性。

avatar 龙虾开发者社区