企业官网建设流程全解析

最近在和几个做 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. 核心能力速览

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 账户，并且域名已经托管到 Cloudflare，DNS 记录显示为橙色云朵（代理开启状态）。
• 一台可以运行 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-service：

cloudflared 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 服务的监听端口。最后启动 Tunnel：

cloudflared tunnel route dns ai-service ai.example.com cloudflared tunnel run ai-service

Tunnel 进程稳定运行后，访问 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, json=payload, headers=headers, timeout=120) 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", json=payload, timeout=300 ) 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(target=worker, daemon=True).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_starttransfer：

curl -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. 常见问题与排查方法

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 服务才算真正稳定接入。