
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 能不能在受限网络里稳定工作。11. 先分清三条链路:代理、证书、网关
企业网络里经常把三个概念混在一起:corporate proxy、CA certificate、LLM gateway。
它们解决的问题不一样。
| 配置 | 解决什么问题 | 典型变量 |
|---|---|---|
| Corporate proxy | 出站流量必须经过公司代理 2 | HTTPS_PROXY、HTTP_PROXY、NO_PROXY |
| CA / mTLS | TLS 检查、私有 CA、客户端证书认证 1 | CLAUDE_CODE_CERT_STORE、NODE_EXTRA_CA_CERTS、CLAUDE_CODE_CLIENT_CERT |
| LLM gateway | 模型请求统一鉴权、计费、审计、限流 3 | ANTHROPIC_BASE_URL、provider-specific base URL |
官方企业部署总览也把 corporate proxy 和 LLM gateway 分开讲:前者是网络出口策略,后者是模型请求的集中管理层;两者可以一起用,但不能互相替代。2
换成排障顺序就是:先让请求能出网,再让 TLS 能被信任,最后再决定是否把模型请求收口到 gateway。
2. HTTPS_PROXY 是主路径,HTTP_PROXY 是退路
Claude Code 会读取标准代理环境变量。官方示例里,推荐先配置
HTTPS_PROXY;如果没有 HTTPS 代理,再用 HTTP_PROXY。NO_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 按文件名排序后继续合并。这个机制适合让安全、平台、开发体验团队分别维护自己的片段。57. 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 auth | api.anthropic.com、platform.claude.com 1 |
| Claude.ai 订阅登录 | api.anthropic.com、claude.ai 1 |
| Native install / auto-update | downloads.claude.ai,旧版本还可能需要 storage.googleapis.com 1 |
| Chrome / artifact / release notes | bridge.claudeusercontent.com、*.claudeusercontent.com、raw.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 件事跑通:
- 在一台测试机上用 shell export 配好
HTTPS_PROXY和NO_PROXY,确认claude能登录、能发模型请求。 - 确认安装方式:native installer 或 Node 22.15+,再决定是否依赖系统证书库。
- 如果有企业根证书 PEM,先用
NODE_EXTRA_CA_CERTS显式验证。 - 如果代理要求 mTLS,固定
CLAUDE_CODE_CLIENT_CERT和CLAUDE_CODE_CLIENT_KEY路径,轮换时原地替换文件。 - 按使用面补 allowlist,不要只放
api.anthropic.com。 - 如果 WebFetch 在第三方 provider 下失败,单独核对
api.anthropic.com预检请求和skipWebFetchPreflight策略。 - 需要集中计费、限额、审计时再上 LLM gateway,不要用 proxy 冒充 gateway。
- 团队分发用 managed settings,把代理、证书源、非必要流量开关和权限策略统一下发。
企业网络里的 Claude Code 问题,表面上常常是一句「连不上」。拆开看,它通常是代理、证书、认证、allowlist、工具预检和 gateway 计费混在一起。把这几层分开配、分开测,故障才不会在每个开发者电脑上重复出现。
関連コンテンツ
- ログインするとコメントできます。
More from this channel›
- Claude Code SDK #46:ClaudeSDKClient 全解:query、receive_response、interrupt,把 Agent 变成可控多轮会话
- Claude Code SDK #45:Model Configuration 全解——model × effort × fallback × budget,把质量和成本分开调
- Claude Code SDK #44:LLM Gateway 全解——ANTHROPIC_BASE_URL × apiKeyHelper × provider switching,把模型请求收口到团队网关
- Claude Code SDK #42:Hosting 全解——subprocess × SessionStore × tenant isolation,把 Agent 跑进生产环境
- Claude Code SDK #41:GitHub Actions 全解——@claude × workflow × GitHub App,把 Issue 变成可审查 PR
- Claude Code SDK #40:Deep Links 全解——claude-cli:// × repo × q,把 runbook 变成一键启动会话
- Claude Code SDK #39:Desktop Code tab 全解——Session × Diff × Preview,把 Claude Code 变成桌面开发工作台