大模型网关公网接入：用OCI免费L7负载均衡破除超时与端口限制

如果你最近在认真做 AI 应用的对外暴露大概率会撞上这样一堵墙大模型网关程序本身跑得很稳但一旦牵扯到“域名、端口、超时”这三个词就能把人从白天折腾到半夜。我这边的场景是给一套大模型网关做公网接入刚开始图省事直接套 Cloudflare 反向代理结果一头撞上 100 秒响应超时和端口白名单限制中间还试过用非标准端口做折中能用但不彻底最后是靠 OCI 免费 L7 云负载均衡器把问题彻底解掉的。这篇不写学院派理论就把踩坑经过、配置细节、参数取舍和最终的稳定拓扑拆开讲清楚给同样在跟网关超时和端口问题较劲的人一个可直接抄作业的参考。先说结论放前面如果你只是给普通 Web 服务做七层代理Cloudflare 免费套餐完全够用。但你的服务是“单次请求动不动十几秒甚至上百秒”的大模型网关继续在 Cloudflare 免费代理上面想办法基本是在跟平台规则硬碰硬。换一个自己能控制空闲超时和读取超时的 L7 负载均衡器才是正解。以下内容全部基于我自己的实操记录涉及 OCI 的部分以 2024-2025 年的控制台界面为准参数上我尽量给出可复现的取值范围具体以你账号实际配额为准。1. 问题复盘为什么大模型网关偏偏卡在“域名、端口、超时”这三座大山上1.1 大模型网关的超时敏感度和普通 Web API 完全不是一个量级先说个最容易低估的点大模型网关并不是普通 API 网关。它的工作模式通常是“接收用户请求 → 转发给推理后端 → 后端完成生成 → 将结果流式返回”整个过程里真正耗时的大头在后端推理而不是网络传输。一个普通登录接口几百毫秒就能返回但一个大模型的流式对话请求首字延迟可能就要 1-3 秒整段生成可能持续 30 秒、60 秒、甚至更久。更麻烦的是很多网关还承担了工具调用function calling和 Agent 编排的职责。模型需要先思考、再调外部工具、等工具返回、再继续生成。我实际测过一组包含多次工具调用的 Agent 任务从用户发出请求到最终流式响应结束耗时超过 90 秒。这在传统 Web 架构里属于“异常请求”但在大模型场景里就是日常。由此带来的核心矛盾是你的网络链路必须接受“长时间占用连接”这件事任何一层代理只要设置了过短的读取超时或空闲超时都会在模型还在生成时把连接掐断表现就是用户端看到请求失败、连接重置或者 504 网关超时。这不是 SSL 配置错也不是代码 bug而是整个链路里某个环节对“慢请求”没有耐心。1.2 Cloudflare 免费套餐的硬限制100 秒超时与端口白名单Cloudflare 免费 CDN/代理对企业站点和 API 服务来说确实很香但它作为反向代理介入你的流量后请求会经过 Cloudflare 的边缘节点再回源到你的服务器。整个链路里Cloudflare 侧有一项硬性规则免费套餐的 HTTP 代理最大支持 100 秒的响应时间。还要说明的是这 100 秒并不是“连接建立后 100 秒”而是从请求被 Cloudflare 接收、到源站响应开始返回之间的一个超时窗口流式响应开始后一般不受影响但问题恰恰出在“生成首字之前的等待时间”上。不少主流大模型推理服务在排队较重的时候从网关转发到推理后端再到首字返回完全可能超过 100 秒。比如我用 vLLM 部署的模型在并发满载时排队等待时间加上 prefill 时间很容易冲到 120 秒以上。这时候即使你已经在网关里配好了流式输出请求还是会先死在 Cloudflare 的 100 秒等待窗口里表现就是“一直转圈然后突然断掉”。除了超时端口限制也是绕不开的。Cloudflare 的代理模式只开放少数几个 HTTP 端口作为源站和边缘之间的连接端口常见的就是 80、443、8080、8443、2053、2083、2087、2096。如果你想在自己的服务器上用 8000 或 9000 这类端口跑网关再套 Cloudflare 代理回源流量就会出问题。要么你改用它允许的端口要么干脆不套代理只做 DNS 解析但这又会让源站 IP 直接暴露。很多“Cloudflare 端口不通”的报错本质上就是端口白名单没绕开。1.3 端口折中方案的思路以及它为什么只是权宜之计被 Cloudflare 端口问题卡住后我第一版方案是“端口折中”把网关服务绑定到 2053 端口Cloudflare 允许代理访问的端口之一然后通过 Cloudflare 的 DNS 记录把域名指向源站再开 CDN 代理。这样表面上能用域名访问也避开了“端口不在白名单”的问题。但这里有个致命短板折中方案只解决了“端口匹配”并没有解决“超时限制”。我实际的体验是——请求短的时候一切正常请求一旦进入模型推理的长耗时区间连接大概率被 Cloudflare 掐断。另外一个隐藏问题是端口 2053/8443 对终端用户并不友好部分企业内网只允许出站 80 和 443你让客户端访问 https://gateway.example.com:2053连企业防火墙这一关都过不去。折中方案上线两周后我就决定放弃开始寻求“能自由控制超时、端口保持标准、免费额度可观”的替代品。2. 端口折中方案实操记录从配置到放弃的全过程2.1 Cloudflare Tunnel 配置最省事的暴露方式但同样受超时约束在“折中方案”之前我第一反应是直接用 Cloudflare Tunnel 把本地网关暴露出去。Tunnel 的好处是不用开公网端口、不用暴露源站 IP控制台点上几步就能把内网服务映射到域名。做法很简单在 Cloudflare Dashboard 里创建一条 Tunnel然后在 Public Hostname 里填上你的域名和本地服务地址比如gateway.example.com指向http://localhost:8000之后在服务器上跑一个 cloudflared 进程隧道就通了。听起来很完美但实际操作中你会发现几个坑。Tunnel 本质上走的还是 Cloudflare 边缘节点所以免费套餐的 100 秒超时限制照样生效。我在做一次 800 字的流式生成测试时首字延迟因为后端排队超过了 100 秒网页端直接在 100 秒出头收到 502/524。另外 cloudflared 进程在服务器重启后偶尔会陷入“连接边缘节点失败”的状态网上搜cloudflare tunnel error能翻出一堆 1033 错误和 cert 过期问题排查起来非常消磨耐心。2.2 为什么 2053 端口折中方案只撑了两周Tunnel 方案超时问题无解我改走“端口折中”网关绑定 2053DNS 记录开启橙云代理。配置上其实一分钟就能完成但用起来之后问题接二连三。第一是超时问题照旧。第二是部分网络环境根本访问不了非 443 端口。我在手机蜂窝网络下测试时 2053 能通但换到某个企业 Wi-Fi 下直接超时这两者的差别就是出站端口白名单。第三是心里始终不踏实——用非标准端口跑生产服务跟整个行业的最佳实践是拧着的。所有的 SDK、OpenAI 兼容客户端、API 文档默认都是 443你非要让他们访问https://api.example.com:2053任何一个合作方接入前都会先问你一句“为什么端口不是 443”。第四也是最让我决定放弃的一点基于 Cloudflare 代理的折中方案只能解决“让请求进来”不能解决“让请求别断”。你真正要的是一个可以自己定义超时策略的七层入口而不是一个被平台规则锁死的隧道。所以我开始认真评估“DNS 只做解析、流量直接打到云负载均衡器”的路线。2.3 从折中方案里总结出的选型标准这段经历让我沉淀出三个选型判断标准后续在挑负载均衡方案时全是按这个标准来的端口必须标准对外只使用 80/443不让用户感知到任何非标准端口。超时必须可控无论是连接超时、空闲超时、还是读取超时都得允许我按大模型网关的特性去调至少能撑到 300 秒以上。域名路由能力要够用能按 Host 头把gateway.example.com和admin.example.com路由到不同的后端服务最好还能终止 SSL免得后端每台机器都得配证书。对照这个标准Cloudflare 免费代理第一个条件满足、第二个条件不满足直接出局。3. OCI 免费 L7 云负载均衡器从“能用”到“稳”的破局3.1 为什么最终选 OCI 的免费 L7 LB而不是其他方案中间其实犹豫过好几个方向继续用 Cloudflare 付费版、换一台自带负载均衡的云主机、Nginx 反代自己做高可用。逐一分析下来Cloudflare 付费版虽然能调长超时但免费额度说没就没而且大模型网关的流量特性是“连接数量不大单连接持续时间长”这在 Cloudflare 这种按请求数/带宽计费的模式里并不经济。Nginx 反代确实能自己控制超时但 Nginx 是单机方案机器挂了服务就断了还需要额外解决证书管理、健康检查、自动故障转移的问题。当然如果你只有一台后端实例Nginx 完全可行但考虑到后续要多副本部署和自动扩缩容还是需要一个真正的负载均衡器。OCI 免费 L7 负载均衡器属于 Oracle Cloud Infrastructure 免费套餐里的网络组件最诱人的地方是“免费且是真正的 L7 LB”。它在控制台叫 Load Balancer创建时可以选择 L7 或者 L4Network LB免费套餐默认支持 L7 能力的负载均衡实例只要不超出免费额度就不额外收费。它能在公网 IP 上做 443 监听、SSL 终止、按 Host 头做虚拟主机路由、后端健康检查、空闲超时配置几乎完美覆盖我上面列的三个选型标准。再补一句OCI 免费负载均衡器属于共享/基础型实例性能上不是那种支持百万并发的高端货但对“大模型网关”这种 QPS 不高、单请求时间长的场景来说性能完全不是瓶颈重点是行为特征匹配。3.2 整体架构设计域名、端口、超时如何在一条链路上各就各位我最终落地的拓扑按数据流顺序是用户客户端 ↓ 通过 https://gateway.example.com 访问Cloudflare 仅做 DNS 解析不开代理 DNS 解析到 OCI LB 公网 IP ↓ 443 端口HTTPS 监听SSL 证书在 LB 上终止 OCI L7 Load Balancer ↓ 转发到后端实例的 8000 端口内网地址 后端 VM运行大模型网关服务 ↓ 转发到推理服务 vLLM / 推理后端注意一个关键动作Cloudflare 那边我把它设置为“仅 DNS”模式也就是灰度云图标点灰不开启橙色代理。这样做是为了让流量直达 OCI LB绕开 Cloudflare 的 100 秒限制。DNS 解析这件事交给 Cloudflare 没问题但不能让它代理流量。域名层面所有流量统一走https://gateway.example.com通过 OCI LB 上的 Hostname 路由把请求转发到对应后端集。端口层面对外只有 443内部统一用 8000跟后端服务实例一一对应没有任何非标准端口暴露到公网。超时层面LB 上把空闲超时Idle Timeout调大同时后端网关自身也不设置短超时整条链路对“慢响应”的容忍度大幅提升。3.3 从零到一OCI LB 创建与配置的完整步骤下面是我在 OCI 控制台里实际操作过的配置流程我尽量写得细一点照着点就行。第一步开通 OCI 账号并进入控制台。如果你还没有 OCI 账号可以用免费套餐注册之后在“网络 → 负载均衡器”菜单里选择创建负载均衡器。记得选“L7 Load Balancer”不要选“Network Load Balancer”L4 类型虽然也能做端口转发但没法做 Host 头路由和 SSL 终止超时控制也没有 L7 灵活。第二步配置监听器。创建 LB 时你会被要求添加监听器我这边监听的是 443 端口协议选 HTTPS。SSL 证书这边你可以上传自己的 PFX/PEM 证书也可以用 OCI 生成的证书。建议直接上传已有域名证书比如用 Let‘s Encrypt 签的证书省得后面浏览器报警告。第三步配置后端集Backend Set。我建了一个叫llm-gateway-bes的后端集策略选加权轮询把运行网关服务的后端 VM 内网 IP 和端口填进去。注意一定要用内网 IP不要用公网 IP否则流量绕路不说还可能被安全列表挡住。后端端口我用的是 8000因为网关服务监听在这个端口。第四步配置健康检查。这是最容易踩坑的环节我单独在后面“踩坑实录”里详细讲。先给个推荐值健康检查路径用/health或者你的网关提供的任何轻量探活端点间隔 10 秒超时 5 秒不健康阈值 3 次健康阈值 1 次。如果你用 vLLM 这类带/health接口的服务探活就很简单。第五步创建 Hostname 路由规则。在 LB 详情页里找到“Hostnames”和“Routing Policies”或者“Virtual Hosts”配置新增一个 hostnamegateway.example.com然后绑定到刚才的后端集。这样同一个 LB 上可以挂多个 hostname每个路由到不同后端真正发挥 L7 的能力。第六步配置安全列表和 NSG。OCI 的负载均衡器要能访问后端 VM必须在后端 VM 的子网安全列表里放行来自 LB 的流量。具体做法在后端子网的安全列表入站规则里放行源 CIDR 为 LB 所在子网 CIDR、目标端口为 8000 的 TCP 流量。很多第一次用 OCI LB 的人都是在这里栽跟头LB 显示健康检查失败结果就是安全列表没放行。第七步修改 DNS 解析。回到 Cloudflare DNS 管理页把gateway.example.com的解析记录改成 OCI LB 的公网 IP并且确保代理状态是“仅 DNS”橙色云朵关闭。等 DNS 生效后curl https://gateway.example.com/v1/models能直接返回网关的模型列表这条链路就通了。3.4 关键参数配置超时、重试、流式响应一个都不能少整理一下我在 OCI LB 上实际用到的、对大模型网关影响最大的几组参数配置项我的取值说明监听协议/端口HTTPS / 443对外标准端口不用任何非标端口SSL 终止LB 上终止证书只装在 LB后端实例用 HTTP 即可后端端口8000网关服务监听端口内网通信无需 TLS健康检查路径/health必须是一个响应极快的轻量接口健康检查间隔10 秒太短会误判太长影响故障转移速度健康检查超时5 秒探活请求的响应超时Idle Timeout300 秒关键参数给流式响应留足余量路由规则Host header → 后端集gateway.example.com 指向网关后端这里最核心的就是“Idle Timeout”空闲超时。OCI L7 LB 的默认空闲超时时间并不长对大模型网关来说必须手动调大。我把它设置为 300 秒理论上可以覆盖绝大多数单次生成请求。如果你部署的 Agent 任务动辄好几分钟建议调到 600 秒。注意这不是连接最大时长而是“连接上没有数据传输的最大允许空闲时间”流式响应会持续产生数据所以实际不会卡到这个上限。另一个容易被忽略的是重试策略。OCI LB 在默认情况下如果后端返回 502/504并不会自动重试而大模型网关偶尔会因为上游推理实例过载返回 5xx。这里我建议在后端网关上层做“有限重试”而不是依赖 LB 层盲目重试因为大模型请求碰到生成到一半再重试用户侧看到的就是重复输出或上下文错乱宁可失败也别乱重试。4. 踩坑实录与排查技巧从健康检查误判到流式断连4.1 坑一健康检查把“模型加载中”判成后端不健康这个坑我印象最深。第一次配好后端集LB 的健康检查每隔十秒去请求/health但 vLLM 在冷启动加载模型的时候进程起来了、端口也在听但/health接口返回的是 503 或者直接不发响应于是 LB 把后端标记为“不健康”然后停止往这个实例转发流量。结果是模型刚加载完成的瞬间LB 还在排队等待健康检查通过用户请求全部 502。我当时的处理是给健康检查加了更长的超时和阈值同时在后端脚本里让模型加载完成后立即预热/health。但最有效的一招是让健康检查改走网关的静态健康端点而不是推理服务的健康端点一个只检查进程存活一个检查模型就绪两者分离开。总之健康检查一定要选择“进程活着就返回 200”的端点别跟大模型的初始化状态绑死。4.2 坑二502 的根源不是 LB而是后端会话被提前断开切到 OCI LB 之后后端实例还沿用了一套老代码默认的 HTTP 客户端空闲超时只有 60 秒。LB 设置 300 秒空闲超时但后端服务在生成到第 61 秒时自己把连接给断了用户端看到的就是一个“干净的 502”。当时我排查了很久一直在调 LB 参数后来用curl -v直接从后端 VM 本地请求网关服务发现后端竟然在第 60 秒左右主动断连这才定位到是应用层超时设置太短。所以排查超时问题时一定要把链路切成三段来看公网到 LB、LB 到后端、后端到推理服务。我推荐先用curl -v --max-time 120 https://gateway.example.com/v1/models测对外链路再直接在 OCI VM 本机执行同样的请求测后端哪里断开哪里就是问题所在。很多“诡异超时”本质上都是这一层那一层的默认超时在叠加不是玄学。4.3 坑三Cloudflare “仅 DNS” 模式生效前的灰云残留问题改 DNS 之前我的域名还是 Cloudflare 代理模式切换成仅 DNS 后大量本地和运营商 DNS 还缓存着旧的 Cloudflare 边缘节点 IP导致部分用户在一段时间内仍然访问到旧的代理链路继续踩 100 秒超时。这个问题的处理办法有两个一是把 DNS TTL 提前调小到 60 秒等切换结束后再调回默认值二是切换后主动清一轮本地 DNS 缓存测试环境可以用dig命令反复确认解析结果已经指向 OCI LB 的公网 IP而不是 Cloudflare 的 IP 段。4.4 深度排查命令集这组命令能解决 80% 的“连接问题”整理一组我在这些天里反复用的排查命令遇到网关访问异常可以直接按顺序跑# 1. 确认域名解析到了正确的 LB IP dig gateway.example.com short # 2. 测试端口连通性只测 TCP 层 nc -vz gateway.example.com 443 # 3. 看 TLS 握手和三段式响应头 curl -vI https://gateway.example.com/v1/models # 4. 测长超时场景下的行为115 秒不中断 curl -v --max-time 115 --no-buffer \ https://gateway.example.com/v1/chat/completions \ -H Content-Type: application/json \ -d {...流式请求体...} # 5. 从后端 VM 本机直连网关区分 LB 层问题还是后端问题 curl -v --max-time 115 http://127.0.0.1:8000/v1/models如果第 1、2 步正常第 3 步也正常但第 4 步固定在某一个秒数断开基本可以确定是链路中某层超时到期。此时用第 5 步做二分定位优先检查后端应用本身和反向代理的超时配置。4.5 免费 LB 的资源边界与扩展方向最后提醒一下 OCI 免费 L7 负载均衡器的资源边界。免费套餐里的 LB 实例有一个固定的公网 IP但它是共享资源的形态规格和性能上限跟付费的更高配置 LB 有差距。对于大模型网关这种“长连接、低 QPS”的场景完全够用但如果你的网关还要承载大量普通短请求或者像文件上传这种超大流量还是建议评估一下是否升级到付费 LB 规格。我觉得这套方案目前最优雅的地方在于对外只有一个标准的 443 端口域名路径靠 L7 Host 头自由路由超时策略完全掌握在自己手里。Cloudflare 留在链路里只做 DNS 解析这一件事免费、稳定、还能享受它的 DNS 保护能力真正承载流量的 OCI LB 免费额度又充足。可以说每一层都放在了它最合适的位置上。写在最后的实操心得折腾完这一轮我自己最大的体会是大模型时代的“网关接入”问题表面上是在折腾端口和超时本质上是对“网络中间层是否理解长流式请求”的考验。遇到超时先别急着加机器先理清楚整个链路里每一层的默认超时时间是多少再去看你的请求到底是多少秒才能产生第一个字节。还有一个非常有用的小技巧生产环境正式切换前一定准备一个能稳定复现“长耗时请求”的测试脚本每次改完配置就跑一遍拿数据说话而不是靠感觉。如果你也正被 Cloudflare 的 100 秒限制折磨或者还在用非标准端口跟防火墙斗智斗勇强烈建议直接跳到 OCI 免费 L7 负载均衡器这条路来。成本几乎为零配置过程半小时左右换来的是以后可以安安心心调试大模型网关而不用三天两头怀疑是不是网络层又掐断了连接。