SonarQube 6.7登录后页面冻结问题求助

结合你的环境和现象来看，这大概率是浏览器兼容性或者SonarQube前端资源/会话异常导致的问题，毕竟SonarQube 6.7是2018年的老版本，和最新Chrome的适配性可能存在冲突。下面是具体的分析和排查建议：

一、Chrome本地缓存/存储冲突 #

老版本SonarQube的前端资源，很可能和最新Chrome缓存的旧数据发生冲突，导致页面渲染卡住：

• 打开Chrome开发者工具（F12），切换到Application标签，找到Storage区域，清除SonarQube域名下的Local Storage、Session Storage和Cache Storage，然后刷新页面重试。
• 用Chrome隐身模式登录测试，如果隐身模式下正常，基本可以确定是缓存或浏览器扩展的问题。

二、Chrome浏览器扩展干扰 #

部分扩展（比如广告拦截器、隐私防护工具）可能会拦截SonarQube的前端脚本或API请求，导致页面交互失效：

• 临时禁用所有Chrome扩展，重新登录SonarQube测试。
• 如果禁用后恢复正常，逐个启用扩展排查出问题的那个，要么卸载该扩展，要么将SonarQube域名加入扩展的白名单。

三、SonarQube前端资源兼容性问题 #

SonarQube 6.7使用的前端框架（如AngularJS 1.x）可能和最新Chrome的新特性不兼容，即使控制台没有报错，也可能存在静默的执行阻塞：

• 在Chrome开发者工具的Console标签中，开启所有级别日志（包括Verbose），仔细查看登录过程中的警告信息，很多兼容性问题会以警告形式体现。
• 切换到Network标签，勾选Disable cache，重新登录，观察所有JS、CSS、API请求的加载状态，即使HTTP状态码是200，也要检查返回内容是否有损坏或格式错误。
• 查看SonarQube的web.log（路径一般是$SONARQUBE_HOME/logs），重点关注登录前后的模板渲染、API请求处理日志，可能存在未被捕获的前端资源加载异常。

四、数据库或会话配置问题 #

虽然Windows Firefox正常，但Chrome的安全规则更严格，可能触发了不同的会话或数据解析逻辑：

• 检查MySQL数据库字符集：执行SHOW VARIABLES LIKE 'character_set_%';，确保SonarQube使用的数据库是utf8mb4或utf8编码，避免因数据编码问题导致前端解析失败。
• 查看SonarQube的Cookie配置：在ChromeApplication标签的Cookies中，检查SONARSESSIONID的SameSite属性，HTTPS环境下建议设置为None（老版本SonarQube可能默认未配置，导致Chrome拦截）。同时确认sonar.properties中的sonar.web.host、sonar.web.context参数和代理后的域名一致。

还需检查的日志与工具 #

• SonarQube的access.log：记录了所有HTTP请求，可查看登录后的API请求是否都正常返回200，有没有超时或被拒绝的情况。
• Chrome Performance面板：打开开发者工具的Performance标签，录制从登录到页面冻结的全过程，查看JS调用栈是否有函数陷入死循环或长时间阻塞。

你提到的“新标签页打开其他页面后恢复正常”，也侧面印证了缓存或会话存储异常的可能性——其他页面重新加载了完整的前端资源，重置了异常的会话状态。

内容的提问来源于stack exchange，提问作者Vittorio C.