动态扫描启动失败时，表面看是点了开始却没有跑起来，实际往往同时牵扯到平台服务状态、传感器连通性、授权可用性，以及登录态能否稳定维持。很多团队会先盯着目标站点，但如果扫描侧先在启动阶段就卡住，再怎么改URL也不会变好。下面按“先让扫描跑起来，再把会话跑稳定”的顺序，把排查与校准步骤拆开讲清楚。

　　一、fortify动态扫描为什么无法启动

　　动态扫描无法启动通常分两类：一类是ScanCentral DAST或WebInspect侧的服务与授权条件不满足，扫描被接受后无法真正进入Running；另一类是首个请求或会话初始化阶段就触发中断条件，表现为Failed to Start、Pending卡住或直接中止。建议先从状态与日志入手定位属于哪一类，再对应处理。

　　1、先看扫描状态是否落在Failed to Start或License Unavailable

　　在ScanCentral DAST的扫描列表里，若出现License Unavailable说明当前没有可用授权供传感器启动扫描；若是Failed to Start，官方给出的常见原因包含DAST API未运行、DAST数据库连接丢失、与传感器通信丢失、传感器启动失败、扫描设置包含无效项等，先按这条线索分流排查会更快。

　　2、平台侧服务未就绪或链路断开导致“已接单但跑不起来”

　　当扫描显示为Failed to Start时，优先核对DAST API服务是否正常、DAST数据库是否在线、传感器心跳是否在刷新，以及网络层面是否存在中间设备把扫描流量或管理流量断开。上述任一环节不稳定，都可能导致“传感器已接受任务但无法开始”。

　　3、授权校验失败导致Product is not licensed一类报错

　　如果日志里出现“Product is not licensed”或启动扫描时返回内部错误，常见诱因是LIM授权服务地址或端口与当前DAST配置不一致，导致授权池校验失败；处理方式通常是用DAST配置工具重新写入正确的LIM主机与端口，并按新生成脚本替换容器或服务配置。

　　4、Scanner Worker Service起不来或连不上API

　　在ScanCentral DAST的Windows传感器场景中，Scanner Worker Service无法启动或启动后立即报错时，社区给出的一个高频原因是证书名称不匹配，导致Worker无法用当前地址完成到DAST Web API的TLS校验；需要核对证书里包含的名称与实际连接地址一致。

　　5、首个请求失败触发“丢失连接即停止”

　　有些目标站点在扫描器开始发包后会被WAF、代理或防火墙以不同方式重置连接，日志会出现FirstRequestFailed之类提示；社区里有案例是关闭“检测到连接丢失就停止扫描”后，扫描可以继续推进，随后再回头处理网络清洗或白名单问题。

　　6、本地WebInspect数据库缓存异常导致初始化失败

　　若是独立WebInspect本机发起扫描时直接阻止新扫描启动，并伴随与本地数据库相关的异常，社区提到过SQL Express缓存损坏会引发Scan Initialization Failed，处理思路是清理对应缓存目录后重启相关服务再验证。

　　二、fortify会话参数应怎样校准

　　会话参数校准的目标只有一个：让扫描线程在爬行与审计过程中始终携带正确的登录态与状态变量，避免刚启动就被当成未登录用户踢回登录页，或因为令牌更新不及时导致频繁重新登录。建议先确认浏览器内核可正常打开站点，再从登录宏、状态参数、令牌提取与线程隔离四块逐步收敛。

　　1、先用与宏一致的浏览器环境验证站点能正常加载

　　当登录宏录制或回放出现卡重定向、SSO跳转异常等情况时，先用truclientbrowser验证目标站点能否在WebInspect使用的Firefox环境中稳定打开，这一步能快速排除浏览器版本与本地存储导致的假问题。

　　2、重新录制会话型登录宏并固定入口动作

