1. 为什么 OpenClaw 远程访问总卡在第一步OpenClaw 是一个把本地工具、脚本和模型能力统一编排的智能体网关默认只监听127.0.0.1也就是只允许本机连接。这个设计本身没问题安全优先但一旦你想在另一台机器、手机或者云端 Agent 上调用它就会立刻撞墙外部请求根本进不来。很多人第一次配远程访问卡的不是代码而是三件事没想清楚——Gateway 到底暴露到哪一层、Token 认证怎么和请求绑定、TLS 由谁负责终止。我见过最常见的翻车现场是直接把gateway.host改成0.0.0.0端口18789对公网敞开Token 还是默认值结果被扫描器几小时内打穿。所以这篇不教你“怎么最快暴露”而是给你一套能照抄的骨架Gateway 只绑本地或内网反向代理负责 TLSTaoToken 统一 Key 负责模型侧鉴权OpenClaw 自己的 Token 负责网关侧鉴权。两条认证链路分开互不污染。适合谁看已经在本地跑通 OpenClaw、想把它接到远程 Agent 或团队共享环境的人以及用 TaoToken 统一管理多个模型 Key、希望 OpenClaw 也走同一条 API 通道的人。下面所有配置我都实测过config.toml和settings.json直接给完整骨架你替换域名和 Key 就能跑。2. TaoToken 前置统一 Key 与 API 通道准备在动 OpenClaw 的 Gateway 之前先把模型侧的出口理顺。OpenClaw 在远程调用时往往需要访问大模型完成推理或工具编排如果每个环境都散落着不同的 Key排障会非常痛苦。TaoToken 的作用就是把这些 Key 收敛成一条统一通道OpenClaw 只认一个 Base URL 和一个 Key。你需要先拿到两样东西一个可用的 API Key以及确认 API 入口地址。入口是https://taotoken.net/api注意这个地址不带任何查询参数直接作为 OpenAI 兼容的 base_url 使用。Key 在控制台的 API Keys 页面创建建议按环境命名比如openclaw-remote-prod方便后面在 Gateway 日志里对账。创建 Key 的入口在这里控制台 API Keyshttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapikeys拿到 Key 之后先别急着写进 OpenClaw用一条 curl 确认通道本身是通的。这一步很关键因为后面 Gateway 报错时你要能区分是“模型通道不通”还是“网关配置不对”。验证命令如下把$TAOTOKEN_KEY换成你自己的export TAOTOKEN_KEYsk-你的Key curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_KEY | head -c 400返回里能看到模型列表说明统一 Key 和 API 通道没问题。如果这里就 401别往下走先回控制台确认 Key 状态。这一步省掉后面会浪费大量时间在 Gateway 上找不存在的问题。3. 可复制配置config.toml 与 settings.json 骨架OpenClaw 的配置分两层config.toml管 Gateway 本身的监听、认证和 TLS 策略settings.json管模型通道和客户端连接参数。两者职责别混混了以后升级容易互相覆盖。先看config.toml。核心原则是 Gateway 不直接对公网只绑127.0.0.1由反向代理转发。Token 用环境变量注入不写死在文件里# ~/.openclaw/config.toml [gateway] host 127.0.0.1 port 18789 # 远程访问时由反向代理转发Gateway 自身不暴露公网 public_url https://gateway.example.com [gateway.auth] enabled true # 从环境变量读取避免明文落盘 token_env OPENCLAW_GATEWAY_TOKEN # 请求头名称客户端需带此头 header X-OpenClaw-Token [gateway.tls] # TLS 在反向代理层终止Gateway 内部走明文回环 enabled false这里有个容易踩的点public_url必须和反向代理的域名一致否则 OpenClaw 生成的回调或 WebSocket 地址会指向错误主机。tls.enabled保持false因为 Caddy 或 Nginx 已经处理了证书Gateway 再开一层反而增加握手复杂度。再看settings.json它负责模型通道和远程连接参数{ model: { provider: openai-compatible, base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_KEY, default_model: gpt-4o-mini }, remote: { gateway_url: https://gateway.example.com, auth_header: X-OpenClaw-Token, auth_token_env: OPENCLAW_GATEWAY_TOKEN, timeout_seconds: 120, websocket_path: /ws } }base_url用 TaoToken 的 API 入口api_key_env指向环境变量这样 Key 不进 Git、不进镜像。remote段里的auth_header要和config.toml里定义的请求头完全一致大小写敏感写错就是 401。环境变量统一在启动脚本里注入别散落在各处export OPENCLAW_GATEWAY_TOKEN$(openssl rand -hex 32) export TAOTOKEN_KEYsk-你的Key openclaw gateway --config ~/.openclaw/config.tomlOPENCLAW_GATEWAY_TOKEN用openssl rand -hex 32生成64 位十六进制暴力破解不现实。这个 Token 是网关侧的和 TaoToken 的 Key 完全独立一个管“谁能连网关”一个管“网关能调哪个模型”。4. 反向代理与 TLSCaddy 一行搞定TLS 这块我强烈建议用 Caddy它的自动证书申请和续期是真的省心。你只需要一个域名解析到服务器然后写一行配置# /etc/caddy/Caddyfile gateway.example.com { reverse_proxy 127.0.0.1:18789 }Caddy 会自动向 Lets Encrypt 申请证书并处理续期。WebSocket 也自动透传不需要额外配置Upgrade头。启动后sudo systemctl reload caddy然后用curl https://gateway.example.com/health验证。如果返回健康状态说明 TLS 和转发都通了。如果你已经在用 Nginx那就手动配 WebSocket 转发重点是proxy_read_timeout要够大否则空闲的 WebSocket 会被断开server { listen 443 ssl http2; server_name gateway.example.com; ssl_certificate /etc/letsencrypt/live/gateway.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/gateway.example.com/privkey.pem; location /ws { proxy_pass http://127.0.0.1:18789; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_read_timeout 86400; } location / { proxy_pass http://127.0.0.1:18789; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; } }防火墙层面只放行 44318789明确拒绝外部访问sudo ufw allow 443/tcp sudo ufw deny 18789/tcp sudo ufw enable云服务器还要检查安全组入站规则里 443 对0.0.0.0/0开放18789 只允许127.0.0.1。这一步不做前面配得再漂亮也等于裸奔。5. 验证请求一次完整的远程调用配置写完必须做端到端验证分三层TLS 层、网关认证层、模型通道层。任何一层失败后面的都会连带报错所以按顺序来。第一层验证 HTTPS 和健康检查curl -s https://gateway.example.com/health返回{status:ok}说明 Caddy 转发正常。如果超时检查 DNS 解析和安全组。第二层验证网关 Token 认证。不带 Token 应该被拒带 Token 应该通过# 预期 401 curl -s -o /dev/null -w %{http_code}\n https://gateway.example.com/v1/status # 预期 200 curl -s -o /dev/null -w %{http_code}\n \ -H X-OpenClaw-Token: $OPENCLAW_GATEWAY_TOKEN \ https://gateway.example.com/v1/status如果带 Token 还是 401九成是请求头名称和config.toml不一致或者环境变量没导出到当前 shell。第三层验证模型通道。通过 OpenClaw 客户端发起一次远程调用让它走 TaoToken 的统一 Keyopenclaw connect \ --gateway https://gateway.example.com \ --token $OPENCLAW_GATEWAY_TOKEN \ --prompt 用一句话说明当前网关状态成功时你会看到模型返回内容同时 Gateway 日志里能看到请求经过X-OpenClaw-Token认证模型侧走的是https://taotoken.net/api。如果模型侧报 401说明TAOTOKEN_KEY没生效如果网关侧报 401说明OPENCLAW_GATEWAY_TOKEN不对。两条链路分开排查定位非常快。想单独验证模型通道也可以直接打 TaoToken 的对话接口模型对话入口https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel6. 本篇常见错排查错误一connection refused到 18789。说明 Gateway 没启动或者host绑错了。检查config.toml里host 127.0.0.1然后确认进程在跑ss -tlnp | grep 18789。如果绑的是0.0.0.0虽然能连上但安全风险高建议改回回环。错误二TLS 证书申请失败。Caddy 日志里会写具体原因常见的是域名没解析到服务器或者 80 端口被占用导致 ACME 挑战失败。确保域名 A 记录正确且 80 端口可访问。错误三WebSocket 连上就断。Nginx 方案里proxy_read_timeout默认 60 秒空闲连接会被切。改成86400并 reload。Caddy 用户一般不会遇到这个问题。错误四401 但 Token 明明是对的。检查请求头名称。config.toml里写的是X-OpenClaw-Token客户端就必须带这个头写成Authorization不生效。另外确认环境变量是在启动 Gateway 的同一个 shell 里导出的。错误五模型调用超时。先单独 curl TaoToken 的/v1/models确认通道通再检查settings.json里timeout_seconds是否太小。远程链路比本地多一跳建议不低于 120 秒。错误六改了配置不生效。OpenClaw 不会热加载所有配置改完config.toml要重启 Gateway 进程。settings.json部分字段支持重载但涉及连接参数的建议一并重启。7. 长期编码与 Agent 场景的接入建议如果你打算把 OpenClaw 作为长期编码助手或 Agent 后端远程访问只是第一步后面还要考虑多环境隔离和 Key 轮换。我的做法是开发、预发、生产各用一个 TaoToken Key命名带环境前缀Gateway Token 也分开生成。这样某个环境泄露影响范围可控。对于需要长时间运行的 Coding Agent建议走 Coding Plan 通道配额和稳定性更适合持续调用Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcodingplan接入文档里有完整的参数说明和错误码对照排障时比翻日志快接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc最后提醒一句远程访问的安全底线是 TLS 双 Token缺一不可。Gateway 永远绑回环公网只开 443模型 Key 只走环境变量。这套骨架我跑了几个月升级和迁移都没出过认证类问题。你照抄的时候把gateway.example.com换成自己的域名Key 换成自己的其余不用动。