1. OpenClaw 公网访问为什么卡在设备身份校验
OpenClaw 的 Control UI 默认走的是「本机可信」模型：浏览器和服务跑在同一台机器上，网关认为设备身份天然可信，所以本地http://127.0.0.1:18789打开一切正常。可一旦你把端口映射到公网，用http://你的IP:18789或http://你的域名:18789去访问，页面要么白屏、要么控制台报错、要么直接弹出control ui requires device identity，登录框都出不来。
这个报错的核心含义是：网关在握手阶段要求浏览器提供一个「设备身份凭证」，而公网访问场景下这个凭证拿不到或者校验不通过。它和 Token 认证是两套东西——Token 管的是「你有没有权限登录」，设备身份管的是「你这个设备是不是被信任的」。很多人配好了 Token 却依然进不去，就是卡在后者。
触发条件其实就那么几类。第一类是绑定地址问题，gateway.bind还停留在localhost，公网请求根本到不了网关，或者到了但被判定为非本地来源。第二类是来源校验，allowedOrigins没把你的域名或 IP 加进去，浏览器发起的跨域请求被拦。第三类就是设备身份校验本身，Control UI 在非安全上下文（HTTP 而非 HTTPS）下无法完成设备指纹的建立，于是直接拒绝。
我试过在纯 HTTP 公网环境下折腾半天，最后发现不是 Token 写错了，而是设备身份这一关卡死了。理解这条链路之后，解决思路就清晰了：要么补齐 HTTPS 让设备身份能正常建立，要么在受控前提下显式关闭设备身份校验。前者是生产推荐，后者是快速验证和临时使用的捷径。下面先把 TaoToken 这个前置环节说清楚，因为无论你走哪条路，模型调用这一层都得先通。
2. TaoToken 前置准备：把模型调用链路先打通
在动 OpenClaw 网关配置之前，建议先把模型调用这一层独立验证通过。原因很简单：如果模型侧本身就不通，你会在网关报错和模型报错之间反复横跳，排查成本翻倍。TaoToken 在这里扮演的是统一模型接入层的角色，它提供兼容 OpenAI 风格的接口，OpenClaw 的chatCompletions端点可以直接对接。
你需要准备三样东西：Base URL、API Key、Model ID。Base URL 用https://taotoken.net/api，注意这个地址不带任何查询参数。API Key 到控制台创建，路径是 API Keys 页面，创建后复制保存，它只显示一次。Model ID 按你实际要用的模型填，比如常见的对话模型标识。
创建 Key 的入口在这里：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 。登录后点新建，给它起个能认出来的名字，比如openclaw-gateway，方便以后按用途吊销。生成后立刻复制，页面刷新就看不到了。
拿到三件套之后，先别急着往 OpenClaw 里塞，用一条 curl 命令独立验证模型侧是否通：
curl https://taotoken.net/api/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 你的APIKey" \ -d '{ "model": "你的ModelID", "messages": [ {"role": "user", "content": "只回复两个字：通了"} ] }'如果返回的 JSON 里choices[0].message.content是「通了」，说明 Base URL、Key、Model ID 三件套没问题，可以进入网关配置环节。如果这里就报 401，那先解决 Key 的问题，别往下走。这一步的意义在于把变量隔离——模型侧确认无误后，后面所有报错都只可能出在 OpenClaw 网关本身。
顺便说一句，如果你打算长期跑编码类或 Agent 类任务，可以了解下 Coding Plan，它在高频调用场景下比按量计费更划算，入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。不过这只是可选优化，不影响本篇的报错修复。
3. 可复制配置：openclaw.json 关键片段与命令行改法
OpenClaw 的配置有两个改法：命令行openclaw config set和直接编辑~/.openclaw/openclaw.json。命令行适合快速改单项，配置文件适合一次性看全貌。我建议先用命令行把关键项改掉，再打开配置文件核对，避免手抖写错 JSON 结构。
先看命令行方式，三条命令依次执行：
# 1. 允许非安全认证，解决 HTTP 场景下的跨域与握手问题 openclaw config set gateway.controlUi.allowInsecureAuth true # 2. 关键步骤：关闭设备身份校验，让 HTTP 公网访问可以通过 openclaw config set gateway.controlUi.dangerouslyDisableDeviceAuth true # 3. 重启网关服务使配置生效 openclaw gateway restart执行完第三条后，网关会重新加载配置。注意dangerouslyDisableDeviceAuth这个名字里的dangerously不是吓唬人，它确实会削弱一层防护，所以只建议在受控网络或临时验证时用，生产环境请走后面的 HTTPS 方案。
如果你更习惯直接编辑配置文件，打开~/.openclaw/openclaw.json，找到gateway节点，对照下面这段结构核对。路径和字段名要和原文一致，别自己造字段：
{ "gateway": { "port": 18789, "bind": "lan", "controlUi": { "allowInsecureAuth": true, "dangerouslyDisableDeviceAuth": true, "allowedOrigins": [ "http://你的域名或IP:18789" ] }, "auth": { "mode": "token", "token": "你的复杂Token" }, "http": { "endpoints": { "chatCompletions": { "enabled": true } } } } }几个字段要重点确认。bind设成lan或0.0.0.0，只写localhost的话公网请求进不来。allowedOrigins里必须包含你实际访问用的完整来源，带协议带端口，比如http://1.2.3.4:18789或http://your.domain:18789，少一个字符都可能被拦。auth.mode保持token，token填你自己生成的复杂字符串，别用弱口令。
改完配置文件同样要openclaw gateway restart。这里有个容易忽略的点：命令行改和手动改如果冲突，以最后一次写入为准，所以别两边同时改同一个字段。改完建议cat ~/.openclaw/openclaw.json看一眼最终落盘的内容，确认 JSON 没有语法错误——多一个逗号都会导致网关启动失败。
4. 验证请求：从 curl 到浏览器逐步确认成功
配置改完不代表就通了，得一步步验证。验证顺序建议从内到外：先本机 curl，再本机浏览器，最后公网浏览器。这样任何一步失败，你都能立刻知道问题出在哪一层。
第一步，本机验证网关是否正常监听：
curl -i http://127.0.0.1:18789/如果返回 200 或 302，说明网关进程活着。如果连接被拒，检查openclaw gateway restart是否真的成功，用ps aux | grep openclaw看进程在不在。
第二步，本机带 Token 验证 chatCompletions 端点：
curl https://taotoken.net/api/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 你的APIKey" \ -d '{ "model": "你的ModelID", "messages": [{"role": "user", "content": "ping"}] }'这一步其实在第二节已经做过，这里再跑一次是为了确认网关重启没有影响模型侧配置。返回正常内容就说明http.endpoints.chatCompletions.enabled生效了。
第三步，公网浏览器访问http://你的IP:18789或http://你的域名:18789。如果之前报control ui requires device identity，现在应该能看到登录界面。输入你的 Token 登录，进入 Control UI。如果还是白屏，打开浏览器开发者工具的 Console 和 Network 面板，看具体是哪个请求失败、返回什么状态码。
第四步，登录后在 UI 里发一条测试消息，确认模型调用链路端到端打通。这一步成功，说明网关、认证、模型三层全部就绪。整个验证过程的关键是「分层隔离」——每一层单独确认，不要跳步。很多人一上来就直接公网访问，失败了不知道是网关没起、Token 错了还是设备校验拦了，只能瞎猜。
5. 常见报错排查：401、local proxy failed 与 OAuth 类问题
即使按上面配完，实际环境里还是会撞到各种报错。这里按真实遇到的频率排一下，对照着查。
401 Unauthorized：最常见。先确认请求头里Authorization: Bearer 你的APIKey格式对不对，Bearer 后面有一个空格。再确认 Key 有没有过期或被吊销，去控制台 API Keys 页面核对。如果 curl 本机通、公网不通，那多半是网关的auth.token和你在 UI 里输入的 Token 不一致，重新核对openclaw.json里的auth.token字段。
local proxy failed：这个通常出现在网关尝试转发请求到模型端点时。检查chatCompletions的 Base URL 是否指向https://taotoken.net/api，注意结尾不要多加斜杠或路径。另外确认服务器出网正常，curl -I https://taotoken.net/api能通。如果服务器在受限网络里，出网被拦也会报这个。
reading choices 相关报错：一般是模型返回结构不符合预期，或者 Model ID 填错了导致返回了错误对象。回到第二节的 curl 命令，用同样的 Model ID 独立测一次，确认返回里有choices数组。如果 curl 正常但网关报这个错，检查 OpenClaw 的模型配置字段有没有拼写错误。
OAuth 类报错：如果你用的是需要 OAuth 流程的接入方式，注意 OpenClaw 的auth.mode要设成对应模式，Token 模式不涉及 OAuth。出现 OAuth 报错通常是模式选错了，或者回调地址没配对。这种场景下建议先切回token模式验证基础链路，再单独调 OAuth。
设备身份报错反复出现：确认dangerouslyDisableDeviceAuth真的写进去了，用openclaw config get gateway.controlUi.dangerouslyDisableDeviceAuth查一下当前值。如果返回false，说明没生效，可能是配置文件被覆盖或者重启没成功。另外allowInsecureAuth也要同时为true，两个是配套的。
排查时有个通用技巧：把网关日志打开，openclaw gateway logs或看对应日志文件，报错发生的时间点附近通常有更详细的堆栈。浏览器侧则看 Network 面板里失败请求的 Response Body，往往比页面上的提示信息更有用。
6. 生产环境怎么收尾：HTTPS 与访问控制
快速验证用dangerouslyDisableDeviceAuth没问题，但生产环境不能这么裸奔。设备身份校验被关掉之后，任何拿到 Token 的人都能从任意设备登录，风险是实打实的。正确的收尾方式是补上 HTTPS，让设备身份校验能正常工作，然后把那个危险开关关回去。
推荐用 Nginx 反向代理加 Let's Encrypt 免费证书。Nginx 监听 443，把请求转发到本机127.0.0.1:18789，OpenClaw 的bind可以改回localhost，不直接暴露端口。证书用 certbot 申请，自动续期。这样浏览器访问的是https://你的域名，安全上下文成立，设备身份校验能正常建立，dangerouslyDisableDeviceAuth就可以设回false：
openclaw config set gateway.controlUi.dangerouslyDisableDeviceAuth false openclaw gateway restart同时把allowedOrigins改成你的 HTTPS 域名，比如https://your.domain。再配一层 IP 白名单，只允许可信来源访问，进一步收窄暴露面。Token 依然要保留，它是登录凭证，和设备身份是两道独立的门。
如果你在配置过程中需要查更细的字段说明，接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有完整的参数列表。想先在网页里验证模型对话是否正常，可以用模型对话入口 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=chat&utm_campaign=rewrite 快速试一条。长期跑编码和 Agent 任务的话，Coding Plan 的入口前面给过了，按需取用。
最后提醒一句：dangerouslyDisableDeviceAuth这个开关的设计意图就是「临时、受控、尽快恢复」。把它当成调试工具，而不是长期方案。公网访问的安全底线是 HTTPS 加访问控制，设备身份校验能开就开着，别为了省事把它永久关掉。
