测试站的HTTP Basic访问保护与WordPress应用程序密码，可能都需要使用Authorization头。两套独立Basic凭据不能简单塞进同一个头；应识别代理和应用各自的认证要求，按受控方案选择访问路径。
先画出请求经过的认证层
确认浏览器或工具先到CDN、Web服务器还是直接到WordPress，记录每层返回的认证提示。HTML保护页面或WWW-Authenticate响应可能来自上游，并不是WordPress插件拒绝。不要因此把应用用户升级成管理员。
明确同一头承载的限制
HTTP Basic通常用Authorization携带一组用户名密码，WordPress应用程序密码也可通过Basic方式进行认证。让客户端轮流填写两组凭据，可能只是覆盖前一组，并不能完成两层独立验证。重定向还可能改变认证信息传递。
按需要设计受控接入
在测试网络、受限来源或提供方支持的其他认证方式中选择合适方案，确需例外时限制到明确路径与访问来源，并保留应用层认证。不能为了工具连接而将整个测试站公开，也不能在URL查询参数中传递管理员密码。
分别验证外层与内层边界
在受控环境确认未授权外部请求仍被拒绝，允许来源的工具能建立正确WordPress身份且仅做约定操作。记录代理是否转发所需头及当前条件。完成测试后回收临时例外，并检查测试站搜索限制和敏感资料仍受保护。
关键区别
HTTP访问保护：限制到达测试站；可能先于WordPress。
应用密码：建立站内身份；不替代外层策略。
Authorization头：承载所选认证；不能盲目叠两组Basic。
怎样确认处理到位
未授权来源仍不能访问测试站，受控工具身份与能力正确，必要认证头按设计传递，临时例外已经回收或有明确期限。
容易误判的边界
本文解释认证冲突，不建议将密码放进网址、关闭整站保护或使用不明代理绕过访问限制。
