LoadRunner压测一旦出现Controller连不上负载机，优先按解析、连通、端口、服务、版本五步查，不要先改脚本。把问题拆成可验证动作，能快速判断是负载机端口没开，还是中间网络把连接拦掉。

　　一、LoadRunner Controller连不上负载机怎么办

　　连不上通常不是单一原因，先用最小测试确认主机名与IP是否一致，再核对负载机Agent与端口监听，最后回到Controller配置与版本差异做收口。

　　1、先排除主机名解析与路由走向

　　（1）在Controller上用主机名与IP各连一次，主机名失败IP成功，多半是DNS或hosts指向错。

　　（2）同网段可连跨网段失败，优先定位路由与安全域隔离，而不是反复重装。

　　2、确认负载机Agent服务确实已启动

　　（1）在负载机打开系统服务，检查LoadRunner相关Agent服务是否运行，必要时重启一次。

　　（2）服务起不来先看终端安全是否拦截进程或阻止自启，先放行再继续测端口。

　　3、核对通信端口是否监听且可达

　　（1）在负载机确认TCP 54345是否监听，部分环境还会用到54245，两者至少要对齐。

　　（2）端口监听正常后，从Controller侧做端口连通测试，判断是本机防火墙拦截还是中间设备拦截。

　　4、处理端口占用与端口口径不一致

　　（1）端口被占用会导致Agent绑不上或握手异常，先释放占用进程再重启Agent。

　　（2）若运维改过默认端口，需同步修改Controller侧负载机通信口径，避免端口通但仍连不上。

　　5、回查Controller添加方式与版本补丁

　　（1）添加负载机先用IP验证连通，再切回主机名，减少解析噪音。

　　（2）Controller与负载机版本或补丁不一致时容易握手失败，建议统一版本节奏并做对照排查。

　　二、LoadRunner负载机端口被拦截怎么定位

　　端口拦截要分段取证：先看负载机本机是否监听，再看本机防火墙，再看中间网络设备。每段给出可复现的测试结果，网络与安全团队才好快速放行。

　　1、先确认通信模式与端口范围

　　（1）直连模式优先围绕54345与54245排查，先别把范围扩大到无关端口。

　　（2）不同测试池跨安全域时策略可能不同，先把源IP、目的IP、目的端口口径写清。

　　2、第一段定位负载机本机监听

　　（1）端口不监听先处理Agent与端口占用，监听后再进入下一步。

　　（2）若监听进程不是LoadRunner相关服务，说明端口被抢占或配置被改写，先纠正再测。

　　3、第二段定位负载机本机防火墙与终端安全

　　（1）监听正常但外部连不上，先在负载机新增入站放行规则，尽量绑定端口与进程。

　　（2）放行后立刻复测端口连通性，能恢复则基本可判定为本机策略问题。

　　4、第三段定位中间网络设备拦截

　　（1）同网段成功跨网段失败，多为ACL或东西向防火墙策略，提交源目的端口与时间点便于查日志。

　　（2）间歇性成功或被重置，常见IPS或会话策略命中，按时间点让网络侧定位丢包位置。

　　5、避免误判端口通就等于可用

　　（1）端口可达不代表握手一定成功，版本不一致、服务权限异常也会导致连接失败。

　　（2）此时做成功机与失败机对照，优先比补丁、端口规则、终端安全策略与服务账号差异。

　　三、LoadRunner多机压测连通性怎么预检与固化

　　把排障变成流程，核心是预检与基线：新增负载机先跑连通性检查，端口与模式写进交接文档，放行规则按最小权限沉淀成模板，后续扩容迁移就不必从零排查。

　　1、上线前先跑连通性预检

　　（1）检查Agent运行、54345与54245监听、Controller到负载机端口可达，三项通过再配场景。

　　（2）预检结果截图留档，便于后续策略变更后快速回溯。

　　2、把端口口径与网段规范固化

　　（1）端口清单、通信网段、负载机命名规则统一写入环境说明，避免多人协作口径漂移。

　　（2）端口若有变更，必须同步更新Controller配置与放行申请材料。

　　3、把放行申请做成最小权限模板

　　（1）模板至少包含源范围、目的范围、端口列表、对应进程、用途说明与回滚方式，新机器直接复用。

　　（2）放行若有有效期或自动回收机制，提前写进排程，避免压测中途掉线。

　　总结

　　LoadRunner Controller连不上负载机怎么办，LoadRunner负载机端口被拦截怎么定位，按解析连通、Agent服务、端口监听、策略拦截、版本对照五步走，能把问题从连不上落到具体可改的点；再用预检清单与基线文档固化端口与放行规则，多机压测扩容会稳定很多。