很多团队装好Fortify ScanCentral后，第一道坎往往不是扫描规则，而是Controller起不来，或Sensor节点明明装了却一直不“上线”。这类问题看似零散，实际都落在同一条链路上：Controller的Tomcat能否正常启动，地址与密钥是否对齐，节点与Controller之间是否能稳定握手。下面按“先让Controller可用，再把节点注册上线，最后把日志与鉴权串起来复盘”的顺序，把排查步骤写清楚，方便你一次性把环境拉起来。

　　一、Fortify ScanCentral启动失败怎么办

　　启动失败不要急着重装，先把“有没有跑起来、跑起来后能不能被访问、访问后能不能和SSC互通”三件事拆开看。Controller本质跑在Tomcat里，你只要能定位到启动脚本与日志，就能很快把问题收敛到端口、内存、配置或证书这几类。

　　1、先确认Tomcat是否按正确方式启动

　　在Controller服务器上进入/tomcat/bin/，Windows执行【startup.bat】，Linux执行【startup.sh】。如果你是以服务方式部署，就在系统服务里对Controller对应的Tomcat服务执行【启动】或【重新启动】，不要混用脚本与服务两套启动方式，以免误判实际进程状态。

　　2、直接从Controller日志锁定第一处报错

　　不要只看控制台一闪而过的提示，优先打开/tomcat/logs/scancentralCtrl.log。日志里通常会把端口占用、配置项读取失败、连SSC鉴权失败等原因写得很直白，你只要抓住第一条ERROR往上回看上下文，效率会高很多。

　　3、重点核对Controller的this_url与对外访问地址

　　如果你改过HTTP到HTTPS或换过端口，务必到/tomcat/webapps/scancentral-ctrl/WEB-INF/classes/config.properties里检查this_url，确保它和你实际访问的协议、主机名、端口一致。this_url会被用于邮件通知与引用地址，写错会导致外部看似能打开页面，但后续回链、集成与下载动作表现异常。

　　4、排查端口冲突与同机部署带来的“假启动”

　　同一台机器上如果SSC、Jenkins或其他Tomcat也在跑，最常见的是8080或8443冲突，Tomcat启动直接失败或启动在你没预期的端口上。做法是先在服务器上确认端口占用情况，再到Tomcat的server.xml里调整端口，改完后用【重新启动】让配置生效，并再次回看scancentralCtrl.log确认新端口已监听。

　　5、遇到内存或堆相关错误先加内存再复测

　　如果日志里出现Java堆内存不足或类似OutOfMemoryError的信号，优先把Tomcat服务的Java内存参数调大再重启复测，不要一上来就把问题归因到安装包。很多环境在代码量较大或并发作业多时，默认内存配置会撑不住，表现就是启动不稳或运行一段时间后崩掉。

　　二、Fortify ScanCentral节点怎么添加注册

　　节点在ScanCentral里对应Sensor，注册成功的关键只有两点：节点机器上要有OpenText SAST可用，节点与Controller的worker_auth_token要一致。你可以先用命令行把节点跑起来验证链路，再决定是否做成服务自启，避免一开始就陷在服务配置细节里。

　　1、先明确节点需要安装什么与装在哪里

　　在每台节点机上安装OpenText SAST，并确认路径下存在Core与bin目录。节点作为Sensor执行扫描时会调用SAST能力，所以仅装Controller不够，节点侧的SAST安装与权限要先确认到位。

　　2、把worker_auth_token对齐到同一把“钥匙”

　　先在Controller的config.properties里确认worker_auth_token的值，再到节点机打开/Core/config/worker.properties，填写同样的worker_auth_token。若你不想用明文，可以按文档方式把共享密钥加密后再写入worker.properties，并同步设置pwtool_keys_file，避免节点启动后直接401拒绝。

　　3、用命令行先把节点跑起来验证能否连上Controller

　　在节点机进入/bin/，执行scancentral-urlworker。看到节点进入等待状态，且Controller侧能识别到该节点，说明注册链路已通，再考虑做自启与池化分配会更稳。

　　4、需要做成Windows服务时按服务安装流程生成worker.properties

　　如果你选择Windows服务方式，先到binscancentral-worker-service按安装流程安装服务，再在系统服务里对FortifyScanCentralWorkerService执行【启动】。服务安装器会为你生成Coreconfigworker.properties，你只需要回到这份文件里补齐worker_auth_token等关键项即可。

　　5、节点启动后仍不在线就从节点侧配置与路径入手

　　节点侧常见坑是worker.properties写错位置，或把token写成带空格、带不兼容字符导致鉴权失败。先确认你改的是/Core/config/worker.properties这一份，再结合节点控制台输出与Controller的scancentralCtrl.log对照看时间点，能很快定位是“没连上”还是“连上被拒”。

　　三、Fortify ScanCentral地址与密钥对齐检查

　　当Controller能启动、节点也能启动，但扫描仍卡住或状态反复横跳时，问题往往不在安装，而在地址、密钥与运行模式的细节对齐。把这三块一次性校验干净，后续扩容节点、升级版本、迁移域名都会省很多返工。

　　1、用SSC的维护模式动作保护正在跑的作业

　　如果你需要重启Controller，先在SSC里进入ScanCentral视图，在SAST页面的Controller区域点击【START MAINTENANCE MODE】。等状态进入可维护后再停机重启，避免粗暴关机导致已派发到节点的扫描丢失或卡死。

　　2、统一Controller对外地址，避免内网地址与外网地址混用

　　很多“节点能连但客户端提交失败”的根因是controller_url在不同机器上写成了不同域名或不同协议。做法是先把Controller的this_url定为团队统一访问入口，再要求客户端与节点都只使用这一份入口地址，避免同一套服务被多地址访问引发证书与回链混乱。

　　3、区分client_auth_token与worker_auth_token，别拿错用

　　client_auth_token用于客户端请求鉴权，worker_auth_token用于节点鉴权，两者用途不同，混用会出现“客户端401”或“节点401”。你在排查时可以把请求链路按角色拆开，先保证节点用worker_auth_token能注册，再保证客户端用client_auth_token能提交作业，最后再看SSC集成链路。

　　4、把日志收集口径固定下来，避免每次排查都从零开始

　　Controller侧固定看/tomcat/logs/scancentralCtrl.log，节点侧固定围绕worker启动输出与worker.properties改动记录。每次改配置前先备份原文件，改完立刻重启并记下时间点，再回日志按时间点定位变化，这样同一个问题不会反复踩坑。

　　总结

　　Fortify ScanCentral的环境问题，按顺序处理会非常快：Controller先能稳定启动并能从日志定位错误，再把节点的worker.properties与worker_auth_token对齐并用命令行跑通注册，最后统一地址与鉴权口径，把维护模式与日志习惯固化下来。你把这三步做扎实，后续无论是加节点、换证书还是接入流水线，问题都会变得可定位、可复现、也更容易一次修好。