Claude Code 国内怎么用？先理解它为什么需要终端代理

如果你搜索的是「Claude Code 国内怎么用」「Claude Code 登录失败」「Clash Verge 终端代理怎么配置」，真正需要解决的通常不是某一个按钮在哪里，而是安装、认证、模型请求和本地回调分别由不同进程完成。Claude Code 是运行在终端中的编程助手，常见安装方式会经过 npm，首次使用还可能打开浏览器完成帐号授权，随后由 Node.js 进程持续访问 Anthropic 的服务端点。浏览器能打开网页，并不代表终端里的 Claude Code 已经具备同样的网络条件。

在国内网络环境中，用户经常遇到几种看似相似、实际原因不同的故障：npm install 长时间没有响应，登录页面打开后回调失败，终端显示认证成功但第一次发送提示词时超时，或者代码读取正常、生成结果却在流式输出中途断开。此时反复更换帐号、删除配置文件或盲目切换全局节点，往往不能稳定解决问题。更可靠的思路是把链路拆开：先确认 Clash Verge 本身已运行，再确认订阅和节点正常，最后让 Claude Code 明确使用本机代理端口，并根据连接日志补充分流规则。

本文以 Clash Verge 与 Mihomo 内核为例，覆盖 Windows、macOS 和 Linux 上都通用的终端配置方法。界面名称可能因版本不同显示为「设置系统代理」「系统代理」「Mixed Port」或「混合端口」，但判断原则不变：浏览器访问、Node.js 请求、OAuth 本地回调和 Claude API 长连接必须分别验证，不能只凭一个网页是否能打开来判断配置成功。

安全提醒：订阅链接、API Key、OAuth 凭据和终端日志都可能包含敏感信息。排障时可以分享错误类型和目标域名，但不要把完整订阅 URL、Authorization 请求头、令牌文件或带有个人信息的日志直接发到公开论坛。

第一步：安装并确认 Clash Verge 的基础状态

开始配置 Claude Code 之前，先把 Clash Verge 本身整理到可验证状态。建议从项目的可信发布页获取与系统架构匹配的安装包，Windows 通常选择 x64，Apple 芯片 Mac 选择 arm64，Intel Mac 则选择 x64。首次启动遇到 Windows SmartScreen 或 macOS 未识别开发者提示时，应先核对下载来源、文件签名和版本信息，再根据系统的「更多信息」或「隐私与安全性」入口执行放行，不要为了省事安装来路不明的二次打包版本。

打开 Clash Verge 后，先进入配置或 Profiles 页面导入你的订阅链接。订阅本质上是包含节点、代理组和规则的远程配置，导入后要等待解析完成，并确认配置列表中出现可选配置文件。点击更新时，如果提示连接超时，先不要急着调整 Claude 规则，因为此时问题发生在「订阅下载」阶段，可能与当前网络、订阅地址失效、DNS 或服务商限制有关。

  1. 导入订阅：在 Profiles 页面粘贴订阅 URL，点击导入或下载，等待配置文件完成解析。
  2. 选择活动配置：导入成功后点击该配置，使其成为当前运行配置，而不是只把它留在列表中。
  3. 选择稳定节点：先在 Proxies 或代理页面手动选择一个延迟和丢包表现稳定的节点，不要一开始就使用频繁切换的自动测速组。
  4. 启动代理核心：确认 Clash Verge 的运行状态为已启动，并记录本机的混合端口，例如 127.0.0.1:7897；实际端口以 Settings 页面显示为准。
  5. 先做基础测试：在浏览器打开一个普通 HTTPS 网站，再观察 Clash Verge 的 Connections 列表是否出现连接记录，确认客户端不是只有界面启动而没有流量经过。

如果 Clash Verge 的系统代理开关已经打开，浏览器一般会自动读取系统代理设置。但终端程序是否继承系统代理取决于操作系统、Shell、Node.js 版本以及具体 HTTP 库，不能假设「系统代理已开启」就等于「Claude Code 一定走代理」。因此下一步要在当前终端中显式设置代理变量。

