Jenkins Windows节点无头Chrome运行时iframe无法加载问题求助

可能的原因及对应排查方向 #

• Chrome旧版无头模式的渲染逻辑差异
  你当前使用的是Chrome 90版本，该版本的旧无头模式（--headless参数对应模式）与有头模式的渲染、资源加载逻辑不完全一致，对跨域iframe、第三方cookie的限制规则更严格。你代码中的iframe加载的是第三方域名资源，无头模式下默认会拦截未授权的跨域资源请求，而你远程登录运行有头模式时，当前用户的Chrome配置默认允许该类请求，因此加载正常。
  Chrome 96及以上版本推出的新无头模式--headless=new已完全对齐有头模式的逻辑，可解决大部分此类差异问题。

• Jenkins运行账户的配置差异
  你远程登录Windows节点时使用的是普通用户账户，该账户下的证书信任配置、网络代理规则、防火墙白名单均已配置正常，可正常访问iframe的目标地址。但Jenkins Windows从节点通常以系统服务账户（如Local System）运行，该账户的用户配置、证书存储、网络规则与普通登录用户完全隔离，如果服务账户未信任iframe目标站点的证书、无对应网络访问权限，就会出现iframe加载失败的问题。

• 动态渲染触发逻辑异常
  你的iframe带有heightadjustment动态高度调整属性，需要依赖页面重绘逻辑触发资源加载。旧版Chrome无头模式下没有实际的图形输出链路，部分动态渲染触发规则不会主动执行，会导致iframe的加载请求未被触发，而有头模式下有实际的图形渲染 pipeline，会自动触发该类动态加载逻辑。

• 无头浏览器检测拦截
  部分站点会内置无头浏览器检测逻辑，即使你覆盖了User-Agent，站点仍可通过Canvas指纹、WebGL特性检测等方式识别到无头模式，主动拦截iframe的加载请求。你本地有头模式运行时不会触发该类检测规则，因此可正常加载。

临时验证及修复方案 #

1. 升级Chrome及ChromeDriver到100以上正式版本，将启动参数中的--headless替换为--headless=new，验证是否能正常加载
2. 手动给Jenkins服务账户配置和你登录用户一致的代理规则、证书信任规则，或者将Jenkins从节点改为以普通用户进程模式运行，而非系统服务模式
3. 启动参数临时添加--disable-web-security，如果测试后iframe可正常加载，即可定位为跨域限制问题，后续可针对性配置跨域规则
4. 开启Chrome性能日志，抓取iframe资源的请求响应状态码，确认是否是被拦截、证书错误还是网络不通导致的加载失败

内容的提问来源于stack exchange，提问作者Bharath Ram