Cloudflare负载均衡健康检查需配置Monitor并绑定到Pool，核心是确保Webman监听0.0.0.0、提供轻量/health接口返回200、关闭debug、统一Redis共享session，使后端“无状态、轻量、收敛”。
Webman 本身不处理全球流量调度，也不内置 DNS 层负载能力；真正实现「全球加速 + 故障转移 + 多地域容灾」的，是 Cloudflare 的边缘网络和负载均衡器（Load Balancing），Webman 只需作为后端 HTTP 服务稳定运行即可。关键不是“Webman 怎么配 Cloudflare”，而是“怎么让 Webman 成为 Cloudflare 负载均衡器可健康探测、可平滑接管的合格后端”。
Cloudflare 负载均衡必须指向 Webman 的真实 IP 和端口
Cloudflare 不会直接代理你本地开发用的 127.0.0.1:8787，它只能把流量发到公网可访问、有固定 IP（或弹性 IP）的服务器上：
- 确保每台部署
Webman的服务器都有独立公网 IP，且防火墙放行你配置的监听端口（如8787或自定义的8080） -
Webman必须监听0.0.0.0（而非仅127.0.0.1），否则 Cloudflare 的探测请求无法到达——检查config/server.php中的listen配置是否为'listen' => 'http://0.0.0.0:8787' - 若使用 Nginx 做反向代理（推荐生产环境），则 Cloudflare 应指向 Nginx 所在机器的 IP+端口，Nginx 再
proxy_pass到http://127.0.0.1:8787；此时 Cloudflare 的健康检查目标是 Nginx，不是 Webman 直连
Health check 路径必须返回 200 且响应极快
Cloudflare 默认每 30 秒对每个后端发起一次 GET / 健康检查，但 Webman 的根路径可能触发完整路由、中间件甚至数据库连接，导致超时或误判宕机：
- 在
app/controller下新建一个轻量控制器，例如HealthController.php，只返回纯文本OK且不走任何中间件 - 在
config/route.php中添加一条最简路由：Route::get('/health', [app\controller\HealthController::class, 'index']); - 在 Cloudflare 仪表板的 Load Balancing → Pools → Edit Pool 中，将
Health check path改为/health，Expected status codes设为200 - 避免用
/ping或/status这类常见路径——某些扫描器会高频请求，可能被 WAF 误拦截，干扰健康检查
Webman 必须关闭调试模式并禁用敏感信息暴露
Cloudflare 是面向公网的入口，若后端 Webman 仍开启 debug => true，错误页会泄露路径、环境变量、数据库配置等，极易被利用：
- 确认
config/app.php中'debug' => false已生效（上线前务必检查） - 删除或重命名
.env文件中的敏感字段（如DB_PASSWORD），或改用系统环境变量注入，避免文件被意外读取 - Cloudflare 的 WAF 规则（如 “PHP Injection”、“Information Disclosure”）默认会拦截含
var_dump、phpinfo、__FILE__等关键词的响应体——但依赖 WAF 拦截不如源头关闭更可靠 - 若用 Docker 部署，确保
Dockerfile或docker-compose.yml中未挂载本地.env到容器内，或使用secrets注入
Session 共享不能依赖本地文件，必须用 Redis 或数据库
Cloudflare 负载均衡会把用户请求随机分发到不同地区的 Webman 实例，如果 session 存在本地磁盘，第二次请求落到另一台机器就彻底丢失登录态：
立即学习“PHP免费学习笔记（深入）”；
- 启用
Redis作为 session 驱动：安装ext-redis，在config/session.php中设'handler' => 'redis'，并填好host、port、database - 不要用
memcached代替——Webman 官方 session handler 对 memcached 的兼容性弱于 Redis，易出现 key 冲突或过期异常 - 若必须用数据库存 session，请确保所有 Webman 实例连接的是同一个 MySQL/PostgreSQL，并在
session.php中正确配置表名与连接池 - 检查
session.cookie_domain是否设为顶级域名（如.example.com），否则跨子域（如api.example.com和www.example.com）无法共享 cookie
health 接口卡在数据库连接上，或 session 配置漏了一台机器，结果整个池被标记为不可用。运维的复杂点永远藏在“一致”二字里——配置一致、环境一致、健康检查逻辑一致。 
