Claude 国内使用完整指南：网络配置与访问方案

先探测，再决定改什么

不要凭感觉配网络。先发一个最小请求，看它卡在哪一步：

curl --head https://<你的服务地址>

只要能收到状态码——哪怕是表示未授权的状态码——链路就是通的：服务端在正常工作，只是没带有效凭据。这种情况要查 Key，不要再折腾代理。

一直等到超时、或者立刻提示连接被拒，才是网络层的问题。前者多半是出口被挡，后者多半是本机没有服务在监听。先分清这两类，再动手。

还有一点：探测命令能通，不代表客户端能通。客户端可能读不到同样的环境变量，也可能走了另一套网络栈。最终要用客户端自己的请求验证，见接口地址与端点。

本机代理：最短的一条路

已经有一个稳定的本地代理时，让终端的请求走它就行。导出两个变量：HTTPS_PROXY 与 HTTP_PROXY，值都指向本机地址加代理端口。不同工具对变量名的支持略有差异，以客户端当前文档为准：

export HTTPS_PROXY="http://127.0.0.1:<端口>"
export HTTP_PROXY="http://127.0.0.1:<端口>"

这样只影响当前窗口。关掉终端就失效，适合临时排查。要长期使用，把同样几行写进终端启动脚本，重新打开窗口后生效。

验证时分两步：先确认代理进程在监听那个端口，再用同一组变量发一次探测请求。两步都过，才说明配置正确。只看到「设置成功」的回显没有意义。

中转服务与自建网关

没有稳定代理，或者团队想统一出口时，可以改请求的目标地址：把 ANTHROPIC_BASE_URL 指向中转服务，再配一把该服务签发的 Key。地址与 Key 的关系，可以对照Base URL那一页。

这条路的代价要提前说清：

• 代码与提示都要先交给第三方，敏感项目不要用；
• 费率、限流、日志留存政策各家不同，先读清楚；
• 服务随时可能变更或停运，不要把生产流程绑死在上面。

有境外服务器和运维能力时，自建网关更可控：统一域名、统一鉴权、统一审计，团队成员只配地址和 Key。证书、访问控制和额度限制由自己掌握，出问题也能查到日志。

合规是前提。使用前确认所在地法规与平台条款允许，企业场景走采购与合规流程，不要把个人方案直接搬进公司网络。

安装与依赖下载慢

客户端装不上、依赖拉不下来，通常不是模型服务的问题，而是包管理器的源太远。

处理顺序：

1. 先把下载源换到国内镜像，装完再换回默认；
2. 仍慢时，只给安装过程临时挂代理；
3. 安装结束后撤销代理设置，避免影响其他包。

临时挂代理这一步最容易留下后患。很多人装完忘了撤，之后所有包都绕一圈，排查半天才发现。装完就跑一次「取消代理」的命令，把它当成安装流程的一部分。

故障对照表

现象	更可能的原因	先查什么
立即提示连接被拒	代理没启动或端口写错	本机端口是否在监听
长时间无响应	出口不通或地址写错	探测请求是否超时
证书校验失败	代理拦截了加密流量	是否对目标域名做了中间人
时断时续	线路抖动或超时太短	适当放宽超时并复测

证书问题不要用「关闭校验」来绕过。那会把整台机器的安全性一起降级。正确做法是让代理放行目标域名，或者把证书链配好。

超时问题先复测三次，确认是偶发还是稳定。偶发就加长超时；稳定失败则回到第一张表，重新判断是出口还是配置。

验证与收束

最后用客户端自己发一条最小请求：

claude -p "用一句话确认连接正常"

能返回内容，网络这一关就过了。接下来认识你每天要面对的界面：输入行、工具调用、权限确认和差异视图，见界面介绍与导航。