最近在和几个做 AI 应用的朋友交流时反复遇到同一个现象模型接口本身没问题本地推理也正常但只要把服务挂到 Cloudflare 后面就会出现各种奇怪的拦截、超时、误判。有人把它叫做“The Cloudflare AI Psychosis”——不是说 Cloudflare 出 bug 了而是 Cloudflare 在 AI 时代面对全新流量特征时原有的安全策略和流量管理机制开始出现“精神分裂式”的表现一边在大力推 AI 相关产品一边又在后台把 AI 请求当成爬虫或恶意 Bot 拦掉一边要求开发者把 AI 服务接入 CDN一边又因为严格的 Bot 管理模式导致 AI 客户端无法正常访问。这篇文章不讨论 Cloudflare 的商业模式只讲实际工程问题当你的 AI 服务部署在本地或自建服务器并通过 Cloudflare 对外提供访问时会遇到哪些典型的“AI 精神病”症状以及怎么定位、怎么配置、怎么验证。先给结论这类问题多数出在 Bot Management、WAF 规则、防火墙规则和超时限制上。最直接的排查入口是 Cloudflare 后台的 Security - Bots把 Bot 管理模式从“严格”调低或者为可信的 AI 调用方配置白名单规则一般能解决 80% 的 403 和误拦截问题。但调整之前需要先弄清楚你的 AI 流量长什么样不然容易把防护全部关掉反而把源站暴露出去。本文会从现象出发拆解 Cloudflare 在 AI 流量场景下的管理机制然后给出一套从环境准备、部署接入、Bot 配置到接口验证的完整流程最后附上常见问题排查清单。如果你正在做本地 AI 服务的公网接入、API 网关搭建或批量推理任务这篇文章可以直接作为操作参考。1. 核心能力速览能力项说明项目类型Cloudflare 安全策略与 AI 流量的冲突分析、配置优化指南核心关键词Cloudflare、AI、Bot Management、WAF、本地部署、接口 API、批量任务主要功能识别 AI 请求被误拦截的原因、调整 Bot 管理模式、配置防火墙规则、验证 AI API 可达性适用平台Cloudflare Web 控制台、Cloudflare API、自建 AI 推理服务器推荐环境任意 Cloudflare 账户Free 版即可测试、一台可运行 AI 推理服务的服务器或本地电脑显存需求不适用于 Cloudflare 本身源站 AI 服务按模型规格配置需以实际推理环境为准启动方式Cloudflare 控制台配置 / cloudflared Tunnel 启动 / 源站服务进程启动是否支持 API支持Cloudflare 自身提供 API 管理规则源站 AI 服务也可通过接口访问是否支持批量任务支持但长时间推理任务需处理代理超时限制建议改造成异步任务适合场景本地 AI 服务公网化、自建 API 网关、ComfyUI/Stable Diffusion WebUI 远程访问、TTS/OCR 服务接入使用边界涉及人脸、声音、版权素材时必须确认授权不得利用镜像或代理绕过平台限制2. 适用场景与使用边界2.1 适合谁用这个方案适合三类人第一类是自建 AI 推理服务的开发者。本地跑着 Stable Diffusion WebUI、ComfyUI、TTS 模型或 OCR 服务想让朋友或团队通过域名直接访问不想暴露服务器 IP。第二类是做 AI 应用的运维人员。服务已经容器化部署希望通过 Cloudflare 做 DNS 管理、CDN 加速、WAF 防护和安全访问控制。第三类是研究 AI 流量特征的工程师。想搞清楚为什么同一套服务放在 Cloudflare 后面会间歇性 403、502为什么 AI 客户端的请求会被当成 Bot。2.2 能解决什么问题通过本文的配置流程可以解决AI 客户端访问 Cloudflare 域名时返回 403 或被 JS Challenge 卡住。Cloudflare Tunnel 能连通但批量推理任务请求经常超时。API 接口在直连时正常、走 Cloudflare 后出现连接重置。Bot Fight Mode 开启后导致 AI 请求被当作爬虫拦截。本地 AI 服务无法安全暴露到公网缺少访问控制和日志审计。2.3 不适合什么场景如果你只需要在局域网内使用 AI 服务完全不需要 Cloudflare 接入如果模型推理单次耗时就超过代理层超时上限又不想改成异步任务那么直接暴露源站或使用内网穿透才是更现实的选择如果只是临时测试模型效果也没必要先搭 CDN 再验证功能。2.4 合规与安全边界这里必须强调任何通过 Cloudflare 暴露的 AI 服务都不能用于生成违反法律法规的内容。涉及真人肖像、他人声音、受版权保护的素材时必须确认已经获得合法授权。Cloudflare 只提供网络层和安全策略内容合规责任在服务提供方。不要在配置时因为图省事关闭所有防护否则你的源站 IP 很容易被扫描到进而被攻击。3. 理解“Cloudflare AI Psychosis”的成因3.1 AI 流量的行为特征与爬虫相似从 Cloudflare 的视角看AI 流量有很多和恶意爬虫相似的特征高频请求、间歇性重试、非浏览器 User-Agent、缺少 Cookie 和浏览器指纹、请求路径往往是 /api/generate、/v1/chat/completions 这类接口地址。当 Bot Management 模式设为“严格”时Cloudflare 会主动拦截这些“非人类”请求导致 AI 客户端拿不到响应。这不是 Cloudflare 故意针对 AI而是它的分类器把 AI 调用误判成了攻击流量。3.2 安全策略与 AI 产品线的目标冲突Cloudflare 一方面推出了 AI Gateway、Workers AI 等产品鼓励开发者把 AI 应用构建在 Cloudflare 生态里另一方面传统的 Bot 防护体系面向的是浏览器流量和网站访问对 API 型 AI 流量的容忍度并不高。这种产品目标和安全策略之间的张力就是“Psychosis”这个词的来源。它会表现为同一个请求直连源站 200走 Cloudflare 后就变成 403同一个 API Key昨天还能用今天被限流同一套代码换一个网络环境就出现验证码。3.3 “严格”模式下的三种典型症状从实际反馈看Bot 管理模式为“严格”时最典型的表现有三种一是 API 接口返回 403页面提示“Sorry, you have been blocked”。二是 AI 客户端连接超时或 SSL 握手失败。三是网页端正常但脚本和 SDK 调用全部失败。对于这三种症状最优先处理的方向是去 Cloudflare 后台看一眼 Security - Bots 的日志确认请求是不是被 Bot 管理模块拦截的然后再决定是调整模式等级还是添加白名单规则。3.4 不只是拦截问题还有超时和缓存除了 Bot 误判Cloudflare 作为反向代理还会带来两个容易忽略的问题。第一个是超时限制。反向代理一般不会无限等待源站响应长时间运行的推理任务很容易触发代理层超时表现出来就是“请求发出去后一两分钟自动断开”。第二个是缓存副作用。如果源站返回的响应头没有做好 Cache-Control 控制Cloudflare 可能会把动态生成的 AI 结果缓存下来导致第二次请求拿到的是旧数据。JSON 接口有时候还会被压缩和缓冲影响流式输出。理解这些成因后下面的配置步骤就有针对性了。4. 环境准备与前置条件4.1 硬件与系统要求Cloudflare 配置本身不挑硬件你只需要有一个浏览器能登录控制台。源站 AI 推理服务的硬件要求由具体模型决定这里只给通用检查项显卡驱动和 CUDA 版本符合推理框架要求。GPU 显存不低于模型最低要求具体以模型文档为准。磁盘剩余空间足够存放模型权重和输出结果。如果使用 CPU 推理需要接受更长的单次推理耗时。4.2 软件与账户准备开始之前确认以下东西已经就绪一个 Cloudflare 账户并且域名已经托管到 CloudflareDNS 记录显示为橙色云朵代理开启状态。一台可以运行 AI 推理服务的服务器或本地电脑建议 Linux 系统Windows 也可以。域名解析权限能够添加 A 记录、CNAME 记录或配置 Cloudflare Tunnel。本地已经安装 Python、Node.js 或推理服务所需的运行时环境。如果使用 Tunnel 方式需要安装 cloudflared 客户端。4.3 网络与端口检查在接入 Cloudflare 之前先确认源站服务能通过本机 IP 访问。比如本地跑了一个 7860 端口的 WebUI 服务先在本机执行curl http://127.0.0.1:7860能正常返回 HTML 或 JSON再继续下一步。不能访问的话先排查服务启动状态和端口监听ss -lntp | grep 7860接下来决定接入方式。本文建议优先使用 Cloudflare Tunnel因为不需要开放源站入站端口安全性更高。5. 本地 AI 服务通过 Cloudflare 接入公网5.1 方式一Cloudflare Tunnel 接入本地服务Tunnel 方式不需要公网 IP也不需要改路由器端口映射适合本地部署的 AI 服务。安装 cloudflared 后登录账户创建 Tunnel然后把域名流量转发到本地端口。先安装 cloudflared。以 Linux 为例常见安装方式如下# Debian/Ubuntu 安装 cloudflared命令以官方文档为准 wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 chmod x cloudflared-linux-amd64 sudo mv cloudflared-linux-amd64 /usr/local/bin/cloudflared登录 Cloudflare 账户cloudflared tunnel login登录完成后创建一个 Tunnel名字可以叫 ai-servicecloudflared tunnel create ai-service然后创建配置文件一般放在 ~/.cloudflared/config.yml内容模板如下tunnel: ai-service credentials-file: /home/you/.cloudflared/tunnel-id.json ingress: - hostname: ai.example.com service: http://127.0.0.1:7860 - service: http_status:404这里把 ai.example.com 替换成你实际管理的域名把 7860 替换成你 AI 服务的监听端口。最后启动 Tunnelcloudflared tunnel route dns ai-service ai.example.com cloudflared tunnel run ai-serviceTunnel 进程稳定运行后访问 https://ai.example.com 就能进入本地 AI 服务。这种方式源站不需要向公网开放任何入站端口安全性明显更好。5.2 方式二DNS 代理接入已有公网服务器如果你的 AI 服务已经运行在一台有公网 IP 的服务器上也可以直接通过 Cloudflare 的 DNS 代理接入。在 Cloudflare 控制台添加一条 A 记录IP 填源站公网地址代理状态保持橙色云朵开启源站端口保持实际服务端口。这种方式配置快但源站 IP 有被扫描的风险建议在源站防火墙只允许 Cloudflare IP 段的流量访问。Cloudflare 官方发布了自己的 IP 范围列表运维时需要定期更新白名单。5.3 先直连验证再走代理无论使用哪种方式都要在接入 Cloudflare 前先验证源站本身的可用性。接入后如果异常可以用以下命令做基础连通性测试curl -I https://ai.example.com curl -X POST https://ai.example.com/api/generate \ -H Content-Type: application/json \ -d {prompt: test}第一次测试建议从最简单的不带鉴权接口开始确认链路通不通再逐步加入复杂参数。6. 核心配置调整 Bot 管理策略解决 AI 请求误拦截6.1 Cloudflare 后台入口登录 Cloudflare 控制台选择你的域名进入左侧菜单 Security - Bots。这里可以看到 Bot Fight Mode、Bot Management 模式、以及被拦截请求的日志。“The Cloudflare AI Psychosis”最典型的现象就出现在这里Bot 管理模式的等级越高对 AI 流量越不友好。如果请求被拦截Bots 页面会显示 blocked 记录点开可以看到命中原因。6.2 从“严格”调整为合适等级如果你的 AI 服务是给特定用户或自己使用的推荐把 Bot 管理模式从“严格”调整为“不拦截”或“仅检测”并在防火墙规则中手动限制访问来源而不是完全依赖 Bot 分类器。如果服务需要开放给外部用户更好的方式不是关闭 Bot 管理而是添加白名单规则允许特定的 User-Agent、IP 段或请求特征绕过 Bot 检测。在 Cloudflare 控制台的 Security - WAF - Custom Rules 中创建规则示例如下规则名称Allow AI Client匹配条件User Agent 包含 ai-client 或 IP 位于可信 IP 段动作Skip - Security Level / Bot Fight Mode优先级放在拦截规则之前以 Cloudflare API 方式创建规则时请求体结构大概如下实际字段需要参考官方 API 文档{ action: skip, action_parameters: { ruleset: current, rulesets: [ http_request_firewall_managed, http_request_firewall_custom ] }, expression: (http.user_agent contains \ai-client\ and ip.src in {192.0.2.0/24}), description: Allow trusted AI client requests, enabled: true }注意这段 JSON 是通用模板字段名和规则集名称要以 Cloudflare 官方接口文档为准不同的套餐能用的规则集也不同。6.3 别把所有防护都关掉在排查问题时把 Bot Fight Mode 临时关掉是可以理解的但排查完一定要恢复。更好的做法是保留全局防护在规则层面放行可信来源。这样即使 AI 请求的 User-Agent 被识别为“非浏览器”也不会被拦截而其他未知来源的恶意爬虫依然会被挡住。6.4 确认规则生效配置完成后用实际 AI 客户端再发一次请求然后回到 Bots 页面看请求记录。如果状态变成 allowed说明规则已经生效。如果还是 blocked检查规则优先级和匹配条件或者打开 Cloudflare 的 trace 页面查看请求命中了哪条规则curl https://ai.example.com/cdn-cgi/trace返回的 cf-ray、loc、ver 等字段可以帮助定位请求走到了哪个节点是否触发了安全策略。7. 功能测试与效果验证7.1 本地 AI 服务基础连通性测试先把源站服务和 Cloudflare Tunnel 都启动然后执行curl -s https://ai.example.com/cdn-cgi/trace如果能看到 cf-ray 信息说明 DNS 解析、CDN 节点、Tunnel 链路都通了。7.2 文生图或图像类服务验证假设你的源站是 Stable Diffusion WebUI 或 ComfyUI验证流程建议按下面的顺序第一步打开 https://ai.example.com确认页面能正常加载。第二步在界面里输入一个简单提示词比如“a red apple on a wooden table”设置低分辨率 512x512、步数 15 到 20点击生成。第三步观察是否出现 403 或 502。第四步如果生成成功再尝试一次高分辨率或批量生成观察稳定性。预期结果是图片正常返回并且第二次请求不会出现缓存旧图。7.3 TTS/OCR 类服务验证如果你的服务是 TTS 或 OCR重点测试以下场景TTS准备一段短文本生成语音检查响应格式和音质。OCR上传一张包含文字的图片返回识别结果。长文本或 PDF 解析注意请求时间和代理超时如果超时考虑改成异步任务。7.4 流式输出验证如果是大模型对话 API流式输出是一个常见需求。Cloudflare 反向代理对流式响应有缓冲行为可能出现“前面内容迟迟不来最后一次性输出全部”的情况。验证时可以使用 curl 观察响应到达时间curl -N https://ai.example.com/v1/chat/completions \ -H Content-Type: application/json \ -d {model: test-model, stream: true, messages: [{role: user, content: hello}]}如果发现流式响应被缓冲可能需要调整源站响应头确保不经过代理缓冲或者通过 Cloudflare 规则关闭缓冲。这个功能在不同套餐中的支持程度不同需查阅官方文档确认。7.5 判断成功与否的标准判断一次功能验证是否通过建议看四个指标第一HTTP 状态码是否为 200/201而不是 403/502/504。第二请求耗时是否在可接受范围内没有出现固定时间点断开。第三输出内容是否完整且没有乱码或截断。第四连续多次请求是否稳定没有明显失败率。8. 接口 API 与批量任务8.1 通过 Cloudflare 域名调用 AI API本地 AI 服务接入 Cloudflare 后外部系统可以通过 HTTPS 域名直接调用 API不需要知道真实服务器 IP。这里给一个通用的 Python 调用示例适用于多数 POST 类型的推理接口import requests url https://ai.example.com/api/generate headers { Content-Type: application/json, Authorization: Bearer your-token-here } payload { prompt: test prompt, max_tokens: 512, temperature: 0.7 } try: response requests.post(url, jsonpayload, headersheaders, timeout120) print(Status Code:, response.status_code) print(Response:, response.text) except requests.exceptions.Timeout: print(Request timeout: 检查 Cloudflare 超时限制或任务耗时) except requests.exceptions.ConnectionError as e: print(Connection error:, e)需要注意retries 和 timeout 需要根据你的模型服务调整。如果单次推理超过 Cloudflare 代理层限制请求会被断开这时要么缩短推理时间要么改用异步任务。8.2 批量任务设计和代理超时应对批量任务在 Cloudflare 后面会遇到一个现实问题长时间执行的请求不稳定。如果每张图片或每段文本处理时间很长建议不要直接用同步 API 循环调用而是设计成“提交任务 查询结果”的异步模式。简单方案是维护一个本地任务队列import time import uuid import requests from queue import Queue from threading import Thread task_queue Queue() task_status {} def worker(): while True: task_id, payload task_queue.get() try: resp requests.post( https://ai.example.com/api/generate, jsonpayload, timeout300 ) task_status[task_id] { status: done if resp.status_code 200 else failed, result: resp.json() } except Exception as e: task_status[task_id] {status: failed, error: str(e)} finally: task_queue.task_done() Thread(targetworker, daemonTrue).start() def submit_task(payload): task_id str(uuid.uuid4()) task_queue.put((task_id, payload)) task_status[task_id] {status: pending} return task_id def get_result(task_id): return task_status.get(task_id)这个示例不是 Cloudflare 官方的方案而是一种工程上通用的异步任务模式实际使用时要根据你的源站服务做调整。8.3 失败重试建议批量任务遇到偶发的 403 或 502 时不要无限重试。建议采用指数退避第一次失败后等 1 秒重试。第二次失败后等 2 秒。第三次失败后等 4 秒。最多重试 3 到 5 次。重试仍然失败记录下来等待人工处理。同时所有请求都打印出 cf-ray 和 status code这样排查时可以快速定位是源站问题还是 Cloudflare 策略问题。9. 资源占用与性能观察9.1 源站资源占用观察本地 AI 推理服务通常消耗 GPU 显存和 CPU。在服务运行期间用下面的命令观察资源状态nvidia-smi htop如果显存占用异常升高说明并发请求过多需要限制并发数如果 CPU 占用过高说明使用的是 CPU 推理或数据预处理瓶颈在 CPU。9.2 Cloudflare 侧的请求观测Cloudflare 控制台的 Analytics 页面可以看到请求量、缓存命中率、安全事件。如果发现请求在“安全事件”里被拦截优先去 Security 事件日志中查看规则命中情况。9.3 网络延迟和请求耗时对比接入 Cloudflare 后通常会有少量的网络延迟增加但因为 CDN 节点通常离用户更近有些场景下实际感知反而更快。如果对比直连和代理的响应时间可以使用 curl 的 time_total 和 time_starttransfercurl -o /dev/null -s -w time_total: %{time_total}s\ntime_starttransfer: %{time_starttransfer}s\n https://ai.example.com这个指标能帮你判断代理层的额外耗时但不能完全代表源站推理耗时因为推理耗时才是大头。9.4 如何降低代理层对性能的影响一个有效的做法是把静态资源前端 JS、CSS、图片交给 Cloudflare 缓存把动态推理请求完全绕过缓存。配置规则时对包含 /api/ 的路径设置 Cache Level 为 Bypass避免 AI 生成结果被缓存。另外源站服务尽量开启 HTTP/2 或 HTTP/3在 Cloudflare 控制台的 Speed - Optimization 中确认相关协议已经启用。10. 常见问题与排查方法问题现象可能原因排查方式解决方案访问域名返回 403 blockedBot 管理模式过严看 Security - Bots 日志调整模式或在 WAF 规则中放行可信来源请求返回 502 Bad Gateway源站服务未启动或 Tunnel 断连检查源站端口和 cloudflared 进程重启源站服务或 Tunnel长时间推理任务断开代理层超时或连接不稳定观察断开时间点改异步任务或缩短单次处理时间流式输出不实时代理缓冲了响应观察首字到达时间调整响应控制头或关闭缓冲第二次请求拿到旧结果AI 输出被缓存检查响应头中的缓存字段对动态路径设置绕过缓存非浏览器请求被 JS Challenge 拦截安全级别过高查看安全事件日志将 API 路径加入跳过规则或降低安全级别批量任务偶尔失败限流或连接被重置查看任务日志和 cf-ray增加指数退避重试页面能打开但接口不通防火墙规则只针对部分路径放行对比页面和接口请求记录统一调整规则使 API 路径同样放行cloudflared 启动报错配置 YAML 格式错误或凭证路径不对查看启动日志按模板重新配置并确认 credentials-file 路径源站 IP 被扫描源站防火墙未限制来源查看源站访问日志只允许 Cloudflare IP 段访问源站11. 最佳实践与使用建议11.1 先小流量验证再放开第一次接入 Cloudflare 时先用单个请求验证链路不要直接跑批量任务。确认 403、超时、缓存三个问题都不存在后再逐渐增加并发。11.2 保留一套直连入口用于排查即使接入了 Cloudflare也建议保留服务器本地的直连入口用于故障定位。当公网域名异常时先在本机 curl 源站接口判断问题出在源站还是代理层。当然直连入口本身要限制访问来源只能从可信 IP 或内网访问。11.3 目录与配置管理AI 服务的模型文件、输入素材、输出结果建议分目录管理~/ai-service/ models/ inputs/ outputs/ logs/ config/日志统一输出到 logs 目录方便排查批量任务失败原因。Cloudflare 侧的规则变更记录尽量用版本化描述避免改完忘记之前设置过什么。11.4 安全基线不能省接入 Cloudflare 不代表源站就安全。建议做四件事第一源站防火墙只放行 Cloudflare IP。第二AI API 必须加鉴权不能裸奔。第三涉及上传和生成的接口要做大小限制和内容校验。第四定期检查 Cloudflare 安全事件日志看有没有异常来源尝试访问 API。11.5 合规与授权提醒如果通过 Cloudflare 暴露的是图像生成、声音克隆、数字人这类 AI 服务必须做到只处理已获得授权的素材不传播涉及他人隐私的内容不生成违规或侵权内容对外商用前确认模型权属和素材版权。Cloudflare 只负责网络层转发内容层面的法律责任由使用者承担。12. 总结与下一步“The Cloudflare AI Psychosis”不是 Cloudflare 的单个 bug而是传统 Bot 防护策略与 AI 流量特征之间的系统性冲突。最有价值的做法不是关闭所有防护而是理解 Cloudflare 判定逻辑通过 Bot 管理模式调整、WAF 规则白名单、缓存策略和异步任务模式让 AI 服务既稳定又可管控。如果你正在被这个问题困扰建议先做一次最小化验证把源站服务启动好用 Cloudflare Tunnel 接入然后把 Bot 管理模式从“严格”调整为“仅检测”测试一个最简单的 API 请求。能通再考虑批量任务和高并发不能通就看请求是被安全规则拦截还是被代理超时切断对照上文的排查表逐步定位。后续可以继续扩展的方向包括用 Cloudflare Workers 做 API 聚合和缓存、通过 Access 做更细粒度的身份认证、把批量任务改造成消息队列模式、对长时间推理任务增加任务状态查询接口。每一步都不复杂关键是不要把 Cloudflare 当做一个透明的转发层它实际上是一个会对流量做判断和干预的安全边界。理解它的判断逻辑你的 AI 服务才算真正稳定接入。