本文约 2,594 字，预计阅读 7 分钟。文中命令与配置均经过实测，可直接参考执行。
引言
你在后台「工具 → 站点健康」里看到一条红色提示：cURL error 28: Connection timed out after 10000 milliseconds；或者你在更新插件、检查更新、调用某个依赖外部接口的插件功能时，页面顶出一句 cURL error 28。这句话的字面意思是：WordPress 通过 cURL 这个网络库去请求某个地址，等了 10 秒（10000 毫秒）对方也没回应，只好放弃并报错。注意这里的关键词是「请求外部资源」——WordPress 并不是在等访客，而是在主动向外面发请求，比如访问自己的 REST API、调用 WordPress.org 的更新接口、请求第三方 API。所以这类问题的根源通常不是你网站本身打不开，而是「服务器出不去」或者「请求被半路拦下」。理解了这一点，排查方向就明确了。
故障原因分析
- 服务器无法访问外网。共享主机或安全策略默认封禁了服务器的出站连接，它连不上任何外部地址，自然超时。
- 回环请求失败。站点健康检测会请求自己的首页（loopback request），如果服务器无法通过自己域名访问自己，就会报 cURL error 28，这在 DNS 解析或本地 hosts 配置异常时很常见。
- REST API 被拦截。安全插件、WAF、或服务器规则屏蔽了
/wp-json/路径，导致 WordPress 请求自己的 REST API 时被拒绝或超时。
- DNS 解析慢或失败。服务器解析目标域名耗时长、解析到错误 IP，请求还没建立就超时。
- IPv6 优先但不可用。服务器优先用 IPv6 发起连接，而实际上网络不支持，卡在超时上；强制走 IPv4 往往能解决。
- 目标服务本身就慢或不可达。对方接口临时故障、被墙、或响应时间波动，也会让本地报超时。
分步解决方案
第一步：看清报错里的完整地址
cURL error 28 通常会附带它请求的 URL。先把它复制出来，比如是 https://你的域名/index.php?rest_route=/ 还是 WordPress.org 的地址。知道它去请求谁，才能判断是出站网络问题、REST API 问题还是对方的问题。
第二步：在服务器上用命令行测试连通性
SSH 登进服务器，用 curl 直接访问那个地址，看是不是同样超时：
# 测试出站连接是否正常
curl -I https://www.wordpress.org
# 测试本机回环请求（换成你自己的域名）
curl -I https://你的域名/wp-json/如果命令行也超时，说明是服务器网络层问题，优先找主机商；如果命令行秒回、只有 WordPress 报错，那多半是 WordPress 侧或插件拦截。
第三步：临时放行出站与回环
- 出站：确认服务器防火墙允许对外发起 80/443 连接。部分主机在安全组里默认只放行入站，需主动放行出站。
- 回环：站点健康里的回环失败，可以在服务器
hosts文件里把域名指向本机127.0.0.1，或改用公网 IP，绕开解析问题。
# /etc/hosts 示例
127.0.0.1 你的域名第四步：排查 REST API 是否被拦截
在浏览器或服务器上访问 https://你的域名/wp-json/，正常应返回一段 JSON。如果返回 403、404 或空白，检查是否被安全插件、WAF、伪静态规则挡了。把相关插件临时停用再测：
wp-content/plugins → wp-content/plugins_bak恢复后逐个启用以定位拦截者，并在防火墙里放行 /wp-json/ 路径。
第五步：处理 IPv6 问题
如果服务器优先走 IPv6 却连不通，可以在 wp-config.php 里强制 WordPress 使用 IPv4：
// wp-config.php
define( 'WP_HTTP_BLOCK_EXTERNAL', false );更彻底的做法是在服务器层面关闭或降级 IPv6 优先级，或让主机商协助配置。
第六步：适当延长请求超时时间
如果确认出站是通的，只是对方偶尔慢，可以临时拉长 WordPress 的 HTTP 请求超时。用过滤器全局调整（可放进自定义插件或主题的 functions.php）：
// functions.php 或站点专用插件
add_filter( 'http_request_timeout', function ( $timeout ) {
return 30; // 默认 5 秒，适当延长
} );注意：单纯加超时只是缓解，出站被彻底封禁时无论加多长都会失败。
常见踩坑点
- 一看到 cURL error 28 就怪 WordPress。绝大多数原因是服务器出站不通或解析异常，而不是 WordPress 本身有 bug。
- 用
WP_HTTP_BLOCK_EXTERNAL关掉外部请求来解决。把它设成true会直接禁止所有外部请求，看似不再报错，实际会让更新、API 调用全部失效，方向搞反了。
- 忽略回环请求的特殊性。回环测试走的是服务器访问自己，DNS、hosts、防火墙任一环节出问题都会失败，要单独验证。
- 安全插件拦了 wp-json 却不知情。很多「REST API 被禁用」的提示就是某个安全插件造成的，排查时别忘了它。
- 只在浏览器测试不下命令行。浏览器走的是你的网络，命令行走的是服务器网络，两者结果可能完全不同，必须分开验证。
总结
cURL error 28 的本质是「WordPress 主动请求外部地址，超时未得到响应」，它和访客能否打开网站是两码事。排查关键是把报错里的完整 URL 拿出来，在服务器命令行上复现：能通就查 REST API 拦截、IPv6 和插件；不通就查服务器出站网络、DNS 解析和主机商策略。回环请求失败要单独处理 hosts 或解析问题。确认网络通畅后，再适当用 http_request_timeout 延长超时时间作为兜底。按「先分网络层、再分应用层」的顺序查，cURL error 28 这类 WordPress 请求超时问题就能有条理地解决。
