想知道IHS把请求转发到了哪台后端服务器，最直接的方法是开启IHS插件日志（http_plugin.log）并设为Trace级别，里面会用“Selected Server”等字段明确写出目标主机；如果还没开日志，也可以先看plugin-cfg.xml里的URI映射规则，从路由规则上推算结果。
IHS本身不产生业务数据，它只是一个“中转站”，每一次用户请求进来，IHS的插件都要决定交给哪台WebSphere（WAS）服务器，这个决定不是随机的，而是严格参考plugin-cfg.xml里的路由配置，所以排查“路由到哪台服务器”的问题，本质上就是回答两个问题：静态规则是什么，以及动态选择结果是什么。
IHS怎么查看路由到哪台服务器：先看plugin-cfg.xml的映射关系
plugin-cfg.xml是IHS路由的“导航地图”
这个文件一般位于IHS安装目录的conf子目录下，例如/opt/IBM/HTTPServer/conf/plugin-cfg.xml，它定义了哪些URL请求会被IHS接管,以及这些请求应该分发给哪些后端集群。
打开文件后,重点看以下节点：
- UriGroup：定义一组URI前缀，比如
/app/。 - ServerCluster：定义后端WAS服务器集群，包含多个
Server节点。 - Transport：定义连接后端服务器的协议和端口。
从这段配置里,你可以直接看出某个URL前缀指向哪个集群。
<UriGroup Name="default_group"> <Uri Name="/app/"/> </UriGroup> <ServerCluster Name="was_cluster"> <Server Name="node1" Host="10.0.0.11" Port="9080"/> <Server Name="node2" Host="10.0.0.12" Port="9080"/> </ServerCluster>
这里/app/的流量会在node1和node2之间分配，也就是说，如果请求路径是/app/login，IHS不会把它发给配置文件之外的服务器。路由范围先由这个文件圈定。
在WebSphere集群环境下，路由规则更复杂
如果后端是WAS ND集群，plugin-cfg.xml通常由部署管理器自动生成并下发到IHS，这时候还需要额外注意集群内的权重和会话保持设置，集群成员的顺序并不代表流量比例,真正的选择逻辑还要看插件运行时状态。
行业共识认为：排查路由问题应先确认静态配置，再动态验证实际连接，顺序反了就容易被假象误导。
实操：IHS插件日志如何记录路由目标
开启Trace级日志，让IHS“自报家门”
要动态看到某个请求具体选择哪台后端服务器,最可靠的方法是打开插件的Trace日志。
步骤如下：
- 编辑
plugin-cfg.xml，找到<Log>- 把
LogLevel改为Trace，同时指定日志路径，<Log LogLevel="Trace" Name="/opt/IBM/HTTPServer/logs/http_plugin.log"/>
- 重启IHS，让配置生效，常用命令是：
/opt/IBM/HTTPServer/bin/apachectl -k restart
或者使用
ihsctl restart。- 在客户端触发一次请求,然后检查日志文件。
- 把
开启之后，日志中会出现类似Resolve Request、Selected Server的关键信息，不同版本文本略有差异，但意思一致：插件把请求和URI匹配后，会记录最终选中的后端节点，业内专家指出，Trace级别日志是确认转发目标的最直接证据，比网络抓包更省事。
精准提取关键内容：IHS插件日志中Resolve Request怎么读
日志行可能很复杂，你不必逐行分析,在Linux服务器上执行：
grep "Selected Server" /opt/IBM/HTTPServer/logs/http_plugin.log
或者搜索请求的URI特征：
grep "/app/login" /opt/IBM/HTTPServer/logs/http_plugin.log
日志会告诉你某个时间点、某个URI被分配给了哪台主机和端口。
[25/May/2026:10:23:45] 000001 00000002 - PLUGIN INFO: Resolve Request URI [/app/login] [25/May/2026:10:23:45] 000001 00000002 - PLUGIN INFO: Selected Server : [node1:9080]
到这里,路由目标已经浮出水面。
需要提醒的是：Trace级别会记录大量日志，生产环境建议在低峰期开启，用完后及时改回Error级别，避免磁盘被撑满。
不用日志也能查：IHS服务器上实时观察连接目标
如果嫌改配置太麻烦，还有一条更直接的路：在IHS所在的服务器上观察它和后端服务器的连接。
前提是你已经知道后端WebSphere服务的监听端口，这个端口通常写在plugin-cfg.xml的ConnectPort属性中，例如9080。
然后执行：
netstat -an | grep 9080
输出的结果里，ESTABLISHED状态的连接就是IHS正在向后端建立的TCP连接，对端IP就是当前承载请求的后端服务器，如果不知道IP对应哪台机器,用：
nslookup 10.0.0.11
或者查看/etc/hosts反查主机名。
这种方法适合临时观察，不能追溯历史请求。如果你定位的是“刚才某个请求去了哪台服务器”，还是插件日志更精准。
IHS插件日志还是访问日志：排查路由该看哪个
很多人习惯先翻access_log，看来看去只有客户端IP和请求行，找不到后端服务器信息，这是正常的，因为IHS的访问日志只记录“客户端到IHS”这段交互，不记录“IHS到WAS”的转发目标。
下面这张表可以帮你快速选择排查路径：
| 数据来源 | 包含后端目标吗 | 适合场景 | 缺点 |
|---|---|---|---|
| access_log | 不包含 | 统计客户端访问量 | 无法定位后端 |
| http_plugin.log | 包含 | 精确查看每次转发目标 | 需要开启Trace，日志量大 |
| netstat/tcpdump | 实时包含 | 临时观察当前连接 | 无法对应具体请求URI |
| WAS日志 | 间接包含 | 核对实际执行业务的机器 | 需要登录后端系统 |
只有插件日志能做到“按请求”还原路由路径,其余方式可以作为补充验证。
使用tcpdump辅助确认
如果连netstat都觉得不够,还可以在IHS服务器上抓包：
tcpdump -ni eth0 tcp port 9080 -s 0 -w /tmp/ihs_trace.pcap
然后打开抓包文件，筛选IHS服务器IP与后端IP之间的数据流，这种方法能同时看到TCP握手和HTTP请求内容，但解析成本较高,一般只在怀疑网络层丢包或耗时异常时使用。
集群环境下路由不固定：如何确认当前会话落在哪台节点
会话保持会让路由“看起来不随机”
IHS插件默认会尽量把同一Session的请求保持到同一台后端节点，如果你在同一个浏览器会话里不断刷新页面，路由结果可能一直抱死在某台服务器上，只有当该节点不可用或负载过高时,插件才会切换到备选节点。
当你发现同一URI在不同时间路由到不同服务器时，不一定是配置错误，可能是会话粘性在起作用，要验证这一点，带上会话Cookie发起请求，再查看插件日志里的Selected Server变化。
和WAS日志对照验证
更稳妥的方式是登录后端WebSphere服务器，查看对应Application Server的SystemOut日志，一旦确认WAS在某个时间点处理了该请求，再和IHS插件日志的时间戳比对,就能完全闭环。
这种交叉核对在排障时非常有用。
Q&A：IHS路由查询常见问题
Q1：IHS插件日志默认打开吗？
默认情况下，plugin-cfg.xml里的LogLevel通常是Error，不会记录详细的转发目标，需要手动改成Trace并重启IHS，才能看到Selected Server信息。
Q2：为什么访问日志里看不到后端服务器IP？
因为IHS访问日志记录的是“客户端与IHS之间的HTTP请求”，而转发后端是由插件内部完成的，不会写入CustomLog字段，想看后端目标,只能启用插件日志或通过抓包观察连接。
Q3：plugin-cfg.xml里的路由规则和插件日志哪个能作为最终依据？
路由规则是先决条件，插件日志是执行结果的记录，插件不会绕过plugin-cfg.xml去连接未定义的服务器，所以静态配置优先；但要看某一次请求的真实去向,必须以插件日志为准。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/774033.html