第二步：让终端和 Claude Code 明确走 Clash 代理

Clash 的混合端口通常同时接受 HTTP 和 SOCKS5 请求，是终端工具最容易使用的入口。假设你的混合端口为 7897，可以根据当前 Shell 设置 HTTP_PROXY、HTTPS_PROXY 和小写形式的变量。很多 Node.js 工具只读取其中一组，大小写都写上更容易避免环境差异。Linux 与 macOS 的 zsh、bash 可以在当前窗口临时执行：

export HTTP_PROXY=http://127.0.0.1:7897
export HTTPS_PROXY=http://127.0.0.1:7897
export ALL_PROXY=socks5://127.0.0.1:7897
export http_proxy=$HTTP_PROXY
export https_proxy=$HTTPS_PROXY
export all_proxy=$ALL_PROXY

Windows PowerShell 使用下面的写法：

$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"
$env:ALL_PROXY="socks5://127.0.0.1:7897"

这些变量只对当前终端会话生效，关闭窗口后会消失，适合先测试。确认可用后，再把它们写入 ~/.zshrc、~/.bashrc 或 Windows 的用户环境变量。不要把代理变量直接写进公开仓库的脚本或项目配置，也不要把带用户名和密码的代理 URL 发给别人。

设置完成后，先不要立即运行 Claude Code，可以用最小化测试检查终端是否确实经过 Clash。不同系统可使用 curl 请求一个 HTTPS 目标，随后在 Clash Verge 的连接列表中查找对应域名：

curl -I https://www.anthropic.com
npm config get proxy
npm config get https-proxy

curl 返回结果并不能单独证明 Claude Code 的所有请求都正常，但如果命令完全卡住，且 Clash Connections 中没有任何记录，说明问题仍停留在终端没有使用代理、端口填写错误或 Clash 核心没有运行。若连接已经出现却返回 403、429 或其他 HTTP 状态，则应区分网络连通性与帐号权限，不要把所有错误都归咎于 Clash。

安装阶段：npm、pnpm 与 tarball 下载要分开判断

Claude Code 的安装过程可能先访问 npm 元数据服务，再从 CDN 下载具体的 tarball 文件。也就是说，registry.npmjs.org 能访问，不代表后续包文件所在的 CDN 也一定稳定；反过来，浏览器打开 Anthropic 页面正常，也不代表 npm 安装链路没有问题。可以先查看 npm 是否被写入了旧代理：

npm config get registry
npm config get proxy
npm config get https-proxy

如果输出的是过去使用过的失效端口，npm 可能会绕过你当前的 Clash 设置。可以删除旧配置，让它优先继承当前 Shell 的代理变量：

npm config delete proxy
npm config delete https-proxy
npm ping

当 npm ping 能返回响应后，再安装 Claude Code。安装命令以官方文档和当前发布版本为准，不要直接复制搜索结果中年代过久的包名或第三方脚本。若安装报 ETIMEDOUT、ECONNRESET 或 socket hang up，先查看 Clash 连接日志里最后成功连接的域名，再判断是 npm registry、CDN、证书校验还是代理节点中途断开。

不要把所有流量永久设为全局：全局模式可以用于短时间确认「是不是分流规则导致失败」，但长期使用会让国内网站、公司内网、Git 私有地址和本地开发服务也经过代理。正确顺序是先用全局模式做对照，再回到规则模式，用日志补齐实际需要的域名。

第三步：登录、API 请求与 Clash 分流规则

Claude Code 的首次认证通常会涉及浏览器跳转和本地终端进程两部分。浏览器负责打开授权页面，Claude Code 进程负责生成登录请求、保存认证状态并接收结果。若浏览器页面显示授权完成，但终端一直等待，常见原因是浏览器和终端使用了不同的网络路径，或者本地回调地址被错误地送进代理。通常不需要代理 127.0.0.1、localhost 和局域网服务，应让它们保持直连。

