wp-login耗时1分钟：CDN后的auth_basic如何在nginx中制造不可见的401循环

令人费解的症状

在对一个高流量新闻门户进行性能审计时，wp-login.php的缓慢是发现的第一个异常。通过浏览器测量的TTFB（首字节时间）约为1分钟。而直接用curl请求服务器，同一个请求只需2毫秒。

当localhost在2毫秒内响应而浏览器等待1分钟时，问题不在服务器，而在CDN与服务器之间的路径——或者服务器在请求经由CDN到达时的响应方式。

服务器技术栈：Docker容器中的nginx + PHP-FPM，无WAF，前置CDN。nginx通过set_real_ip_from和real_ip_header X-Forwarded-For从CDN请求头中提取访客真实IP。

acl.conf与satisfy any

调查指向了nginx中的WordPress配置文件。wp-login.php的location块包含了一个共享的访问控制文件：

# /home/developer/webserver/common/wpcommon.conf
location = /wp-login.php {
  include common/acl.conf;
  limit_req zone=one burst=1 nodelay;
  include fastcgi_params;
  fastcgi_pass php;
}

acl.conf文件内容：

# /home/developer/webserver/common/acl.conf
satisfy any;
auth_basic "Restricted Area";
auth_basic_user_file htpasswd-ee;
allow 127.0.0.1;
allow 172.28.5.0/24;
allow 198.51.100.0/24;
allow 10.0.0.0/8;
deny all;

乍看之下，配置似乎很合理：要么IP在白名单中（allow），要么访客提供有效凭证（auth_basic）。满足其一即可——这正是satisfy any的作用。

satisfy any在实践中的效果

nginx的satisfy any指令定义：如果配置的任意一种认证/授权机制被满足，则允许访问该location。在这个acl.conf的语境中：

如果IP在白名单中（allow）：无需密码即可访问。

如果IP不在白名单中：nginx返回401并请求基本凭证（auth_basic）。

如果访客在401后提供有效凭证：允许访问。

这个设计假设已知IP（管理员、办公室、VPN）直接进入，未知IP可以通过用户名和密码访问。当nginx看到的是访客真实IP时，这工作得很好。

问题所在：CDN不在白名单中

nginx配置了set_real_ip_from和real_ip_header X-Forwarded-For，从CDN发送的请求头中提取真实IP。当配置正确工作时，nginx在评估访问规则之前，会用访客真实IP替换源IP。

但两个测试之间有一个微妙的差异：

curl本地（127.0.0.1）： 不经过CDN直接连接到nginx。源IP是127.0.0.1，在白名单中。结果：2毫秒返回200。

浏览器经由CDN： CDN将请求转发到服务器。nginx通过X-Forwarded-For接收到访客真实IP——而这个IP不在白名单中。

nginx做了正确的事：识别出访客的真实IP。问题是访客的真实IP不在白名单中。于是返回401。

一个普通的401不应该导致1分钟的等待。超时出现是因为CDN收到带有WWW-Authenticate的401后，尝试进行认证协商——等待一个从未以预期格式到来的响应。用户看到的结果就是约60秒的TTFB，直到CDN放弃或转发错误。

对比：修复前后

通过比较两条路径可以直接验证这一行为：

# 直接测试服务器（绕过CDN）
curl -sv -o /dev/null -w "TTFB: %{time_starttransfer}s\n" \
  http://127.0.0.1/wp-login.php
# 结果：TTFB: 0.002s — HTTP 200

# 通过CDN测试（模拟浏览器）
curl -sv -o /dev/null -w "TTFB: %{time_starttransfer}s\n" \
  -H "Host: 示例客户.com" \
  https://示例客户.com/wp-login.php
# 结果：TTFB: ~1.083s — HTTP 401

CDN测试中的1.083秒已经比浏览器中的1分钟快，因为curl不等待认证协商——收到401后立即返回。而浏览器尝试渲染认证弹窗，在CDN处理响应期间持续等待。

修复方案

根据客户希望如何管理wp-login.php的访问，有三种方法：

方案一：将操作者IP添加到白名单

# acl.conf — 添加特定IP以实现即时访问
satisfy any;
auth_basic "Restricted Area";
auth_basic_user_file htpasswd-ee;
allow 127.0.0.1;
allow 172.28.5.0/24;
allow 203.0.113.45;   # 操作者/办公室IP — RFC5737示例
deny all;

适用于从已知固定IP访问的用户。对于使用动态IP或无VPN远程访问的用户无效。

方案二：如果保护来自插件则从wp-login移除acl.conf

# wpcommon.conf — 无acl.conf，保护委托给WordPress
location = /wp-login.php {
  limit_req zone=one burst=1 nodelay;
  include fastcgi_params;
  fastcgi_pass php;
}

适用于WordPress已有插件保护的情况（Limit Login Attempts、Wordfence等）。消除了导致冲突的双重认证层。

方案三：确认htpasswd-ee有有效凭证且客户有意使用auth_basic

某些情况下auth_basic是有意为之——客户希望对wp-login.php的任何访问在到达PHP之前都需要密码。此时解决方案是确认htpasswd文件有有效凭证，并且CDN配置为将基本认证转发给源站。

反模式：CDN与satisfy any的组合

satisfy any + auth_basic + IP白名单模式在直接访问的服务器上效果很好。当前面有CDN时会悄然失效，原因很具体：CDN通过少量出口IP集中访问源站。真实访客有一个IP，但nginx看到的是CDN的IP——或从X-Forwarded-For提取的真实IP，它很少与为内网IP创建的白名单匹配。

每当你在使用IP allow/deny的配置前放置CDN时，都需要重新审视访问规则。直接访问时有效的配置，经由CDN可能变得不可见或无法访问。

这个模式尤其危险，因为它不产生明确的错误。服务器用401响应，CDN正常处理，高TTFB看起来像性能问题——而非配置问题。不比较localhost与CDN的话，真正的原因永远不会浮出水面。

如何在其他服务器上诊断

# 1. 比较直接访问与CDN的TTFB
curl -sv -w "\nTTFB: %{time_starttransfer}s\n" http://127.0.0.1/wp-login.php
curl -sv -w "\nTTFB: %{time_starttransfer}s\n" https://your-site.com/wp-login.php

# 2. 检查CDN返回的HTTP状态码
curl -sv -o /dev/null https://your-site.com/wp-login.php 2>&1 | grep "< HTTP"

# 3. 查找nginx配置中的acl include
grep -r "include.*acl" /home/developer/webserver/ --include="*.conf"
grep -r "satisfy" /home/developer/webserver/ --include="*.conf"

# 4. 检查nginx在CDN请求中看到的IP
grep "wp-login" /var/log/nginx/access.log | tail -20
# 日志中的IP应该是访客真实IP，而非CDN的IP

如果通过CDN的HTTP状态码是401且TTFB很高，问题就是satisfy any在等待CDN的响应。如果nginx日志中的IP是CDN的IP（而非访客真实IP），说明set_real_ip_from未配置——真实IP永远不会到达allow/deny规则的评估环节。

这次事故的教训

wp-login.php的高TTFB通常被归咎于服务器过载、数据库缓慢或插件过重。这些是常见嫌疑——也因此真正的原因需要更长时间才能浮现。当localhost在2毫秒内响应而CDN需要1分钟时，服务器是无辜的。调查从代理配置层开始。

satisfy any不是一个bug，而是一个强大的工具，它预设nginx能看到真实的客户端IP。当前面有CDN时，这个前提可能会被打破——保护就变成了一个无声的拦截。