Claude Code SDK #43:Corporate Proxy 全解——HTTPS_PROXY × CA store × mTLS,让 Claude Code 穿过企业内网

Claude Code SDK #43:Corporate Proxy 全解——HTTPS_PROXY × CA store × mTLS,让 Claude Code 穿过企业内网

企业网络里的 Claude Code 故障,常常不是模型问题,而是代理、证书、mTLS、allowlist、WebFetch 预检和 LLM gateway 边界混在一起。本篇按官方文档拆解 Corporate Proxy 配置,帮助团队把受限网络里的 Claude Code 跑稳。

如果你在公司网络里第一次跑 claude,最容易误判的错误不是模型不好用,而是网络链路根本没打通:代理能不能转发 HTTPS、企业根证书有没有被信任、WebFetch 的域名预检会不会被防火墙拦住、mTLS 客户端证书是不是已经过期。官方 Enterprise network configuration 文档把这些东西放在同一页,因为它们共同决定 Claude Code 能不能在受限网络里稳定工作。1

1. 先分清三条链路:代理、证书、网关

企业网络里经常把三个概念混在一起:corporate proxy、CA certificate、LLM gateway。
它们解决的问题不一样。
配置解决什么问题典型变量
Corporate proxy出站流量必须经过公司代理 2HTTPS_PROXYHTTP_PROXYNO_PROXY
CA / mTLSTLS 检查、私有 CA、客户端证书认证 1CLAUDE_CODE_CERT_STORENODE_EXTRA_CA_CERTSCLAUDE_CODE_CLIENT_CERT
LLM gateway模型请求统一鉴权、计费、审计、限流 3ANTHROPIC_BASE_URL、provider-specific base URL
官方企业部署总览也把 corporate proxy 和 LLM gateway 分开讲:前者是网络出口策略,后者是模型请求的集中管理层;两者可以一起用,但不能互相替代。2
换成排障顺序就是:先让请求能出网,再让 TLS 能被信任,最后再决定是否把模型请求收口到 gateway。

2. HTTPS_PROXY 是主路径,HTTP_PROXY 是退路

Claude Code 会读取标准代理环境变量。官方示例里,推荐先配置 HTTPS_PROXY;如果没有 HTTPS 代理,再用 HTTP_PROXYNO_PROXY 可以用空格或逗号分隔,支持 localhost、IP、具体域名和 .example.com 这种域名后缀。1
最小配置长这样:
export HTTPS_PROXY="https://proxy.example.com:8080"
export NO_PROXY="localhost,127.0.0.1,.corp.example.com"
claude
有两个细节别漏。
第一,Claude Code 不支持 SOCKS proxy。公司只给了 SOCKS5 地址时,不是换个变量名就能跑,需要网关或本地转接层把它变成 HTTP/HTTPS proxy。1
第二,NO_PROXY="*" 是绕过所有代理。这个值适合临时验证「是不是代理导致的问题」,不适合作为团队默认配置。否则你以为流量都过了审计出口,实际全被本机直连绕开。

3. 代理用户名密码别写死在脚本里

如果代理要求 basic authentication,官方支持把凭据放进代理 URL:1
export HTTPS_PROXY="http://username:password@proxy.example.com:8080"
这能跑,但不适合直接写进团队脚本。文档也提醒不要把密码硬编码在脚本里,应使用环境变量或安全凭据存储。1
更稳的做法是:
export PROXY_USER="alice"
export PROXY_PASS="$(security find-generic-password -s corp-proxy -w)"
export HTTPS_PROXY="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:8080"
Windows 团队可以把同一件事交给凭据管理器、Intune 下发的用户环境变量,或者企业自己的 secrets agent。目标不是让变量看起来更优雅,而是避免代理密码进 git、CI log 和共享 wiki。

4. 自定义 CA 有两条路:系统证书库和 NODE_EXTRA_CA_CERTS

