上个月我被一个大模型网关的超时问题折腾到凌晨两点。服务的结构其实很简单：一台带GPU的服务器部署了兼容OpenAI接口的推理服务，前面套了一层域名入口，方便用户通过统一的API地址访问。反馈也很明确：只要请求处理超过一分半，客户端就掉线，报错要么是“连接重置”，要么是“响应超时”。我一层层往下查，后端日志里请求明明成功了，进程也没有异常，最后才意识到问题根本不在我的程序上，而是站在域名边缘的那个转发层。这个转发层就是不少人默认在用的Cloudflare，而它对大模型网关有一个非常出名的限制：源站响应等待上限100秒，常用可用端口也被锁死在80/443。
这篇文章就是那次排障过程的完整复盘。我会从域名、端口、超时三个角度拆开讲，为什么Cloudflare这套链路对大模型网关来说处处别扭，为什么最终换到OCI免费L7云负载均衡器以后问题彻底消失，以及换网关过程中要避开哪几个隐形坑。文章适合两类读者：一类是自建大模型API服务、正琢磨怎么把入口层从缓存型边缘服务换成更适合长耗时接口的开发者和运维朋友，另一类是已经踩了超时坑但还没定位到问题根源的人。
1. 大模型网关的“入口”为什么比业务代码更容易踩坑
1.1 网关入口的三层博弈：域名、端口、转发
大模型网关和普通网站有个非常不一样的地方：它不是一个“给人看”的页面，而是一个“给程序调用”的API端点。普通网站慢一点、缓存一下，用户还能忍受；API网关一旦出现连接断开、响应超时，客户端会直接报错，如果下游没有做好重试退避，还容易把源站打挂。
一个自建模型网关对外提供服务，至少要打通三层：
- 域名层：决定客户端用什么地址访问，涉及DNS解析、TLS证书、可能的区域就近接入；
- 端口层：决定流量进入源站时走哪个TCP端口，以及公网到源站之间的映射关系；
- 转发层：决定域名和端口之间的连接是否被中间设备接管、改写，甚至主动掐断。
很多人第一反应是“用Cloudflare”，因为免费、配置快、自带证书。但对大模型网关来说，Cloudflare恰恰是这三层里最容易出问题的一层。它不是不好，而是它的产品定位是给“以毫秒为单位的网页流量”设计的，不是给“以分钟为单位的长时推理流量”设计的。
1.2 端口折中方案看着能用，实际处处别扭
先说端口。Cloudflare的反向接入层在前面，免费层基本只放行80/443。如果你的模型服务监听的是8080、18080、9000这种端口，要么改端口，要么在Cloudflare里折腾各种转发规则把流量引进去——但不管哪条路，本质上都是在“迁就边缘设备的限制”，而不是按需设计架构。
我见过不少项目被端口问题逼得做各种折中：把多个服务塞到同一个443端口下，用路径来区分 /v1/chat、/v2/embedding、/admin。表面看能跑，但很快会遇到几个问题：
- 路径路由规则越堆越多，改一处路由就要重新发布网关配置；
- 某些服务依赖独立端口做回调、健康检查或debug接口，路径方案覆盖不了；
- 证书统一挂在443下，多域名、多证书场景切换时非常别扭。
不是说这种方案一定不行，而是它把“架构问题”转化成了“规则管理问题”，长期维护成本很高。真正的大模型网关往往同时要接SSE流式输出、WebSocket语音、普通REST推理，理想状态是每个服务都能自由选择端口和路径，而不是被入口层卡住。
1.3 三层问题的交叉点：超时才是真正的导火索
如果说端口问题只是添堵，超时问题就是引爆点。Cloudflare对HTTP请求有一个硬限制：从请求到达边缘节点，到源站返回响应，等待上限是100秒。这个限制在普通网站上几乎无感，因为绝大多数页面请求3秒内就完事了；但大模型推理恰恰相反，一个稍微复杂一点的生成任务动辄几十秒，碰上长上下文模型，100秒根本不够用。
所以最后走向OCI免费L7负载均衡器，不是“为了换而换”，而是因为域名、端口、超时这三个问题，只有L7负载均衡器能同时解开。它不做缓存，不抢端口，空闲超时还可以自己调，正好补上了大模型网关最缺的那块拼图。
2. Cloudflare 100秒超时对大模型网关的“精准打击”
2.1 限制到底卡在哪一个环节
先说清楚这个100秒限制的准确含义。
客户端发出的HTTPS请求会先到Cloudflare边缘节点，边缘节点再与你的源站建立连接。Cloudflare默认等待源站“完成响应”的最长时间是100秒。如果一个POST请求发到你的推理服务，模型算了110秒才返回结果，那么在100秒时Cloudflare就已经判定这次请求超时，给客户端回一个错误响应，同时切断和源站的连接。源站那边可能还在继续算，算完发现连接已经被拔了，这就是典型的“源站日志显示成功、客户端却报错”的场景。
再补充一个容易被忽略的点：SSE流式输出也有类似的雷区。SSE协议要求服务端每过一段时间就往客户端推数据、保持连接活跃。如果模型推理过程中有某个阶段“停顿”了很长时间——比如触发了工具调用等待入参、上下文太长正在整理压缩——导致100秒内没有任何响应字节推给Cloudflare边缘，同样会被掐断。这类问题尤其隐蔽，因为本地直连源站测试时一切正常，套上Cloudflare之后才开始出现。
2.2 大模型网关里最容易触雷的三种流量
我在排障过程中总结了三种最容易撞上100秒限制的流量类型：
| 流量类型 | 典型场景 | 触发原因 |
|---|---|---|
| 非流式长推理请求 | 客户端关闭流式，等最终结果整体返回 | 源站整体响应时间超过100秒 |
| SSE流式推理中的停顿 | 模型在工具调用、长上下文整理时暂停输出 | 单次数据帧间隔超过100秒 |
| 批量处理/离线任务接口 | 批量向量化、批量精排、长文档分析 | 单次后端处理时间超过100秒 |
这里面最坑的是第二种。很多人测试SSE时只测“稳定输出”的场景，数据一帧接一帧地推，永远测不出问题。但真实用户的使用习惯不是这样，他们会让模型写代码、调插件、琢磨半天再出结果。只要停顿超过100秒，连接就会断。用户看到的就是“AI回复到一半就断了”，他理解不了，只会觉得你的服务不稳定。
2.3 把超时调成参数，是方向性错误
遇到超时，第一反应往往是“把连接超时调大一点”。客户端fetch加个timeout=120，Nginx把proxy_read_timeout调到600，FastAPI设置keep_alive更长——这些操作在纯源站链路上确实有效，但在Cloudflare后面全部失效。原因很简单：超时发生在Cloudflare边缘节点，它位于你的Nginx和客户端之间。你在源站把超时调得再大，边缘节点到100秒照样掐线。
这不是参数问题，是链路问题。链路中间有一个你控制不了的设备，而且这个设备又不通融，那就只能换一条没有这个设备的链路。这是我从这次排障里得到的最重要的一条结论，也直接决定了后面的选型方向。
3. 完整排障链路：从“怀疑后端”到“锁定边缘节点”
3.1 现象：连接总在80到100秒之间断
先说现象。出问题的网关后面挂着一个兼容OpenAI接口的推理服务，用户调用时，只要生成逻辑比较长，连接就会在80到100秒之间断开。当时收到的报错非常杂：有人的Python requests看到的是Connection reset by peer；有人用OpenAI SDK，看到的是TimeoutError；还有一部分用户走的是WebSocket通道，反而一切正常。
最有意思的一点是，WebSocket不受影响。Cloudflare对WebSocket的处理走的是独立的升级通道，和普通HTTP请求的转发策略不同。所以WebSocket正常反而成了一条重要线索：连接断开不是源站的问题，而是HTTP转发层的问题。
3.2 证据链：源站日志正常，客户端确实断了
接下来我把后端日志和网关访问日志拉出来对了一遍。源站那边清清楚楚记着请求200完成，耗时104秒、106秒、112秒不等；网关也记录了转发完成。但客户端这边的错误时间戳全都落在请求发起后的100秒附近。两边一对比，结论已经八九不离十：源站服务没有问题，连接是在中途被某个中间设备掐断的。
为了进一步验证，我临时把网关绑到一个源站IP上，让用户绕过域名解析直接IP访问。这一试，问题彻底显形：同一批大请求，直连IP全部正常返回。那会儿我还没法断定是Cloudflare还是DNS，但已经把范围缩小到“公网域名链路”这一层了。
3.3 锁定：用直连IP和不接边缘服务的域名做对比
最后做了一个更严谨的对比测试：三个入口，同一个请求：
- 入口A：域名走Cloudflare边缘节点，结果100秒断；
- 入口B：直接访问源站IP，TLS用源站证书，结果正常；
- 入口C：用另一个不套边缘服务的域名指向同一源站，结果正常。
入口A断、B和C都通，这就等于把故障精确锁定在了Cloudflare的边缘转发层上。后来我在Cloudflare的官方文档里确认了100秒限制的说明，和现象完全吻合。到这里，排障阶段算是画上了句号，接下来就剩选型和迁移了。
3.4 经验：排超时问题，永远先回答“谁先断的”
这次排障给我最大的经验是：遇到超时，先不要着急改代码。先回答三个问题：断的是哪一侧？中间有没有不受控的设备？源站日志和客户端错误时间戳能不能对得上？把这三个问题回答完，基本就能定位方向。如果一开始就埋头改后端超时参数，很可能几天都找不到真正的根因。
4. 从Cloudflare到OCI免费L7负载均衡器：方案对比与决策逻辑
4.1 CDN边缘和L7负载均衡器的本质区别
不少人觉得，负载均衡器不就是CDN的另一种叫法吗？还真的不是。CDN的核心职责是缓存和就近分发，设计目标是让静态资源离用户更近；而L7负载均衡器的核心职责是流量分发、健康检查、SSL终止、会话保持，它不缓存你的响应，来了请求就转发给后端，后端返回什么就是什么。
对大模型网关而言，缓存几乎没有意义——模型推理结果是动态生成的，每个请求都不同，缓存反而容易出脏数据。真正需要的是一个“稳定、透明、超时可调”的转发通道。L7负载均衡器正好干的是这件事。
至于OCI的免费L7负载均衡器，则是另一个层面的好消息：Always Free资源里就包含弹性负载均衡器实例，个人开发者和小团队完全可以把模型网关架到公网而不产生额外费用。
4.2 OCI免费层能覆盖的边界
具体来说，OCI Always Free套餐里可用的是一个Flexible Load Balancer，官方标称带宽在10Mbps这个级别（以控制台实际额度为准），对大模型API网关这种以少量长连接为主的场景是够用的。免费额度里通常还能包含一两台小型虚拟机，意味着你可以在同一个网络区域里把“负载均衡 + 源站”整个拓扑都搭起来。
需要说清楚的是，这个方案适合的规模是：小团队、个人开发者、内部工具、Demo项目。如果你要扛每秒几百上千的高并发，那还是上付费实例更稳妥。但对于“把大模型网关从Cloudflare的100秒限制和端口锁死里解放出来”这件事，免费层完全够用。我用下来的体感是：个人项目和大模型灰度验证，它比我预想的稳定得多。
4.3 为什么说它是“终极破局”
我把两个方案放在一起对比：
| 对比项 | Cloudflare方案 | OCI L7 LB方案 |
|---|---|---|
| 等待源站响应上限 | 100秒，企业版才可调长 | 可自行配置，默认空闲超时300秒，建议调至600秒以上 |
| 可用端口 | 免费层基本只放行80/443 | 任意端口，Listener和后端端口可互相映射 |
| 缓存/改写响应 | 有，可能引入脏数据 | 无，纯转发 |
| 后端真实IP | 容易被改写，需要额外配置 | 默认保留原始IP |
| 运维心智负担 | 边缘规则多、限制多 | 普通负载均衡器，行为直观 |
结论很清楚：Cloudflare是一个优秀的边缘服务，但它真的不是为长耗时API设计的；而OCI的免费L7负载均衡器本质上就是一台“透明转发机器”，端口自由、超时可控、不缓存不介入，这才是大模型网关想要的入口层。
5. OCI免费L7负载均衡器的落地步骤：迁移实录
5.1 整体架构从“三明治”变成“透明通道”
迁移前：
客户端 → 域名DNS解析 → Cloudflare边缘节点 → 源站（推理服务）
迁移后：
客户端 → 域名DNS解析 → OCI公网负载均衡器 → 源站（推理服务）
这轮迁移只动DNS记录和入口层，源站侧完全不动，所以风险可控。整个过程可以分步执行，出问题随时可以切回旧链路。
5.2 创建负载均衡器的最小配置
在OCI控制台创建负载均衡器，我路过的最小配置是这样：
- 在“网络”菜单下找到“Load Balancers”，点击“创建负载均衡器”。
- 选择类型为Layer 7 Load Balancer（应用负载均衡器）。
- 选择Always Free对应的弹性配置。
- 网络规划时，建议放在和源站同一个VCN或能路由到源站的子网，这样后端通信走内网，不占用公网带宽。
- 添加Listener：协议选HTTP或HTTPS，端口按需填，比如我用了一个非标准端口做灰度验证。
- 配置后端集（Backend Set）：指向源站的内网IP和实际监听端口。
- 配置健康检查：路径指向一个稳定的检查接口，超时和间隔先用默认值，跑稳了再调。
后端集里有个容易被忽略的点：后端端口不用和监听端口一致。监听端口是外网访问用的，后端端口是源站实际监听的，比如源站监听8080，Listener监听443，把两者通过后端集映射起来就行。端口自由的目标就是这样实现的。
5.3 超时参数调整：把空闲超时拉到600秒
OCI负载均衡器默认的空闲超时通常是300秒，这已经比Cloudflare的100秒宽裕不少，但大模型推理场景下，300秒也只是“够用”。我把Listener上的空闲超时调整到了600秒。
这里的“空闲超时”含义是：如果连接上一段时间没有任何数据传输，LB就会主动关闭连接。大模型网关的SSE流式输出通常不会真的空闲太久，但模型在思考阶段确实可能出现停顿，所以给足600秒是合理的推荐值。如果你还要跑更重的离线批处理，可以按需再往上调。
需要注意，不同服务商控制台上的参数名称可能不一样，有的叫Idle Timeout，有的叫Keepalive Timeout。配置前先确认自己调的是监听器级别的网络空闲超时，而不是后端池的重试超时，别调反了。
5.4 域名和证书的处理
后面要做的是把DNS从Cloudflare切到OCI LB的公网IP。我先把原本指向Cloudflare的A记录改成LB的IP，TTL调短一些，切完观察一段时间再调回正常TTL。
证书方面，我建议在OCI LB上做SSL终止，证书可以用自有域名的正式证书，也可以先生成一张自签证书用于联调。做了SSL终止之后，源站可以继续走HTTP，证书管理集中到LB这一层，对源站的改动降到最小。如果你后续要做更复杂的双向TLS，再单独调整。
5.5 验证清单
最后是验证。我实测的目标很明确：长请求超过100秒不断、SSE流式输出稳定、WebSocket升级正常、真实IP能传到后端。简单列一下验证动作：
- 用一个需要110秒的非流式推理请求压一次，确认能正常返回；
- 用SSE请求触发一次超过100秒的思考停顿，确认连接不会被掐；
- 建立一条WebSocket长会话，保持一段时间，确认心跳和断线重连正常；
- 看后端日志，确认收到的是真实客户端IP而不是LB的内部地址。
全部通过，迁移才算真正完成。
6. 上线OCI LB后，四个隐形坑比配置本身更值得注意
6.1 健康检查只探路径不探业务
我在源站上写了一个/health接口，只返回ok。LB的健康检查一旦探测到HTTP 200，就把流量放进去。但真正的模型服务可能因为显存不足、模型没加载、API进程卡死而处于“假死”状态。如果只依赖基础健康检查，LB会在某台后端假死时仍然分配流量，用户就会突然遇到一堆超时或者5xx。
建议健康检查的探针接一个业务级接口，这个接口返回的内容可以包括：进程存活、依赖服务状态、模型是否已加载、显存余量。虽然是个人项目，这个动作也能减少很多半夜被叫醒的机会。
6.2 SSL终止位置决定后续扩展空间
我把SSL终止放在LB上，源站用HTTP。好处是证书管理集中、源站不用管TLS。但代价是：如果以后要在源站和客户端之间做双向TLS，或者需要源站自己判断TLS握手阶段的信息，LB终止会让你拿不到原始TLS握手上下文。所以做这个选择时要想清楚未来会不会有这类需求，不要单纯为了省事就全堆在LB上。
6.3 WebSocket升级和SSE的监听器配置差异
OCI L7 LB对WebSocket支持得不错，基本上是开箱即用，只要监听器协议配成HTTP或HTTPS，LB会识别Upgrade请求并建立长连接。SSE也类似，因为SSE本质上是普通HTTP响应带上text/event-stream。但有两点要记住：一是在监听器里确认WebSocket支持已开启，不同版本的控制台开关位置不太一样；二是SSE的空闲超时和WebSocket的空闲超时可能各自独立配置，不要只改HTTP的idle timeout就以为万事大吉。
6.4 别忽略后端连接保持
这个问题在压力测试时会突然爆发。客户端到LB、LB到源站，是两段独立的TCP连接。如果后端服务的连接池没有开Keepalive，每条请求都重新建TCP连接，高并发下源站的TIME_WAIT连接会堆积得非常快。反正我在源站的Web服务里开了Keepalive，并把keepalive_timeout设置得比LB的空闲超时短一些，防止连接被LB先关掉，导致源站频繁收到被动的连接重置。
迁移之后的体感
这次迁移过后，我已经把所有新项目的大模型网关默认改成“域名解析到OCI免费L7负载均衡器”的打法了。Cloudflare那100秒的限制不是Bug，而是它的产品设计取向，对网站来说合理；但大模型API网关不归它管，硬套迟早出事。如果你也遇到“源站日志正常、客户端却断连”的问题，建议顺着域名、端口、超时这条链路排查，大概率能少熬一个凌晨班。最后再分享一个小技巧：迁移前把健康检查接口写成业务级接口，切换DNS后的第一个请求，直接打到健康检查接口上看链路通没通，比看一堆业务日志高效得多。
