Claude Code 与 Codex命令行工具的特殊之处

先说清楚这个差别，因为它决定了哪些方案对你有用。网页版的对话发生在浏览器里，所以一个把请求转发一遍的镜像站点就能让它工作。命令行工具不是这样：它直接向官方接口发起 HTTPS 请求，请求里带着你自己的凭据，而镜像站既拿不到也不该拿到这些凭据。所以镜像站对命令行工具结构上就无效，不是「暂时不支持」。

这一层需要的是让本机发出的请求本身能够到达目标接口，也就是在系统层建立一条隧道。浏览器插件同样无效 —— 命令行工具的流量不经过浏览器。这是三类方案里唯一能覆盖命令行的一种。

第二个常被忽略的点是长连接。命令行工具在工作时会保持较长时间的连接，而不是发一个请求就结束。这意味着它对链路中断比网页浏览敏感得多：网页断了刷新一下就好，命令行工具断了可能整个任务要重来。所以对这类使用场景，客户端在链路变差时会不会自动换线，比峰值速度重要得多。

我们的客户端在连接期间持续探测当前线路，探测不通就自动切到下一条可用线路，并且优先留在同一地区，避免把一个正在跑的任务丢到延迟完全不同的链路上。这不是为命令行专门做的功能，但命令行是最能感受到差别的场景。

第三点是关于账号与地区，同样要说清楚边界：如果你的账号本身受地区限制，或者支付方式所属地区不被接受，隧道解决不了。这一层和网络无关。我们能做的是让网络这一层通，不能做的是改变服务方对账号的判断。

Codex 这类工具的情况和上面基本一致 —— 它同样是命令行形态，同样直接调用官方接口，同样不适用镜像方案。需要注意的是，网上关于这类工具的教程绝大多数在讲「怎么安装」，而安装和「能不能连上」是两个问题；很多人按教程装好之后卡在连接上，是因为教程解决的不是这一层。

据 RFC 9114（HTTP/3）规定，一条连接上可以并行承载多个请求流；这带来的副作用是单条连接一旦断掉，同时受影响的请求比过去更多。对长任务来说，这正是「自动换线」比「峰值速度」更值钱的原因。

安卓与 Windows 客户端已上线，macOS 与 Linux 开发中。iPhone 暂无原生客户端。安卓与 Windows 客户端已上线，macOS 与 Linux 开发中。iPhone 暂无原生客户端。

因为命令行工具直接向官方接口发起请求，请求里带着你自己的凭据。镜像站拿不到也不该拿到这些凭据，所以它结构上就无法代理这类请求。

不能。插件只处理浏览器自己发出的请求，命令行工具的流量不经过浏览器。

因为它保持较长时间的连接。网页断了刷新即可，长任务断了可能要重来，所以自动换线比峰值速度更重要。

没用。那一层和网络无关，取决于账号注册地区与支付方式所属地区。我们不假装能解决这个。

暂时不支持。安卓与 Windows 客户端已上线，macOS 与 Linux 开发中。iPhone 暂无原生客户端。命令行的使用者多半在桌面上，这个缺口我们清楚。

再说一个只有命令行使用者会遇到的细节：这类工具通常会把请求发往多个不同的域名 —— 主接口一个、遥测一个、文档或模型资源可能又是另一个。如果你用的是只代理部分流量的方案，可能出现「主功能能用但某个子功能一直失败」的情况，而错误信息往往指向别处。系统层隧道不存在这个问题，因为它不区分是哪个域名。

第二个细节是超时。命令行工具的默认超时通常比浏览器长，这意味着链路不通时它不会立刻报错，而是卡住很久才失败。这会放大「不知道到底是哪里出了问题」的困惑。判断方法是同时在浏览器里打开一个境外站点：如果浏览器也打不开，问题在网络层，不必去翻工具的配置。

第三个细节和额度有关：命令行工具在一次任务里可能产生相当多的往返请求，累积流量比在浏览器里聊天高出不少。如果你用免费额度跑长任务，可能会比预期更早用完。这不是限制策略的问题，而是使用形态决定的，提前知道比事后困惑好。