在规则模式下，优先使用 Clash Verge 的连接日志观察真实目标域名。认证阶段可能出现 Anthropic 主站、帐号服务、应用接口和静态资源域名；不同版本的 CLI、认证方式和地区可能产生差异，不能把一份旧域名清单当作永久不变的标准。对已经确认属于 Claude Code 服务的域名，可以放入一个独立策略组，例如「Claude」，并手动指定稳定节点。

规则配置的思路可以概括为三层：

  • 本机与内网优先直连：将 localhost、127.0.0.1、局域网网段、公司内网域名和本地开发端口排除，避免 OAuth 回调或本地 API 被转发到远端。
  • Claude 相关域名使用独立策略：通过 Clash 日志确认目标后，用精确域名或可信的后缀规则指向固定策略组，避免把整个互联网粗略归入同一组。
  • 普通国内服务保持直连：npm 镜像、Git 私有仓库、企业 VPN 和内部文档站点应依据实际网络要求处理，不要因为 Claude 需要代理就全部改成代理。

如果你的配置支持规则覆写，可以将个人规则放在远程订阅规则之前，并确保顺序优先于宽泛的 GEOIP、国家地区或最终兜底规则。规则顺序非常重要：即使你已经写了正确的 Claude 域名，如果它位于一条更早命中的直连规则之后，最终仍会显示为 DIRECT。排查时要看连接详情中的「命中规则」和「实际策略」，不要只看配置文件里有没有那一行。

现象 优先检查位置 处理方向
npm 安装卡住且无连接记录 Shell 代理变量、端口、核心状态 确认 HTTP_PROXY 和 HTTPS_PROXY 指向实际混合端口
浏览器授权成功，终端仍等待 本地回调、localhost 排除规则 保持回调地址直连，检查终端是否仍在运行及端口是否被占用
登录成功但首次请求超时 API 目标域名与分流策略 从连接日志确认域名、规则命中情况和节点握手状态
输出几段代码后断开 节点稳定性、长连接和自动切换 暂时固定节点，避免 url-test 在会话中途切换出口
返回 401 或 403 帐号、凭据、地区或权限 确认网络已连通后，再检查认证状态和服务使用资格

第四步：系统代理不够时，再考虑 TUN 模式

如果浏览器和 curl 都能通过 Clash 访问，而 Claude Code 仍完全没有连接记录，说明该进程可能没有读取环境变量，也没有遵循系统代理。这时可以考虑在 Clash Verge 中启用 TUN 模式，让 Mihomo 在网络层接管更多 TCP、UDP 流量。TUN 并不是「更快的节点」，它只是扩大流量接管范围，因此开启前要先理解路由、DNS 和权限影响。

Windows 上通常需要允许服务模式或安装必要的网络服务；macOS 可能需要批准系统网络扩展并输入管理员密码；Linux 则要确认运行权限、虚拟网卡和路由设置。开启后建议先测试浏览器与终端，再测试 Git、Docker、WSL 或公司 VPN。若开启 TUN 后整机断网，不要继续叠加 fake-ip、DNS 劫持和多层代理，先关闭 TUN 恢复基础网络，再逐项启用。

Claude Code 的开发场景经常同时使用 Git、npm、Docker、SSH、数据库和本地 Web 服务。TUN 规则过宽可能导致 Git 私有域名走错出口，也可能让容器内的 DNS 与宿主机不一致。建议在连接列表中逐个确认：Claude 请求进入代理策略，本地开发服务保持直连，Git 和 npm 根据团队网络要求选择直连或代理，SSH 不要被错误地改写为 HTTP 代理。对于 Docker 或 WSL，宿主机的 127.0.0.1 不一定等于容器内部的回环地址，必要时应使用宿主机可达地址和明确的端口映射。

