LiteLLM 统一网关接入自定义域名与 Cloudflare 托管架构实践踩坑复盘与方案权衡1. 背景与核心诉求在跨云 K3s 环境中部署 LiteLLM 网关后默认的访问入口是通过 OCIfree-arm-vm节点的公网 IP 加 Kong Gateway 的 NodePorthttp://134.185.90.98:31850/litellm/v1/...虽然该地址已经可以跑通 OpenAI 兼容的 API 调用但在实际团队协作和多客户端接入如 Codex、OpenCode、业务服务时直接使用裸 IP 和高位端口存在几个明显问题凭据安全与合规明文 HTTP 传输存在中间人窃听风险无法安全下发生产级的 Master API Key端点可维护性一旦底层 VM 迁移或公网 IP 变动所有客户端的配置文件都需要批量修改URL 规范性非标准端口:31850在某些受限内网、企业代理或第三方 SDK 中可能被默认策略拦截。为此我们将已有的域名jpgcp.cloud委托给 Cloudflare 进行 DNS 托管并计划为网关分配二级域名gw.jpgcp.cloud。但在实际接入过程中Cloudflare 的边缘代理机制与 Kubernetes NodePort、大模型长推理特性产生了若干预期之外的冲突。本文记录完整的踩坑排查过程、两种主流架构方案的深度对比以及当前阶段的工程选择。2. 核心踩坑复盘Cloudflare 代理与 LLM 网关的冲突机制在初次配置 Cloudflare DNS 时我们开启了默认的Proxied橙色云朵 ☁️模式随后在调用时遇到了两个典型的网络阻断问题。2.1 踩坑一Cloudflare 边缘代理丢弃非标准高位端口在开启橙色云朵的前提下我们尝试直接请求带端口的二级域名curlhttp://gw.jpgcp.cloud:31850/litellm/health/liveliness现象请求无限挂起最终报连接超时Connection Timeout。原理剖析Cloudflare 免费版的反向代理CDN Proxy在边缘节点上只监听特定的标准 Web 端口HTTP80,8080,8880,2052,2082,2086,2095HTTPS443,2053,2083,2087,2096,8443当外部流量发送至gw.jpgcp.cloud:31850时TCP 握手包到达 Cloudflare Anycast 边缘节点由于 31850 端口不在其开放监听列表内边缘防火墙会直接将数据包丢弃Drop流量根本无法到达源站 OCI 节点。2.2 踩坑二源站端口不匹配与 HTTP 522 报错既然无法直接带端口请求我们转而通过标准的 HTTPS 443 端口发起请求curl-ihttps://gw.jpgcp.cloud/litellm/v1/models现象偶尔返回 200但在连续调用或执行复杂请求时频繁出现HTTP/2 522或error code: 522。HTTP/2 522 server: cloudflare error code: 522 (Connection timed out)原理剖析客户端向 Cloudflare 发送https://gw.jpgcp.cloud端口 443Cloudflare 边缘节点接受连接Cloudflare 尝试向源站 IP134.185.90.98发起回源连接默认尝试连接源站的443或80端口而在我们的 K3s 集群中Kong Gateway 的实际对外承载端口是NodePort31850。虽然 OCI 安全组放行了 80 和 443但节点操作系统本地并没有对应的高可用原生监听进程当源站 80 端口因网络抖动未能在规定时间内完成 TCP 三次握手时Cloudflare 边缘即刻判定源站不可达抛出Error 522。2.3 踩坑三思考大模型Thinking Models的长推理与 100 秒超时在测试gemini-3.7-flash或具备深度推理能力的思考模型时模型会先在服务端生成若干轮思考 TokenReasoning Tokens。对于复杂提示词从请求发送到首个 Token 返回可能耗时 40~50 秒以上。Cloudflare 免费版在代理模式下具有以下硬性限制HTTP 连接读取超时HTTP 524 Timeout硬编码为100 秒用户无法在控制台自定义调大如果请求未开启流式stream: false且底层模型推理超过 100 秒Cloudflare 会单方面向客户端返回HTTP 524 (A timeout occurred)直接中断客户端连接。3. 两大架构方案深度解析与权衡为了彻底解决上述网络与端口问题我们在工程上评估了两种落地架构方案一DNS-Only 模式灰色云朵直连客户端 ──(DNS 查询)──► [ Cloudflare DNS ] │ │ │ ◄──(返回源站真实 IP: 134.185.90.98) │ ▼ (客户端直连源站端口) [ OCI free-arm-vm: 134.185.90.98:31850 ] ──► [ Kong Gateway ] ──► [ LiteLLM Pod ]实现机制将 Cloudflare 中的 DNS 记录设置为DNS Onlyproxied: false灰色云朵。Cloudflare 仅承担权威 DNS 解析职责不参与任何 HTTP/TCP 流量转发。客户端通过统一域名直接访问带端口的网关地址http://gw.jpgcp.cloud:31850/litellm/v1优点全端口透明直达彻底绕过 Cloudflare 边缘代理的端口限制31850、22及任意自定义端口均可正常通信0 中间层超时截断彻底消除 Cloudflare 的 100 秒超时限制模型推理时长完全由 Kong 网关配置如read-timeout: 180000决定极致超低延迟客户端与 OCI 新加坡机房直接建立 TCP/TLS 连接没有跨国 CDN 节点的额外转发损耗架构极简、排障链路短出现网络异常时只需排查本地客户端与 OCI 节点之间排除第三方 CDN 策略干扰。缺点URL 带有端口号访问时必须显式携带:31850未能做到完全纯净的https://...暴露源站真实 IPDNS 直接解析出 OCI 实例的公网 IP缺少 CDN 边缘防扫描与 DDoS 流量清洗保护明文 HTTP 限制若要实现 HTTPS需要在 Kong 层或节点层独立挂载证书不能直接使用 Cloudflare 的边缘自动证书。方案二标准 443 端口接入隐藏端口与边缘加速方案二旨在对外提供完全不带端口号的标准 HTTPS 入口https://gw.jpgcp.cloud/litellm/v1。该方案包含两种具体实现路径路径 2ACloudflare Proxied Origin Rules端口重写客户端 ──(HTTPS :443)──► [ Cloudflare Edge (自动 SSL) ] ──(HTTP :31850)──► [ OCI 134.185.90.98:31850 ]实现机制在 Cloudflare 中保持开启橙色云朵并在Rules ➔ Origin Rules中配置一条重定向规则When hostname equals gw.jpgcp.cloud - Override destination port to 31850优点URL 完全纯净标准https://...无端口零新增云成本利用 Cloudflare 规则实现无需创建任何 OCI 额外资源隐藏源站 IP享受 Cloudflare 免费防 DDoS 与 CDN 边缘缓存SSL 证书由 Cloudflare 自动轮换无需本地维护证书文件。缺点与限制100 秒硬性超时非流式长思考请求若超过 100 秒会被 Cloudflare 强制切断需依赖客户端强制开启stream: true存在 20~50ms 的边缘中转握手开销。路径 2B部署 OCI 原生 Load Balancer原生 443 监听客户端 ──(HTTPS :443)──► [ OCI Load Balancer (:443) ] ──(HTTP :31850)──► [ K3s free-arm-vm:31850 ]实现机制在 OCI 租户中创建一个弹性 Load Balancer利用 Always Free 10Mbps 免费额度在 443 端口配置 Listener后端挂载free-arm-vm:31850并在 OCI Certificates 申请免费证书或挂载 Cloudflare 15 年 Origin 证书。优点标准 HTTPS无端口号超时时间可自主配置为 1800 秒30 分钟完美支持任何长时间复杂推理原生支持多节点后端负载均衡HA链路直达新加坡 OCI 机房延迟稳定。缺点占用 OCI 租户唯一的免费 Load Balancer 实例配额需要在云控制台维护 VCN、子网、监听器与证书链路配置相对较重。方案对比汇总表评估维度方案一DNS-Only 直连 (:31850)方案 2ACloudflare Origin Rules方案 2BOCI Load BalancerURL 形态http://gw.jpgcp.cloud:31850https://gw.jpgcp.cloudhttps://gw.jpgcp.cloud端口要求需显式指定:31850标准 443无需端口标准 443无需端口HTTPS 锁头需源站自行处理Cloudflare 全自动提供OCI 证书 / 15年 Origin 证书长推理超时限制无限制(Kong 自主控制 180s)100 秒硬截断(非流式易报 524)无限制(支持 1800s 超长连接)源站 IP 保护暴露 OCI 真实 IP完全隐藏(对外仅暴露 Anycast IP)暴露 OCI LB 公网 IP网络开销0 中转直连最低延迟20~50ms 边缘转译直连机房低延迟云资源占用00占用 1 个 OCI Free LB 实例4. 当前阶段的选择与工程落地结合当前系统的运行目标为本地开发、Codex 助手及内部工具提供高稳定、低延迟的统一大模型接入我们在不同阶段做出如下策略选择4.1 当前选择方案一DNS-Only 直连当前 Phase 1 阶段我们优先采用方案一DNS-Only 灰色云朵配置实施在 Cloudflare 将gw.jpgcp.cloudA 记录设置为proxied: false解析直接指向 OCI 实例 IP134.185.90.98客户端端点配置以 Codex~/.codex/config.toml为例[model_providers.litellm] name my-litellm-gateway base_url http://gw.jpgcp.cloud:31850/litellm/v1 env_key LITELLM_MASTER_KEY wire_api responses选型依据彻底消除了 Cloudflare 边缘代理产生的522 / 524超时风险保证了 Gemini 3.7 Thinking 模式长时间深度推理的稳定性规避了非标准端口在 CDN 边缘被丢包的问题。4.2 未来演进路线当系统进入多团队共享或正式对外提供 SaaS 服务时系统将平滑演进至方案 2BOCI Load Balancer[ 客户端 ] │ (标准 HTTPS :443) ▼ [ OCI Always Free Load Balancer (:443) ] ──(挂载 15 年 Cloudflare Origin 证书) │ (私网 HTTP 转发) ▼ [ free-arm-vm:31850 (Kong Gateway) ] │ ▼ [ LiteLLM Pod (:4000) ]该架构能够同时实现纯净的https://gw.jpgcp.cloud/litellm/v1标准访问15 年免维护的 SSL 证书安全卸载支持 1800 秒的超长推理超时多 K3s 工作节点的高可用流量分发。5. 验收实测与验证数据在当前采用的方案一DNS-Only 模式下执行全链路功能验证5.1 全球 DNS 解析验证digA gw.jpgcp.cloud 8.8.8.8 short# 返回: 134.185.90.98 (直接解析到 OCI 源站)5.2 存活探针与模型列表# 1. 探针检查curl-shttp://gw.jpgcp.cloud:31850/litellm/health/liveliness# 返回: Im alive!# 2. 鉴权与模型列表curl-shttp://gw.jpgcp.cloud:31850/litellm/v1/models\-HAuthorization: Bearer$LITELLM_MASTER_KEY|jq-c.data[].id# 返回: gemini-3.6-flash-freelayer, gemini-3.7-flash-freelayer5.3 真实聊天推理与 Token 统计curl-s-XPOSThttp://gw.jpgcp.cloud:31850/litellm/v1/chat/completions\-HAuthorization: Bearer$LITELLM_MASTER_KEY\-HContent-Type: application/json\-d{ model: gemini-3.6-flash-freelayer, messages: [{role: user, content: What is 100 200? Answer with only number.}], max_tokens: 64 }|jq-c{content: .choices[0].message.content, tokens: .usage.total_tokens}返回数据{content:300,tokens:72}5.4 Codex 客户端联调在 Codex 终端执行指令模型顺利通过http://gw.jpgcp.cloud:31850/litellm/v1完成上下文读取与代码生成全过程耗时稳定在 1~2 秒内未出现任何断连或重试提示。6. 总结在将私有大模型统一网关接入公网域名时不能简单将 CDN 代理套用在非标准端口上。理解 CDN 边缘的端口白名单、回源超时时间100s以及 TLS 握手层级是保障网关稳定性的前提NodePort 临时暴露阶段优先使用DNS-Only灰色云朵直连避免 CDN 代理介入导致的端口阻断和 522/524 超时大模型专属超时机制推理模型如 Thinking / o1 类对长连接要求高网关层必须配置大于 120 秒的 upstream read timeout标准 HTTPS 演进通过 OCI 托管 Load Balancer 承载 443 端口与 TLS 卸载是兼顾纯净 URL 与超长推理连接的企业级最优解。