如果你部署过大模型网关大概率遇到过这种诡异场景本机 curl 一切正常用户那边一把长文本丢进来几十秒后页面开始转圈再等一会儿直接报错。查网关日志没异常看上游模型也没问题最后把矛头指向入口处的 Cloudflare——原来所有走了代理模式的请求源站必须在 100 秒内给出完整响应否则 Cloudflare 直接甩给你一个 524流式输出和长推理全被卡死在半路。更难受的是你想换端口绕一绕Cloudflare 代理模式又只认那么几个端口白名单自定义端口根本走不通。这篇文章就从我实际踩过的这一整圈坑说起先梳理大模型网关场景下域名、端口、超时三者的纠缠关系然后说清楚 Cloudflare 100 秒限制和端口折中为什么治标不治本最后给出我在用的终极方案——用 Oracle Cloud 免费层Always Free的 L7 云负载均衡器把网关接出去域名照常解析TLS 照常终止超时上限拉高到远超模型推理耗时而且不花一分钱。1. 先看清痛点大模型网关请求链路里的“三座大山”1.1 网关、域名、端口、超时四个字背后是三座不同的山大模型网关说白了就是一层统一代理。你写一个 App不想让用户直接面对 OpenAI、Anthropic、Gemini 这些五花八门的 API也不想把供应商的 Key 暴露在前端更不想每个接口各自为政地做限流、计费、日志。于是你就把请求收拢到一个网关服务上由它帮你路由、鉴权、重试、记录。常见的有 One API、LiteLLM Proxy也包括 FastGPT、Dify 这类知识库平台自带的模型网关模块。网关本身是个普通 HTTP 服务监听在某个端口上。但就是这个“普通 HTTP 服务”一旦要放到公网上给人用立刻牵扯出三个层面的问题域名能不能稳定解析到入口公网入口的端口能不能和现有服务共存以及从客户端到网关再到上游模型的整条链路上超时设置会不会把长请求掐断。这三个问题看着独立实际彼此咬合你为了让 Cloudflare 能代理就得把端口迁到白名单里你把端口迁了又发现 100 秒响应限制让模型推理活不下去你想绕过 CF 代理又犹豫域名解析和防护怎么处理。这就是为什么很多人折腾了一两周最后发现根本不是配置写错了而是方案本身选错了对象。1.2 一条请求从客户端到模型推理到底要过几道“闸门”我画一条实际链路你就明白为什么超时是“层层设卡”。用户的浏览器或 App 首先发起 DNS 查询解析出入 口 IP请求到达 CDN 或负载均衡器这台入口设备再把请求转发给网关服务网关需要判断该路由给哪个上游模型然后向供应商 API 发起新的 HTTP 请求最后模型开始推理把 Token 一个个吐回来再原路返回。每一层都有超时政策。比如你客户端可能设置了 20 秒超时CDN 可能设了 100 秒网关到上游模型可能设了 60 秒上游模型自己又可能因为队列拥堵让你等待几十秒。这些超时不是简单的“取最小”而是每一层都可能在某个时刻主动断开一个“看起来没动静”的连接。大模型请求的特殊性恰恰在于它是真的可能长时间“没动静”——比如复杂任务里模型在思考或者工具调用链很长或者长上下文的预填充计算很慢。这时候被误杀几乎是必然的。1.3 为什么“100 秒”对大模型尤其致命很多人刚开始觉得100 秒够长了不会踩到。但干过之后就会意识到大模型推理和网页请求完全是两种形态。网页请求讲究的是“快速拿到完整 HTML”1 秒内最好大模型推理是“用户发一段 5000 字上下文让它写一篇长分析”光是预填充和注意力计算就可能超过 30 秒再开始逐 Token 输出一段非流式的长回答轻易能拖到两三分钟。更别说接了工具调用的 Agent 场景模型可能先去调用外部 API花几十秒等结果再继续生成。非流式请求超过 100 秒Cloudflare 会直接给你一个 524 状态码页面显示 “A timeout occurred”源站日志里却什么都没有因为请求根本没到源站是边缘节点先放弃了。流式请求稍微好一点因为连接在持续传数据但仍然要面对空闲超时模型思考的间隙如果超过阈值连接照样被切。实测下来SSE 流式在 Cloudflare 代理后面不是不能跑而是只要某个间隙稍微长一点客户端就会收到一个被强行终止的流前端表现就是“生成到一半断掉”特别恼火。这两个问题是所有想用 Cloudflare 当大模型网关入口的人必须正面面对的。2. Cloudflare 代理模式看似优雅实则“端口折中”全是不甘2.1 代理模式下的 100 秒超时是怎么把你掐断的Cloudflare 代理模式的工作原理是客户端先连到 Cloudflare 边缘节点边缘节点替你回源。这个模式的核心问题在于它把“源站给出完整响应”的时间上限卡得死死的。免费版账户就是 100 秒从边缘节点向源站发起连接、源站开始返回数据、直到完整响应结束整个过程必须在 100 秒内完成否则边缘节点直接断开并返回 524。这个限制对静态网站和轻量 API 完全够用但对大模型网关就是灾难。我说个实际数字有一次我让网关走 CF 代理请求是一个长上下文总结任务模型预填充用了大概 50 秒生成用了 80 秒总耗时长过 100 秒结果客户端拿到 524而网关和模型那边其实早就把结果算完了只是回传的时候被边缘节点抛弃了。流式场景也没有想象中乐观。很多教程说“SSE 一直有数据就不会断”但真实情况是如果模型在某个中间环节思考了超过空闲超时阈值的时间CF 一样会断开连接。而且 CF 免费版对流式传输的缓冲策略并不透明有时你明明在持续输出 Token客户端却要隔很久才收到一批体感上就非常卡。大模型网关要的是“连接能活多久我说了算”而 CF 代理是“连接能活多久边缘说了算”这两者天然矛盾。2.2 端口白名单导致的选择困难为什么“换端口”是下下策Cloudflare 代理模式还有一个隐藏限制它只对有限的端口做代理解析。常见的 HTTP/HTTPS 白名单端口包括 80、443、8080、8443、2052、2082、2083、2087、2096 等其他端口即使你的源站监听没问题CF 也不会帮你转发。这就逼着人做“端口折中”。最常见的折中是把大模型网关从默认的 3000 端口改成 443 或 8080让 CF 能代理。但问题来了一台机器上往往不止一个服务Nginx 占了 443博客占 80或监控面板占了 8080端口冲突立刻爆发。你开始犹豫到底是把博客挪走还是让网关换到 8443换完之后客户端那边 SDK 又需要重新配地址真是一动牵全身。另一种折中是套一层 Nginx 反代用路径区分比如/api转给网关其他转给网站。但加了这一层等于在链路上多了一个超时控制点Nginx 的proxy_read_timeout默认只有 60 秒又得去改改完还要考虑日志、错误页、缓存问题。还有方案是走 Cloudflare Tunnel把本地服务通过隧道暴露出去但问题在于 Tunnel 的流量最终也经过 CF 边缘节点免费计划下的连接管理同样不宽松而且你多了个常驻进程要守护隧道本身也是一层新的排障盲区。这些方案能跑通但每一次“折中”都在增加系统的复杂度和不可控性。2.3 我为什么最终不再把 Cloudflare 代理作为网关入口兜兜转转之后我的结论很明确CF 代理适合“短请求、高缓存、重防护”的网页类场景不适合“长连接、长耗时、需要精确控制超时”的模型网关场景。也有一个折中方案就是把 CF 记录切成“仅 DNS”模式也就是常说的灰云。这样域名解析仍然由 Cloudflare DNS 负责但流量不经过 CF 代理直接解析到你的源站 IP。这个方案能彻底绕开 100 秒限制和端口白名单但代价也很明显源站 IP 暴露CF 自带的 CDN 缓存和 Web 防护基本失效。既然防护都不要了那 CF 在这条链路里的意义就只剩下“一个好用的 DNS 面板”。你可能会想那不如直接找一个能当公网入口的东西替你把流量分发、TLS 终止、超时管理都包了——这才是我转向云负载均衡器的最根本动机。3. 破局思路为什么选 OCI 免费 L7 云负载均衡器3.1 OCI 免费层到底送了啥L7 负载均衡器好在哪Oracle Cloud 的 Always Free 免费层里除了大家熟悉的 Ampere A1 ARM 实例4 核 24GB 内存和两台 AMD 微型实例之外还有一项经常被忽略的资源一个 Flexible Load Balancer也就是弹性负载均衡器。它默认附带 10 Mbps 的带宽额度支持公网访问而且只要你不超规格费用就一直是零。这个免费 LB 对大模型网关来说简直像量身定做的入口层。负载均衡器分 L4 和 L7 两层。L4 只会做 TCP/UDP 转发理解不了 HTTP 语义L7 则能解析 HTTP能做基于路径和主机名的路由、健康检查、会话保持、TLS 终止。对网关来说L7 的意义很大因为你可以在同一个公网入口上把/api路径的请求分给网关后端把/blog或/admin分给其他服务不用改端口、不用加 Nginx端口冲突问题直接从架构层面消失。3.2 它凭什么能绕过 Cloudflare 的限制先把三套方案的对比列出来你一眼就能看明白选型逻辑维度Cloudflare 代理模式Cloudflare 仅 DNS灰云OCI L7 负载均衡器100 秒响应限制有源站超 100 秒返回 524无无空闲超时可调大端口白名单只代理固定端口列表无限制无限制公网 IP 上端口自定流式 SSE/WebSocket存在空闲超时与缓冲风险无 CDN 介入空闲超时可控TLS 终止边缘终止源站自己处理LB 上终止DDoS/缓存能力强基本无基础云防火墙健康检查费用免费版可用免费版可用Always Free核心区别在于OCI LB 是放在“源站前面”的流量分发器它不是第三方代理不会在你的连接中间偷偷加一道 100 秒的期限。你把公网入口交给 LBLB 把连接转给后端网关中间的空闲超时完全由你配置。默认值确实很保守但你可以拉到很大足以覆盖大模型的长推理和流式思考间隙。当然也要提一个门槛免费 LB 的带宽只有 10 Mbps换算下来约 1.25MB/s。对大模型网关的文本流式输出来说这个数字是绝对够用的——即使你一秒生成 50 个 Token每个 Token 平均两三个字节也就几百字节每秒几百人同时远程调用都压不垮这条带宽。但如果你打算通过这个入口传输音频、图片、大文件那就要提前评估负载了免得高峰期带宽被打满。3.3 架构设计OCI LB、域名、网关如何摆布迁移完成后的架构大概是这样的api.example.com的 A 记录指向 OCI LB 的公网 IP用户访问时请求先到 LB 的 443 端口LB 用监听器规则做 TLS 终止再根据路径把请求转给 VCN 内网里的网关实例比如内网 IP10.0.0.5:3000网关再去请求上游模型 API。如果你还想继续用 Cloudflare 管域名只需要把api.example.com的记录类型切成“仅 DNS”也就是灰云让 DNS 解析到 LB 的 IP而不是让 CF 代理流量。这样你就同时拿到了 Cloudflare 的稳定 DNS 和 OCI LB 的灵活超时策略两边优势都占住。如果连 DNS 都想省掉用任何一家域名注册商的 A 记录指向 LB 公网 IP 也是一样的效果。这套架构最大的好处是后端网关可以彻底脱离公网端口暴露。网关监听内网地址只有 LB 能访问它源站不像裸奔那样直接挂在公网上。域名、端口、超时三个问题的职责真正分清楚了域名只管解析LB 管端口和超时网关只管业务。4. 实操把 OCI L7 负载均衡器变成大模型网关的“长期入口”4.1 前期准备清单动手之前先把这几样东西备齐一个 Oracle Cloud 账号注册后进入免费层额度内即可一个已经创建的 VCN里面至少有一个公共子网一台跑网关的 Linux 实例比如免费的 Ampere A1 ARM 实例部署好 One API、LiteLLM Proxy 或类似网关服务一个域名以及域名 DNS 控制台的修改权限。网关这边我强烈建议在迁移之前就把监听地址改成0.0.0.0:3000让网关能接受来自 VCN 内部 LB 的连接。很多网关默认只监听127.0.0.1本机 curl 正常LB 后端健康检查却永远失败这个细节最容易被忽略。4.2 创建负载均衡器选型和基础配置登录 Oracle Cloud Console进入主菜单依次打开 “Networking” → “Load Balancers” → “Create Load Balancer”。创建向导里有几个关键参数可见性选择 “Public”因为你要接收公网请求Shape 保持默认的 “Flexible”这就是免费层支持的弹性规格带宽范围把最小和最大都设成 10 Mbps严格卡在免费额度内选择你的 VCN 和公共子网监听器协议按需选 HTTP 或 HTTPS端口设 80 或 443。创建过程中会要求至少配置一个监听器和一个后端集。如果还没有上传证书可以先建 HTTP 监听器端口 80等后续上传证书后再补一个 HTTPS 监听器并关掉 80。但如果你打算一步到位可以在向导里直接选择 HTTPS并上传证书。这里要提醒一句OCI LB 的监听器和后端集是在创建时绑定的后续虽然能改但没有经验的人容易在向导里跳来跳去。我的建议是先在纸上画清楚公网入口用 443 还是 80后端端口是多少健康检查路径是什么再进控制台填能少走很多弯路。4.3 配置后端集与健康检查后端集是 LB 和后端实例之间的桥梁。你在向导里创建后端集时需要指定协议为 HTTP后端端口填网关监听端口比如 3000。然后在“后端服务器”一栏把你的实例加进去填实例的私有 IP 和端口。健康检查是决定 LB 是否会继续转发流量的关键。协议选 HTTP路径写你的网关健康检查端点。LiteLLM 一类的网关通常有/health/liveness或/health/readinessOne API 之类的项目也可以自己加一个最简单的/health路由只要返回 200 就行。如果你实在不想改网关代码可以做个 Nginx 转发把/health直接固定返回 200。健康检查参数按常规设就行间隔 10 秒、超时 3 秒、重试 3 次。唯一要强调的是健康检查会使用和真实流量相同的后端端口如果你的网关只是监听了127.0.0.1健康检查从 LB 发起访问时就会失败后端状态一直显示“异常”这是发生率最高的初期问题。4.4 关键一步把监听器和空闲超时调到大模型友好的数值大模型网关能不能稳定长连接全看这一步。进入监听器详情页找到 “Connection idle timeout” 的配置项。这个值默认我记得相当保守通常只有几十秒到 300 秒左右对大模型场景不够用。我的建议是直接把它调到 900 秒也就是 15 分钟。如果 OCI 控制台允许填到 3600 秒那更好等于给连接留出了极大的余量。你可能会担心调太大了会不会导致连接挂着不释放其实不会因为到了这一层真正决定连接是否该断的是网关自身网关会做请求级别的超时控制LB 只是兜底不允许因为“闲着”就把正常连接掐了。这只是 LB 一层的超时。别忘了网关自身也要配合LiteLLM Proxy 的请求超时、One API 的请求超时设置都必须大于你 LB 的空闲超时习惯值否则网关掐掉的请求LB 怎么等都没用。比如你 LB 空闲超时设了 900 秒网关到上游的request_timeout却只有 60 秒那任何超过 60 秒的推理请求照样失败。最佳实践是网关超时 LB 空闲超时让最内层先判断要不要放弃。4.5 安全列表与 NSG端口开对否则一切白搭OCI 的 VCN 安全列表是有状态防火墙很多人在这一步翻车。你 LB 建好了监听器也配好了结果从公网一测端口就是不通十有八九是安全列表没放行。有两段规则需要设置。第一段是“互联网入站到 LB 子网”如果你用了 HTTPS 443就添加一条入站规则源 IP 填0.0.0.0/0目标端口 443。如果还临时用了 80也一并放行。第二段是“LB 到后端网关”在网关实例所在子网的安全列表里添加一条入站规则源地址填 LB 所在子网的 CIDR目标端口填 3000。这样做的好处是网关只对 LB 开放端口不直接暴露给公网。如果你更喜欢 NSG网络安全组可以把 LB 和网关实例分别加入两个 NSG通过 NSG 规则控制访问逻辑更清晰。配置完后用telnet LB公网IP 443或者本机nc -vz LB公网IP 443验证一下端口通不通。端口被占的问题也顺手排查一下登录网关实例执行netstat -tlnp确认网关真的监听了0.0.0.0:3000而不是127.0.0.1:3000。这里有个小常识如果看到0.0.0.0:80被某个进程占着并不是说“所有地址的 80 都被占死了”而是这个进程对任意网卡地址的 80 都接收连接你想再用具体 IP 绑 80 就会报 Address already in use。4.6 域名解析与 TLS 证书配置LB 创建完成后你会拿到一个公网 IP。如果控制台提示这个 IP 是临时的我建议直接创建一个“保留公网 IP”并分配给 LB防止重启或重新部署后 IP 变化导致域名解析失效。域名解析这边在 DNS 控制台添加一条 A 记录把api.example.com指向 LB 公网 IP。如果还在用 Cloudflare DNS记得把代理状态切成“仅 DNS”不要让云朵变橙。这一步做完你可以先通过curl http://api.example.com/v1/models验一次确认能通再升级 TLS。TLS 证书可以直接上传到 OCI LB。在监听器里选 HTTPS 并绑定证书LB 负责终止 TLS后端仍然走 HTTP。上传时要传完整的证书链也就是域名证书和中间证书拼在一起否则部分客户端会报证书链不完整。另外如果你同一个 443 端口还需要服务其他域名或路径OCI LB 也支持基于主机名和路径的路由规则这对“一台机器多个服务”的场景非常友好。4.7 端到端验证流式输出、长推理、超时表现全部配置完成后不要急着一把梭按顺序做三轮验证。第一轮普通请求。用 curl 请求网关的模型列表接口确认域名解析、TLS 握手、后端转发、健康检查全链路正常。第二轮流式输出。直接调用一个支持流式的大模型接口观察 Token 是否逐段返回。比如用 curl 加-N参数或者直接在代码里按 SSE 事件流逐行读取确认没有缓冲等待现象。第三轮也是最重要的一轮模拟超长推理。可以给模型出一个“请写一篇万字长文”这类的任务让请求必然超过 100 秒。这轮测试能直接验证你的超时配置是否生效。我在测试时故意让请求跑了 160 多秒CF 时代会果断报 524换到 OCI LB 后中间确实没有数据返回的几秒钟也没被切断直到模型最终生成完毕所有 Token 完整落到客户端。同步在 OCI 控制台看 LB 的指标和日志你会发现后端连接和响应码都正常这比之前 CF 时代“无法中断、无源站日志、无从查起”的体验强太多。5. 踩坑实录与问题排查速查表5.1 常见问题速查表我整理了一张速查表覆盖这套架构里最常遇到的问题按“现象、可能原因、解决方案”三列排开现象可能原因解决方案请求超过 100 秒被中断返回 524Cloudflare 代理模式触发响应限制把 CF 切成仅 DNS改用 OCI LB 入口LB 后端状态一直显示异常网关只监听了 127.0.0.1将网关监听地址改为 0.0.0.0 或内网 IP健康检查连续失败健康检查路径不存在或返回非 200新增/health路由或用 Nginx 固定返回 200外网无法连接到 443 端口安全列表未放行互联网入站添加入站规则源0.0.0.0/0端口 443LB 能通但转发后还是失败后端安全列表未放行 LB 子网到 3000 端口在网关子网加入站规则源设为 LB 子网 CIDR流式连接中途断掉LB 空闲超时太小或网关自身超时更短把 LB 空闲超时调到 900 秒以上同步调大网关超时TLS 握手报证书链错误只上传了域名证书缺中间证书拼接完整证书链后重新上传到 LB访问速度慢、偶发卡住链路 MTU 问题或客户端网络分片用ping -M do -s 1472测试路径 MTU排除分片故障5.2 三个“不算配置项”但很容易忽略的注意点第一个是网关和 LB 的超时必须配合调而不是只调一边。有人把 LB 的空闲超时拉到了 3600 秒结果网关到上游模型的超时还是 60 秒长请求照样失败。层级越靠内的超时应该越宽松否则外层等得起、内层先放弃了。第二个是不要踩 1024 端口的“特权感”。很多服务默认用 3000、8000、8080 这类高位端口听起来高端实际上在高位端口上更容易碰到安全列表、习惯性防火墙策略、CDN 端口白名单的层层限制。有了 LB 之后你完全可以把公网入口收敛在 443后端用 3000这是最不容易出错的组合。第三个是 OCI 的免费额度边界。Always Free 的资源虽然长期免费但不代表可以无限造。LB 的带宽固定在 10 Mbps如果你在上面跑大流量下载或高并发视频流很快会摸到天花板。大模型文本接口没问题但别把它当文件传输入口用。5.3 我从这个迁移里总结的几条经验回头来看这套迁移真正做的事情是把“网关能否被稳定访问”从碰运气变成了可配置的基础设施。Cloudflare 代理负责保护网页应用很合适但 API 网关这类长连接场景更适合一个自己能控制超时和端口策略的负载均衡层。迁移的过程中我也注意到很多人遇到端口冲突时第一反应是让服务改端口而不是换一个更合理的流量入口。实际上一台公网服务器上如果有多个服务正确做法是让云负载均衡器做 L7 分发按路径或子域名路由而不是把所有服务都挤在某个端口上互相迁就。这个思路不仅适用于 OCI 免费 LB也适用于任何云厂商的负载均衡产品。如果你现在还在被 Cloudflare 的 100 秒限制、端口白名单、网关超时三件事反复折磨我建议你按这个顺序试一遍先把网关跑在固定内网端口用 OCI 免费 LB 接出去域名解析到 LB 的 IP最后再把 Cloudflare 切成仅 DNS 模式。踩过这一圈之后你会发现链路反而变短了问题定位也更清楚了。至少对我个人来说把入口层换成云负载均衡器之后再也没出现过“请求明明算完了却死在半路”的玄学问题。