内网路由正常但部分端口无法访问，说明三层连通性已满足，问题一定出在四层及以上——即端口转发路径、服务监听、防火墙策略或系统资源层面。需依次排查服务监听地址（非127.0.0.1）、防火墙入站规则（协议/作用域）、系统端口保留冲突、TCP连接资源耗尽四大核心环节。
内网路由正常但部分端口无法访问，说明三层连通性（ip可达）已满足，问题一定出在四层及以上——即端口转发路径、服务监听、防火墙策略或系统资源层面。这类故障隐蔽性强，常被误判为“网络没问题”，实际是业务链路断裂。
一、确认服务是否真正在监听目标端口
很多问题根源在于服务没真正绑定到可被外部访问的地址上：
- 运行 netstat -ano | findstr :端口号（如
:8080），检查输出中是否有LISTENING状态，且 Local Address 是0.0.0.0:8080或192.168.x.x:8080，而非仅127.0.0.1:8080（后者只允许本机访问） - 若用 IIS、Nginx 或 Java 应用，检查配置文件是否显式设置了
bindingAddress或host参数；Tomcat 默认可能只监听 localhost - 重启服务后立即再查一次，避免因服务启动失败而假象“已运行”
二、逐层检查防火墙放行状态
Windows Server 的防火墙策略有多个层级，任一环节拦截都会导致端口不通：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 执行 netsh advfirewall firewall show rule name=all | findstr "端口号"，确认存在对应入站规则，且状态为
Enabled - 检查规则协议类型是否匹配（TCP/UDP），方向是否为
In，作用域是否包含内网子网（如192.168.1.0/24），而非仅LocalSubnet或空值 - 临时禁用防火墙测试：netsh advfirewall set allprofiles state off，再从另一台内网机器 telnet 测试；若恢复则通，说明是防火墙规则细节问题
- 注意：组策略（GPO）可能覆盖本地防火墙设置，需在
gpresult /h report.html中检查是否有“Windows 防火墙：定义入站端口规则”类策略生效
三、排查系统级端口保留与冲突
Windows Server（尤其 2016+）默认会动态预留大量端口，即使 netstat 显示“空闲”，程序也可能因权限被拒而无法绑定：
- 运行 netsh interface ipv4 show excludedportrange protocol=tcp，查看被系统保留的端口段（如
13500–13599）；若你用的端口（如 13508）落在其中，就会报Access is denied - Hyper-V、WSL2、Docker Desktop 启用后会扩大保留范围，重启不一定释放——可改用高位端口（如 25000–30000）快速验证是否为该原因
- 如确需使用特定端口，可用命令收缩动态端口池：netsh int ipv4 set dynamicport tcp start=49152 num=16384，把保留区缩至高位，释放低段端口
四、验证 TCP 会话资源是否耗尽
高并发短连接场景下，TIME_WAIT 连接堆积或动态端口池枯竭，会导致新连接建立失败（现象是偶发不通、连几秒就断）：
- 统计当前 TIME_WAIT 数量：netstat -n | findstr TIME_WAIT | find /c /v ""；超过 8000 就需警惕，超 15000 极大概率引发连接失败
- 查看动态端口范围：netsh int ipv4 show dynamicport tcp；默认 49152–65535 共 16384 个，若已被占满（可用
netstat -an | find /c "ESTABLISHED"辅助估算），新连接将无法发起 - 临时缓解：调整注册表
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下的MaxUserPort（设为 65534）和TCPTimedWaitDelay（设为 30），然后重启
