访客能打开网站，WordPress 后台却提示“您的站点无法完成回环请求”，并不矛盾。访客的浏览器和运行 WordPress 的 PHP 进程，可能使用不同的 DNS、网络出口和访问权限。网站对外可访问，无法保证服务器经由站点域名访问自身时也能成功。
排查要从站点健康给出的完整错误开始。DNS 解析失败、连接超时、HTTP 403 和重定向异常，分别对应不同链路。重装 WordPress、重启整台服务器或关闭全部防护，都会让定位范围变得更大。
本文针对自行管理的 Linux、Nginx/Apache 与 PHP 部署。托管主机没有终端权限时，也可以把错误原文、发生时间、站点域名和对应日志交给服务商。文中命令为示例，没有在读者的生产环境执行。
站点健康的回环测试在请求什么
WordPress 的回环请求，是服务端通过 HTTP 请求本站地址。它与网卡的 127.0.0.1 回环地址不能直接画等号。本站域名解析到公网 IP 或 CDN 时，请求就可能经过公网入口、负载均衡或 WAF。
核验时的 WordPress 核心实现中，WP_Site_Health::can_perform_loopback() 使用 site_url('wp-cron.php') 生成地址，通过 HTTP API 发送带测试参数的 POST，并检查请求错误和返回状态码。该实现使用 10 秒超时，携带当前 Cookie，也会在特定服务器变量存在时加入 Basic Auth 信息。[1]
核心源码解释了测试为何使用 POST：让 wp-cron.php 提前结束，避免在站点健康检查期间再次触发定时任务。这个检查与普通 WP-Cron 调度请求并不完全相同。[1] 不同 WordPress 版本和插件过滤器可能改变行为，判断时应以本站安装版本为准。
因此，首页 GET 成功、REST API 正常或系统 cron 已经配置，都不能单独证明站点健康的这次测试必然成功。反过来，一次回环告警也不足以认定全部定时任务都停止了。需要分别检查相关功能。
错误信息先分成连接失败和 HTTP 拒绝
保留后台的完整提示，包括错误码、状态码和时间。常见线索有以下几种。
Could not resolve host或 cURL 错误 6，优先检查运行环境的域名解析。Failed to connect或错误 7，检查目标地址、监听端口、出站限制和入口防火墙。Operation timed out或错误 28，可能卡在解析、连接、TLS 或应用处理；需要结合耗时和日志继续缩小范围。- 401、403、429，说明已经收到 HTTP 响应，应查 Basic Auth、WAF、限流和安全插件。
- 404、405 或异常跳转，检查 WordPress 安装路径、代理路由、请求方法和站点地址。
错误 28 不等于“服务器性能差”。目标 IP 不可达、IPv6 路径不通、防护挑战或应用处理阻塞，都可能消耗完超时时间。盲目延长超时会让后台等待更久，却不一定恢复功能。
从 PHP 所在环境检查 DNS 与网络
诊断请求要尽量来自 PHP 实际运行的环境。容器内 PHP、宿主机终端和管理员电脑，看到的 DNS 结果可能不同。下面的 example.com 必须替换为实际站点域名。
getent ahosts example.com
curl -sS -o /dev/null --connect-timeout 5 --max-time 15 \
-w 'code=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/
这条请求访问首页，用于观察解析结果与连接阶段，不会完整复现 WordPress 的 POST 测试。curl 的这些时间字段大多从请求开始累计计算，不能把它们当作各阶段独立耗时直接相加。[2]
如果同时配置 A 和 AAAA，可以分别观察 IPv4 与 IPv6。
curl -4 -I --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -I --connect-timeout 5 --max-time 15 https://example.com/
-I 使用 HEAD，部分应用对 HEAD 的处理不同于 GET；这里仅做连通性线索。IPv6 失败时，还要确认该运行环境是否本来就没有 IPv6 出口，不能据此立即删除域名的 AAAA 记录。
核对容器 DNS、宿主机解析、代理环境变量，以及服务器出站 443 策略。域名若指向公网负载均衡，还需检查服务商网络是否允许后端通过公网入口回访自身。公网地址回流受限时，可以评估内部解析或内部入口方案，但必须保留正确的域名、TLS 和路由语义。
把域名硬写到 127.0.0.1 只有在本机确实监听相应端口、虚拟主机匹配正确且架构允许时才可能适用。多节点、容器和 CDN 环境直接套用，会绕开必要链路，或者把请求送到错误服务。
HTTPS 和跳转需要按域名链路核对
检查 WordPress 地址与站点地址是否符合实际部署。WordPress 安装在子目录时，两者可以不同，不能为了消除告警强行改成相同值。配置中的 WP_SITEURL、WP_HOME 也可能覆盖后台选项。
若反向代理终止 HTTPS，而后端没有正确识别原始协议，回环请求可能在 HTTP 和 HTTPS、不同域名或不同路径之间循环跳转。先看每一跳的 Location，再核对代理信任与应用协议识别。
curl -sS -D - -o /dev/null --max-time 15 https://example.com/
这条命令不会自动跟随跳转。脱敏后的响应头可以帮助确认跳转目标，但不要把其中的 Cookie 或认证信息公开。
一个容易误判的细节是，在核验时的核心回环测试源码中，https_local_ssl_verify 过滤器的默认值为 false。[1] 这不代表所有 WordPress HTTP 请求都跳过证书验证，也不代表可以把所有回环故障归因于证书链。插件可能调整过滤器，其他请求也可能启用证书验证。
如果独立 curl 测试报证书错误，应修复证书域名、有效期、完整链或运行环境的 CA 信任。独立 curl 默认的证书校验行为，与这段核心回环实现可能不同。使用 curl -k 取得响应，不能作为 TLS 已修复的验收依据，更不应永久关闭全站 HTTP API 的证书校验。
需要比较 CDN 与源站时，curl 的 --resolve 可以在单次请求中指定 IP，并保留 URL 主机名供 Host 和 TLS 使用。[2] 示例中的 192.0.2.10 是文档保留地址，不能直接执行作为真实源站测试。
curl --resolve example.com:443:192.0.2.10 \
-sS -D - -o /dev/null --connect-timeout 5 --max-time 15 \
https://example.com/
测试仅限自己管理的源站。若源站只接受 CDN 回源、使用专用证书或要求额外认证，直连失败可能符合设计，不能为了测试把源站全面开放。
401、403 和 429 要追到具体拦截层
防护系统通常无法给 PHP 发出的请求完成浏览器交互挑战。站点登录保护、维护模式、安全插件和 CDN 机器人规则，都可能使回环请求收到拒绝响应。
按发生时间关联 CDN/WAF 事件、反向代理日志和 PHP 日志。优先回答两个问题：这次测试有没有到源站？拒绝响应由哪一层产生？如果 WAF 已拦截，源站没有访问记录并不奇怪；如果源站收到请求，再检查 HTTP 方法、路径、状态码与应用记录。
Basic Auth 需要特别核对。核心测试会尝试使用当前请求中的认证变量，但代理或 PHP 运行方式可能不传递这些变量。[1] 浏览器通过了密码保护，服务端发出的请求仍可能缺少认证信息。
允许规则应限定路径、方法、经过验证的请求来源及必要条件，并保留日志。不要只凭一个可伪造的 User-Agent 放行，也不要取消整个 /wp-admin/ 的保护。服务器经 CDN 回访时，源站看到的连接 IP 可能是 CDN 节点；PHP 的出站公网 IP 也可能与入站地址不同，IP 白名单需要按真实拓扑验证。
对 wp-cron.php 的限制还要兼顾实际任务调度。不能仅为通过站点健康测试开放 POST，却意外继续阻断业务所需的调度请求；也不能把“接口能返回 200”当作任务一定执行的证据。
终端成功时，继续比较 PHP 与 WordPress HTTP API
命令行 curl 能访问首页，只覆盖了部分链路。PHP-FPM 可能使用独立容器、不同的代理设置或安全限制；WordPress HTTP API 还会经过插件过滤器。[3]
检查 WP_HTTP_BLOCK_EXTERNAL、WP_ACCESSIBLE_HOSTS、WordPress 代理常量，以及安全插件是否通过 HTTP API 过滤器提前拒绝请求。应记录实际拒绝信息，不能看到“禁止外部请求”的常量就直接断定它阻断了本站回环。
请求已到源站却长时间没有响应时，再结合 PHP-FPM 日志、慢日志与进程池状态判断。有些部署中，后台请求等待自身发出的 HTTP 请求，而可用 PHP worker 已被耗尽，回环请求只能排队。此时增加请求超时可能加重等待；进程池容量也不能脱离内存预算盲目上调。
插件与主题的冲突测试宜在预发布环境进行，一次改变一个变量。如果只能在生产验证，应备份、安排低峰窗口，并评估停用插件对登录、支付和安全策略的影响。不要直接把“一键停用全部插件”当作常规首步。
确需调试日志时，按 WordPress 官方调试文档临时启用记录，关闭前台错误展示，并尽可能将日志放在非公开位置。[4] 日志可能包含路径、令牌或用户信息，排查结束后要恢复设置并按策略处理文件。
修复后的验收不止刷新一次后台
重新运行站点健康回环测试，并按相同时间核对响应和日志。若之前由防护规则拒绝，需要确认测试请求已按预期通过，同时其他未授权访问仍被阻止。
再检查本站实际使用的功能，例如定时文章、备份插件队列或编辑器相关操作。使用可控的测试任务，不要批量手动触发生产队列；站点健康返回成功，也无法证明所有插件任务都正常。
留存修改前后的解析结果、目标 IP、状态码和规则变更。回滚时恢复原 DNS/Hosts、代理、插件或防护设置，撤销临时诊断规则。若曾修改站点地址，需要确认前后台、子目录路径和资源 URL 仍然正确。
能够确认修复的证据应来自同一运行环境：PHP 发出的测试请求完成、相应功能恢复，以及必要访问限制仍然生效。管理员电脑能打开首页，只能证明浏览器这条访问链路正常。
参考资料
- [1] WordPress 官方：
WP_Site_Health::can_perform_loopback()，https://developer.wordpress.org/reference/classes/wp_site_health/can_perform_loopback/ - [2] curl 官方手册：write-out、IPv4/IPv6 与 resolve，https://curl.se/docs/manpage.html
- [3] WordPress 官方：
wp_remote_post()，https://developer.wordpress.org/reference/functions/wp_remote_post/ - [4] WordPress 官方：Debugging in WordPress，https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
资料核验日期：2026 年 11 月 5 日。核心实现以核验时官方参考及源码为依据，实际行为需结合本站版本、插件和部署方式判断。