这条路径解决什么
放行申请、上线验收、安全组变更核对时，需要确认「从指定来源能不能连上目标端口」。做法是把目标整理成主机与端口的清单，逐个或并行探测，输出结构化的通与不通清单。关键是把「立即被拒绝」与「一直没响应」区分开，这两者指向完全不同的原因。
基本信息
| 适用场景 | 批量验证端口可达性，核对防火墙与安全组策略 |
|---|---|
| 可选工具 | nc -z、bash 的 /dev/tcp、telnet、nmap（更重） |
| 并行手段 | xargs -P 控制并发数，避免串行等待过长 |
| 必加超时 | timeout 或 nc 的 -w，否则 DROP 策略下每个端口都要等到系统默认超时 |
| 判据要点 | 连接被拒绝说明可达但无监听；超时说明被丢弃或路由不通 |
典型使用场景
- 放行验收：确认申请的网络策略确实生效
- 上线前自检：从应用侧机器验证依赖的数据库、缓存、消息端口
- 故障定位：区分「服务没起来」与「网络没放通」
- 变更后回归：安全组调整后批量复核关键端口
- 多来源比对：从不同网段各测一次，确认策略是按来源生效的
简单循环
简单循环
for port in 22 80 443 3306; do
nc -z -w2 10.0.0.5 $port && echo "$port OPEN" || echo "$port CLOSED"
done无 nc 环境
无 nc 环境
timeout 2 bash -c 'cat < /dev/null > /dev/tcp/10.0.0.5/443' && echo OPEN || echo CLOSED
# 判断依据是 bash 的 /dev/tcp 伪设备能否建立连接并行加速
并行加速
printf '10.0.0.5 22\n10.0.0.5 443\n10.0.0.9 80\n' \
| xargs -P6 -n2 sh -c 'nc -z -w2 $0 $1 && echo "$0:$1 OPEN" || echo "$0:$1 CLOSED"'探测结果读法
| 结果 | 含义 | 下一步 |
|---|---|---|
| 立即成功 | 端口可达且有服务监听 | 到此结束，注意协议是否匹配 |
| 立即失败（Connection refused） | 网络可达但目标端口没有监听 | 去目标机确认服务是否启动、是否绑在预期地址 |
| 迟迟无响应（timeout） | 包被丢弃或路由不通 | 检查防火墙策略、安全组与路由 |
| 域名解析失败 | 名称无法解析为地址 | 先解决 DNS，再谈端口 |
UDP 端口不能用 -z 判断：UDP 无连接，探测结果不可信。要验证 UDP 服务需真实收发一段数据并观察响应，或直接看服务端日志是否收到请求。
DROP 与 REJECT 的差别决定了等待时间：DROP 让客户端一直等到超时（看起来像网络不通），REJECT 会立即返回连接被拒绝。设计探测脚本时统一加 -w 或 timeout，否则大量 DROP 端口会让整个验收流程卡很久。并发数也别开太大，短时间大量连接可能触发对端防护。
把结果整理成三列（主机、端口、结论）重定向到文件，比看刷屏的终端输出更容易交付：变更单、验收单与工单里附上「命令加输出」才算有据可查。批量任务建议附上执行时间与来源机器，事后复盘时能还原当时的网络状态。