Sonarqube服务运行正常但默认9000端口拒绝连接无法访问

从服务状态看systemd显示服务active，但本地所有地址curl都返回连接被拒，本质是服务进程没有正常绑定到9000端口，按以下顺序排查即可：

• 第一步：校验端口实际监听状态
  执行命令查看9000端口是否真的被进程绑定：
  ss -tulpn | grep 9000
  如果命令无任何输出，说明服务进程实际未完成启动、或者已经异常退出，systemd的active状态是误报，直接去查SonarQube日志，不要盲目修改其他配置。日志默认存放在${SONARQUBE_INSTALL_PATH}/logs/目录下，重点看三个文件的报错：
  • es.log：内置Elasticsearch的启动日志，80%的启动失败都是ES校验不通过导致：
    • 报错提示vm.max_map_count [65530] is too low：执行sysctl -w vm.max_map_count=262144临时修复，永久生效需在/etc/sysctl.conf中添加vm.max_map_count=262144后执行sysctl -p加载配置
    • 报错提示权限不足：检查SonarQube整个安装目录的属主，必须和systemd中配置的启动用户一致，SonarQube禁止root用户启动，必须使用专用普通用户运行
    • 报错提示文件句柄/线程数不足：在/etc/security/limits.conf中为启动用户添加nofile 65536、nproc 4096的资源限制
  • web.log：Web服务进程日志，常见报错为数据库连接失败、端口被其他进程占用、绑定的IP地址不存在
  • sonar.log：服务主日志，会记录各组件的启动顺序和整体报错信息
• 第二步：校验核心配置文件
  打开${SONARQUBE_INSTALL_PATH}/conf/sonar.properties检查Web服务绑定配置：
  • 若需要直接通过IP+端口访问，配置sonar.web.host=0.0.0.0
  • 若仅通过本地反向代理访问，配置sonar.web.host=127.0.0.1
  • 确认sonar.web.port=9000，如果修改过端口值，后续访问要对应调整端口
    不要将sonar.web.host配置为具体的公网/内网网卡IP，容易因网卡加载顺序、IP变动导致绑定失败。
• 第三步：校验systemd服务配置正确性
  打开/etc/systemd/system/sonarqube.service检查配置：
  • User、Group必须配置为SonarQube专用的普通运行用户，不能配置为root
  • WorkingDirectory、ExecStart路径必须和实际SonarQube安装路径一致
  • 如果ExecStart调用的是sonar.sh start启动脚本，必须将服务Type设置为forking，同时添加PIDFile=${SONARQUBE_INSTALL_PATH}/bin/linux-x86-64/SonarQube.pid配置，否则systemd无法正确识别进程状态，会出现服务实际已退出但状态显示active的误报。配置修改后执行systemctl daemon-reload再重启服务。
• 第四步：校验系统拦截规则
  本地curl能通但外部访问不通时再排查这部分：
  • 临时关闭防火墙测试：CentOS系执行systemctl stop firewalld，Debian/Ubuntu系执行ufw disable，如果关闭后能访问，对应添加9000端口的入方向放通规则即可
  • 临时关闭SELinux测试：执行setenforce 0，如果关闭后能访问，添加SELinux放通规则即可
  • 云服务器需额外检查控制台安全组是否放通对应端口的入方向流量；使用反向代理的场景要确认代理配置中upstream地址和SonarQube实际绑定的地址、端口一致。

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