网络与 LLM 网关

网络与 LLM 网关

企业里网络出向是一道必答题。合规要求、内网代理、白名单、审计、成本拆账——这些都不是单个工具能搞定的，得有一个统一的关卡。LLM 网关就是这个关卡：所有模型调用都走它一道，它在中间做认证、记账、过滤、限流、转发。

Claude Code 支持把模型调用指向自定义网关代理，让企业用一套现有的统一管控体系管所有 AI 出向。这一篇讲清楚 Network configuration 文档、LLM gateway 文档，以及怎么跳过 Bedrock / Vertex 自身认证、让 Claude Code 直连你的网关。

为什么需要 LLM 网关

设想这样一个场景：

• 公司所有出向流量必须走企业代理，便于审计与合规。
• 安全团队要在中间扫一遍 prompt，阻止敏感数据外泄。
• 财务要把每个团队的 token 用量拆账，按部门出账单。
• 数据治理要记录所有模型调用的元数据，留 6 个月审计日志。

如果每个 AI 工具各自直连模型供应商，上面这些都没法统一做。LLM 网关就是「总关卡」：所有调用收口到一处，做完了该做的再放出去。

网关能做的	价值
统一认证	各团队不必各自管 API key
限流	防止某个团队把额度跑爆
审计日志	谁在什么时候调了什么、花了多少
Prompt 过滤	阻止敏感数据外泄
成本拆账	按团队、按项目出账单
多模型路由	按场景路由到不同模型/Region

网络配置：基础

Claude Code 的网络配置遵循官方 Network configuration 文档。企业最常见的诉求是：

• 走企业 HTTP/SOCKS 代理：让 Claude Code 的出向走公司代理。
• 白名单域名：把 Anthropic API、Bedrock、Vertex 的域名加进代理白名单。
• 不出企业内网：所有出向必须经过审计关卡。

具体的代理环境变量按官方文档为准（不同版本有调整），照官方一行抄最稳。

LLM 网关：自定义端点

LLM gateway 文档讲的是怎么让 Claude Code 把模型调用指向你自己的网关端点，而不是直接打 Anthropic / Bedrock / Vertex。

网关常见的实现有：

• 自建反向代理（nginx / envoy + 一层认证/审计逻辑）
• 第三方 LLM 网关产品（很多企业级 AI 平台带这个能力）
• LiteLLM（开源，能聚合多家模型供应商、统一鉴权、拆账）

跳过 Bedrock / Vertex 自身认证

这是接网关时最关键的一步。

正常情况下，Claude Code 走 Bedrock 时会自己做 AWS 认证、走 Vertex 时会自己做 GCP 认证。但你搭了 LLM 网关之后，网关自己已经认证过了——如果 Claude Code 这一层再做一遍，就会冲突。

所以官方提供了两个开关，让 Claude Code 跳过自身的云认证，把请求直接送到网关：

# 走 Bedrock 模式但跳过 AWS 认证（让网关认证）
export CLAUDE_CODE_USE_BEDROCK=1
export CLAUDE_CODE_SKIP_BEDROCK_AUTH=1

# 走 Vertex 模式但跳过 GCP 认证（让网关认证）
export CLAUDE_CODE_USE_VERTEX=1
export CLAUDE_CODE_SKIP_VERTEX_AUTH=1

读这段配置：

• CLAUDE_CODE_USE_BEDROCK=1 + CLAUDE_CODE_SKIP_BEDROCK_AUTH=1：用 Bedrock 的协议格式，但不做 AWS 认证——网关替你认证。
• CLAUDE_CODE_USE_VERTEX=1 + CLAUDE_CODE_SKIP_VERTEX_AUTH=1：用 Vertex 的协议格式，但不做 GCP 认证——网关替你认证。

这样，Claude Code 把请求按 Bedrock/Vertex 协议格式发出，认证完全交给网关，互不打架。

一张速查表

场景	配什么
走企业 HTTP 代理	按官方 Network configuration 文档配代理环境变量
走自定义 LLM 网关（Bedrock 协议）	CLAUDE_CODE_USE_BEDROCK=1 + CLAUDE_CODE_SKIP_BEDROCK_AUTH=1
走自定义 LLM 网关（Vertex 协议）	CLAUDE_CODE_USE_VERTEX=1 + CLAUDE_CODE_SKIP_VERTEX_AUTH=1
第三方 LLM 网关产品	按产品文档配端点 + 跳过云认证
LiteLLM 自建	配 LiteLLM 端点 + 跳过云认证

自建网关的简单形态

最小可用的自建网关形态，大致是这样：

Claude Code  →  你的网关  →  Anthropic API / Bedrock / Vertex
                  ├─ 认证（企业 SSO / API key）
                  ├─ 限流（按团队/项目）
                  ├─ 审计日志（元数据入库）
                  ├─ Prompt 过滤（敏感数据扫描）
                  └─ 成本拆账（按 header 里的 team 标签）

网关对 Claude Code 来说就是一个透明的代理——请求格式不变，只是中间多一道关卡。Claude Code 那一侧只需要：

1. 配置把请求打到网关端点。
2. 跳过 Bedrock / Vertex 自身认证（用上面那两个开关）。

剩下的认证、限流、审计、拆账，全在网关那一侧实现。

适合什么样的企业

LLM 网关不是所有企业都需要。判断要不要搭：

情况	建议
几十人小团队、走 Anthropic 直连	不必搭网关，开 Console workspace 看成本就够
几百人以上、要审计、要拆账	建议搭，统一收口
强合规行业（金融/医疗/政务）	必须搭，所有出向都要审计
已有 API 网关基础设施	复用现有网关，加 LLM 路由即可

网关 vs 直连：取舍

维度	直连 Anthropic / Bedrock / Vertex	走 LLM 网关
配置复杂度	低，开箱即用	中，要配网关 + 跳过认证
认证	各自管	网关统一管
审计	各供应商日志	网关集中日志
成本拆账	难	容易
限流	各供应商限流	网关自定义
Prompt 过滤	难	容易
延迟	最短	多一跳，略增
故障点	少	多一个网关

网关多一跳延迟、多一个故障点，但换来的是统一管控。值不值，看你企业的合规与治理需求有多重。

接下来

网络与网关配好之后，Claude Code 的所有模型调用都从你的关卡过。下一站该看的是怎么让 Claude Code 本身在执行命令时也受控——沙箱与 Devcontainer。