按顺序排查，避免同时改十个变量

  1. 确认 Clash 核心：检查配置已激活、节点可用、混合端口正在监听，并在 Connections 页面看到测试流量。
  2. 确认终端变量：在同一个 Shell 中执行 echo $HTTPS_PROXY 或 PowerShell 的环境变量查询，确保没有指向旧端口。
  3. 确认基础请求：用 curl 和 npm ping 分别测试 HTTPS 与 npm 链路，不要直接把所有失败归因于 Claude Code。
  4. 确认认证路径：观察浏览器授权完成后，终端是否收到回调；将 localhost 和 127.0.0.1 保持直连。
  5. 确认规则命中：在 Clash 连接详情中查看目标域名、策略组、连接耗时和错误信息，必要时临时固定一个稳定节点。
  6. 最后再启用 TUN：当环境变量和规则都无法让目标进程产生连接时，再用 TUN 验证是否属于代理继承问题。

还要注意时间和证书问题。系统时间明显错误会导致 TLS 校验失败；企业杀毒软件、HTTPS 扫描、VPN 客户端和其他代理软件也可能拦截或改写连接。排障时尽量只保留一个代理入口，暂时关闭重复的系统代理工具，并重新打开终端，使新的环境变量真正生效。如果 Claude Code 的错误从超时变成明确的认证错误，通常说明网络链路已经向前推进了一步，此时应转向帐号或凭据检查。

实用记录方法：每次只改一个变量，并记录修改前后的结果，例如「固定节点后能登录」「删除 npm 旧代理后安装成功」「打开 TUN 后出现容器 DNS 失败」。这样可以快速区分端口、规则、节点、认证和本地环境问题，避免最后得到一份自己也无法复现的配置。

日常使用中的稳定性与安全建议

Claude Code 会读取项目文件、执行命令并根据上下文生成修改建议，因此网络配置之外，还应重视工作区安全。不要在包含生产密钥、个人令牌、客户数据或未脱敏日志的目录中直接运行高权限自动化命令；使用版本控制保存改动，重要操作前先查看差异。代理配置也应遵循最小权限原则：只给需要访问外部服务的终端使用代理，不要把代理地址、订阅 Token 或认证文件提交到 Git。

长时间编程时，稳定节点通常比瞬时测速第一的节点更重要。Claude Code 的流式响应可能持续较长时间，自动测速策略组若在请求过程中切换节点，容易表现为输出突然停止或连接重置。可以在工作时临时固定节点，结束后再恢复自动选择。遇到偶发失败时，先查看连接持续时间、重试次数和错误类型；如果每次都在相同域名失败，优先修规则，如果随机发生在不同域名，才更应该怀疑节点质量或本地网络抖动。

订阅更新也要谨慎。远程订阅刷新可能覆盖策略组名称、规则顺序或覆写配置，导致原本能用的 Claude 规则失效。建议在更新前保留当前配置的备份，更新后重新查看活动配置、代理组和规则命中情况。不要只看「订阅更新时间」显示成功就认为服务正常，至少应重新执行一次终端测试，并在 Clash Verge 中确认目标连接使用了预期策略。

相比一些只提供浏览器按钮的同类代理方案，单独配置终端工具时往往需要手写环境变量、分别处理 npm 与 OAuth，还容易因为没有连接日志而陷入反复试错；某些轻量客户端虽然开关简单，却缺少规则覆写、连接详情和 TUN 排障入口。Clash 官网 的优势在于把 Clash Verge 订阅导入、终端代理变量、规则命中、节点固定与 TUN 排障放在同一套可验证流程里，既能照顾首次使用 Claude Code 的新手，也方便开发者根据真实日志逐步收紧配置，而不是长期依赖全局代理。如果你希望在自己的电脑上按本文步骤搭好这套环境，可以前往免费下载 Clash 官网，先从混合端口和规则模式开始验证，再按需要启用更完整的终端接管能力。