生产服务器运行Chrome Lighthouse出现403 forbidden错误如何解决

Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Status code: 403)

• Cloudflare Bot管理/安全规则拦截：Lighthouse运行时的UA默认包含Chrome-Lighthouse标识，属于Cloudflare爬虫检测规则的常规拦截范围，同时无头浏览器的请求特征会触发Cloudflare的JS人机质询，Lighthouse无法自动完成验证就会返回403。本地和staging环境通常不会开启Cloudflare的严格生产级拦截规则，所以运行正常。
• AWS WAF规则拦截：如果生产环境AWS侧配置了Web应用防火墙，针对无头浏览器、异常UA的拦截规则也会拦截Lighthouse请求，触发403报错。
• 生产环境访问权限限制：如果生产站配置了IP白名单、HTTP基础认证、或者要求特定请求头/Cookie才能访问，Lighthouse默认发起的请求未携带对应鉴权信息，会被直接拒绝访问。
• Cloudflare安全等级设置过高：当Cloudflare安全等级调整为高/极高时，会对所有未验证的请求发起人机验证，Lighthouse的无头Chrome无法自动完成验证流程，直接返回403。

• Cloudflare侧配置调整
  • 首先进入Cloudflare控制台「安全」-「WAF」-「事件日志」，查询对应403请求的拦截原因，定位是规则拦截还是Bot检测拦截。
  • 新增WAF例外规则：匹配请求UA包含Chrome-Lighthouse的所有请求，设置为绕过WAF、Bot管理、速率限制等所有安全校验，无需降低全站安全等级。
  • 如果是固定IP运行Lighthouse，可以直接将该IP添加到Cloudflare的IP白名单中，所有来自该IP的请求都不会被拦截。
• AWS WAF侧配置调整
  • 进入AWS WAF控制台，查看生产环境Web ACL的拦截日志，确认是否存在对应Lighthouse请求的拦截记录。
  • 新增自定义允许规则，匹配UA包含Chrome-Lighthouse的请求直接放行，无需经过其他拦截规则校验。
• Lighthouse运行参数调整
  • 如果生产站配置了HTTP基础认证，运行时添加参数：--extra-headers "{\"Authorization\": \"Basic <base64编码的账号密码串>\"}"携带鉴权信息。
  • 可通过--chrome-flags="--user-agent='<普通桌面浏览器的UA>'"参数，将Lighthouse的请求UA伪装为普通用户浏览器，绕过UA层面的拦截。
  • 如果需要携带登录态Cookie或其他自定义请求头，都可以通过--extra-headers参数传入，保证请求和正常用户请求特征一致。
• 临时测试方案
  • 如果只是单次运行Lighthouse测试，可临时将运行Lighthouse的设备公网IP添加到Cloudflare和AWS WAF的白名单中，测试完成后再移除，不需要修改全局规则。

内容的提问来源于stack exchange，提问作者Byrisetti Hemanth