很多公司会做 TLS inspection。代理把外部 HTTPS 拆开检查,再用公司根证书重新签发连接。如果 Claude Code 不信任这张根证书,就会报 TLS 证书错误。
官方文档说,Claude Code 默认信任两类证书源:随 Claude Code 打包的 Mozilla CA 集合,以及操作系统证书库。读取系统证书库需要运行时支持 tls.getCACertificates;native installer 一定支持,npm 安装则需要 Node 22.15 或更新版本。1
所以第一步不是急着加变量,而是先确认安装方式:
claude doctor
node --version
如果公司根证书已经装进 OS trust store,且你用 native installer 或 Node 22.15+,多数场景不用额外配置。如果你要显式指定信任来源,可以设:1
export CLAUDE_CODE_CERT_STORE="bundled,system"
# 或只信系统证书库
export CLAUDE_CODE_CERT_STORE="system"
如果企业给的是一份 PEM 文件,直接用 Node 通用变量:1
export NODE_EXTRA_CA_CERTS="/path/to/corp-root-ca.pem"
这里有个版本坑:老 Node 读不到系统证书库时,CLAUDE_CODE_CERT_STORE=system 不会神奇修复它。要么换 native installer,要么升级 Node,要么用 NODE_EXTRA_CA_CERTS 明确给 PEM。

5. CLAUDE_CODE_CERT_STORE 要放进 env,不是顶层 settings key

Enterprise network configuration 文档特别说,CLAUDE_CODE_CERT_STORE 没有专门的 settings.json schema key。如果要写进配置文件,需要放在 env 下面。1
{
  "env": {
    "HTTPS_PROXY": "https://proxy.example.com:8080",
    "NO_PROXY": "localhost,127.0.0.1,.corp.example.com",
    "CLAUDE_CODE_CERT_STORE": "bundled,system",
    "NODE_EXTRA_CA_CERTS": "/etc/ssl/certs/corp-root-ca.pem"
  }
}
环境变量页也说明,shell 里设置的变量只影响当前终端;写进 settings 文件的 env 会在每次 claude 启动时生效。可选位置包括 ~/.claude/settings.json、项目里的 .claude/settings.json.claude/settings.local.json,以及组织管理员下发的 managed settings。4
这就引出一个实战建议:个人排障先用 shell export,团队分发再写 managed settings。别一上来就把临时代理地址提交进项目配置。

6. Managed scope 适合公司级网络策略

Settings 文档把配置分成 Managed、User、Project、Local 四个 scope。Managed 优先级最高,可以通过 server-managed settings、MDM/OS policy、系统级 managed-settings.json 等方式下发,而且用户和项目配置不能覆盖。5
这很适合公司级网络策略:代理地址、证书源、禁用非必要流量、允许哪些 MCP server、哪些权限规则必须执行。开发者不该在每个仓库里自己维护这些东西。
一个最小 managed fragment 可以长这样:
{
  "env": {
    "HTTPS_PROXY": "https://proxy.corp.example.com:8080",
    "NO_PROXY": "localhost,127.0.0.1,.corp.example.com",
    "CLAUDE_CODE_CERT_STORE": "bundled,system",
    "DISABLE_TELEMETRY": "1",
    "DISABLE_ERROR_REPORTING": "1"
  }
}
如果团队用文件方式分发 managed settings,Settings 文档还支持 managed-settings.d/ drop-in 目录:基础文件先合并,目录里的 *.json 按文件名排序后继续合并。这个机制适合让安全、平台、开发体验团队分别维护自己的片段。5

7. mTLS 是客户端证书,不是 CA 证书

CA 证书解决「我信不信服务器」。mTLS 里的 client certificate 解决「服务器信不信我」。企业代理、API gateway 或零信任出口有时会要求客户端出示证书。
Claude Code 对 mTLS 的变量是这三个:1
export CLAUDE_CODE_CLIENT_CERT="/path/to/client-cert.pem"
export CLAUDE_CODE_CLIENT_KEY="/path/to/client-key.pem"
export CLAUDE_CODE_CLIENT_KEY_PASSPHRASE="your-passphrase"
官方文档还有一个对轮换很有用的细节:Claude Code 会在启动时读取证书和 key 文件,也会在应用 settings 时重新读取,包括 session 期间 settings 发生变化的时候。要轮换证书和 key,可以替换同一路径下的文件。1
所以证书轮换不要写成「改文件名再改配置」。更好的方式是保持路径稳定,用企业证书代理或部署脚本原地替换文件,再让 settings reload 接管。

8. allowlist 不只是一条 api.anthropic.com

