跨主机部署如何限制 FPM 访问来源?

跨主机部署意味着 Web 服务器与 FPM 不在同一台机器上，unix socket 不再是选项，限制访问来源只能靠“监听地址、客户端白名单、网络规则”三道闸门同时成立。PHP 官方手册明确警告，php-fpm 不应从不可信网络可达，因为能建立 FastCGI 连接的一方可以影响该请求所使用的配置，例如 auto_prepend_file，进而可能执行任意代码。跨主机场景恰恰容易把 FPM 推到网络上，配置一旦疏漏，暴露面会比单机部署更大。

先收紧监听地址与客户端白名单

FPM 池配置里，listen 不带地址的 9000 等价于监听所有地址。跨主机部署应绑定专用内网地址，而不是 0.0.0.0。仅绑定内网还不够，TCP 场景要设置 listen.allowed_clients，把允许的来源限定为 Web 服务器地址。该指令只在 TCP 下按来源地址限制客户端，不设置就不会做这层限制。若 Web 请求经过 NAT、反向代理或负载均衡，FPM 看到的来源可能不是原始 Web 主机，白名单要按实际拓扑填写，不能照搬示例。改完 reload 后，用 ss 查看实际监听，确认没有残留池仍绑在全部网卡。

网络层与编排层要同步收口

FPM 主机上的安全组或防火墙只放行 Web 主机到 FPM 端口，IPv6 规则尤其要核对，只改 IPv4 常留下另一半暴露。容器化部署时，宿主上的 ss 可能看不到端口，但 docker port 和端口绑定信息会显示是否发布到 0.0.0.0；跨主机容器间应走自定义网络和服务名，不发布到宿主。Kubernetes 要检查 NodePort、LoadBalancer 和 Ingress 是否把 FPM 端口带出去。Nginx 的 fastcgi_pass 必须指向 FPM 的内网地址，并与 listen 一致；不一致时站点可能直接 502，也可能上游指向另一台机器，让暴露面反而更大。

验证不能只看配置。从非授权主机做 TCP 连通性测试，预期拒绝或超时；从 Web 主机确认能建连。端口号不常见不构成访问控制，暴露面由绑定地址和网络规则共同决定。巡检时固定核对三项：listen 的当前值、外部可达性、fastcgi_pass 与 listen 是否一致。任何一项漂移，都可能让 FPM 重新可达。跨主机部署的限制不是一条配置能完成的，而是监听、白名单和网络规则持续保持一致。