　　在WebInspect中通过【Tools】→【Login Macro Recorder】→【Session-based】录制登录过程，尽量把入口URL、表单提交、跳转完成后的落点页都录完整；宏里若存在可变参数，后续再做参数化，不要一开始就混入过多条件分支。

　　3、把关键状态变量纳入State管理而不是让扫描去随意变异

　　对于站点使用的会话标识符，先到【Edit】→【Default Scan Settings】→【HTTP Parsing】里，在“HTTP Parameters Used For State”中用【Add】新增需要保持状态的参数；社区示例中提到LptaToken这类值应作为状态保持变量，让WebInspect自动跟随更新，而不是在扫描过程中被当成普通参数大幅变异。

　　4、对容易触发登出的Cookie做排除处理

　　若某些Cookie被变异后会触发登出，可在【Edit】→【Default Scan Settings】→【Attack Exclusions】中查看“Excluded Cookies”，对需要完全不变异的项用【Add】加入排除；社区示例里也提到可先确认jsessionid是否已在排除列表，避免多余操作。

　　5、接口或令牌型认证按“从宏提取令牌再注入线程”配置

　　做API扫描或Bearer Token场景时，在认证配置里启用从宏响应中提取令牌：勾选Fetch Token From Macro，录制或导入宏后，在Fetch Token Search Pattern里填写用于匹配的正则模式；同时根据目标系统的令牌是否线程隔离，决定是否勾选Isolate State，以便每个线程独立取令牌或全局共享一个令牌。

　　6、用登出条件驱动宏重放，避免扫描过程中“悄悄掉线”

　　动态令牌或会话过期不可避免，关键是让扫描能自愈；可在登录宏里配置登出条件，通过响应内容的特征匹配来判断何时需要重新执行登录宏，从而在爬行与审计阶段持续维持登录态。

　　三、fortify应怎样核对传感器与授权

　　当会话已校准但仍频繁启动失败，往往需要把视角抬到传感器池、授权占用、心跳与网络出站能力这些基础条件上。此部分建议用“能否拿到授权、能否稳定连到管理面、能否稳定连到目标面”三条线并行核对，避免只盯某一个点反复试错。

　　1、核对传感器池选择与授权是否会被队列挡住

　　若提交扫描时未勾选“只使用指定传感器”，扫描可能在池内寻找任一可用传感器；同时当无可用授权时会进入License Unavailable并在队列等待，需结合池内并发与授权配额评估是否需要错峰或扩容。

　　2、检查心跳与通信链路是否稳定

　　扫描出现Interrupted时，文档示例提到可能与传感器心跳过期相关；一旦管理链路抖动，扫描状态可能在Running与未知状态间切换，建议重点核对网络质量与时间同步。

　　3、确认目标侧网络与中间设备不会在启动阶段重置连接

　　若日志提示连接被远端强制关闭或首包失败，需要从WAF规则、代理出站、端口放行、TLS拦截等方向逐项排查；必要时先临时放宽“丢失连接就停止”的条件，让扫描输出更多请求轨迹以便定位拦截点。

　　4、核对OAST相关出站访问需求

　　社区讨论中出现扫描阶段对fortify-oast.net的访问痕迹，说明在某些检测或策略下可能需要公网DNS或OAST能力；若网络不允许出站访问，应提前规划改用本地OAST方案或调整策略以匹配网络边界。

　　5、用一份最小化设置做基线验证

　　先用最简单的策略与最小线程数对一个已知可访问的测试站点跑通启动，再逐步叠加登录宏、令牌提取、策略项与并发设置；一旦出现Failed to Start，就能更准确地把问题归因到新增配置或基础设施。

　　总结

　　fortify动态扫描启动失败通常不是单点故障，而是服务状态、授权校验、传感器链路与会话保持共同作用的结果；先用ScanCentral DAST状态把问题分流，再用登录宏与状态变量把会话跑稳，最后用传感器与授权核对把基础条件补齐，整体排查路径会更可控。