很多排障卡在这里:模型请求能通,但登录、安装、插件、Chrome bridge、release notes 或 artifact 预览失败。
官方网络访问表列了多类域名:api.anthropic.com 用于 Claude API 请求,claude.ai 用于 claude.ai 账号认证,platform.claude.com 用于 Console 账号认证,downloads.claude.ai 用于插件可执行文件下载、native installer 和 auto-updater,raw.githubusercontent.com 用于 /release-notes changelog feed 和插件市场安装统计等。1
如果团队只 allowlist api.anthropic.com,CLI 可能能回答问题,但安装更新、账号登录、插件和 release notes 都会出现零散故障。
更合理的做法是按使用面分层:
使用面至少核对
API key / Console authapi.anthropic.complatform.claude.com 1
Claude.ai 订阅登录api.anthropic.comclaude.ai 1
Native install / auto-updatedownloads.claude.ai,旧版本还可能需要 storage.googleapis.com 1
Chrome / artifact / release notesbridge.claudeusercontent.com*.claudeusercontent.comraw.githubusercontent.com 1
这张表不是让每个公司无脑全开。它的作用是把「为什么这个功能坏了」从玄学问题变成可核对的网络清单。

9. WebFetch 有一条额外的域名安全检查

即使用 Bedrock、Google Cloud’s Agent Platform、Microsoft Foundry 或 gateway 跑模型,Claude Code 的 WebFetch 工具仍可能访问 api.anthropic.com 做 domain safety check。数据使用文档说,WebFetch 在抓取 URL 前会把 hostname 发到 api.anthropic.com,不发送完整 URL、path 或页面内容;结果按 hostname 缓存 5 分钟。6
如果公司网络屏蔽了 api.anthropic.com,WebFetch 会失败,除非 allowlist 这个域名,或者在 settings 里设置 skipWebFetchPreflight: true。文档也提醒,关闭检查后 WebFetch 会尝试抓取任何 URL,因此需要配合 WebFetch permission rules 限制可访问域名。6
这点很容易被误诊成「代理没配好」。实际上模型链路可能已经通了,坏的是工具链路里的预检请求。

10. Gateway 管凭据和审计,proxy 管网络出口

LLM gateway 文档给它的定位很清楚:集中管理 provider credential、按开发者或团队归因 usage、做成本控制、审计日志和 provider switching。3
这和 corporate proxy 的职责不一样。Proxy 关心的是「这台机器能不能出网,出网走哪条路」。Gateway 关心的是「模型请求用谁的凭据、记到哪个团队、怎么限额、怎么审计」。
官方 rollout 顺序也很工程化:先部署 gateway 并放入 provider credential,再给每个开发者发 gateway credential,然后通过 managed settings 和 secrets tooling 分发 base URL 与凭据,最后让开发者在 Claude Code 里检查配置是否已经生效。3
这里还有一个账单坑:当 gateway credential 或 apiKeyHelper 生效时,开发者的 claude.ai subscription 不再用于这个 session;流量按 gateway 转发的上游凭据计费。只设置 ANTHROPIC_BASE_URL、但没有 gateway credential,不会替代订阅登录。3

最小落地清单

如果你要在公司网络里推广 Claude Code,别先写一份很长的「网络说明」。先把下面 8 件事跑通:
  1. 在一台测试机上用 shell export 配好 HTTPS_PROXYNO_PROXY,确认 claude 能登录、能发模型请求。
  2. 确认安装方式:native installer 或 Node 22.15+,再决定是否依赖系统证书库。
  3. 如果有企业根证书 PEM,先用 NODE_EXTRA_CA_CERTS 显式验证。
  4. 如果代理要求 mTLS,固定 CLAUDE_CODE_CLIENT_CERTCLAUDE_CODE_CLIENT_KEY 路径,轮换时原地替换文件。
  5. 按使用面补 allowlist,不要只放 api.anthropic.com
  6. 如果 WebFetch 在第三方 provider 下失败,单独核对 api.anthropic.com 预检请求和 skipWebFetchPreflight 策略。
  7. 需要集中计费、限额、审计时再上 LLM gateway,不要用 proxy 冒充 gateway。
  8. 团队分发用 managed settings,把代理、证书源、非必要流量开关和权限策略统一下发。
企业网络里的 Claude Code 问题,表面上常常是一句「连不上」。拆开看,它通常是代理、证书、认证、allowlist、工具预检和 gateway 计费混在一起。把这几层分开配、分开测,故障才不会在每个开发者电脑上重复出现。

관련 콘텐츠

  • 로그인하면 댓글을 작성할 수 있습니다.
More from this channel