端口不通主因是服务未监听、防火墙拦截或监听地址错误（如仅绑127.0.0.1）；telnet连不上需先区分Connection refused（服务未监听）与Connection timed out（网络拦截），再用ss -tlnp确认监听地址是否为0.0.0.0。
端口不通，八成不是网络问题，而是服务没监听、防火墙挡了、或者绑错了地址（比如只绑 127.0.0.1）。别急着换工具，先用 telnet 和 nc 快速分层定位——它们轻量、自带率高、结果直给。
telnet 连得上但秒断？说明端口通但服务没响应
telnet 只做 TCP 三次握手 + 建立连接，不关心上层协议。它连得上，就证明传输层通；连不上，才需要往下查路由或防火墙。
- 成功时输出类似
Connected to 192.168.1.100.或直接出现空白提示符（甚至带服务欢迎信息，如SSH-2.0-OpenSSH_8.9） - 失败时常见三种提示：
Connection refused（目标没监听该端口）、Unable to connect to remote host（网络不可达或防火墙 DROP）、Connection timed out（中间设备静默丢包，如安全组未放行） - 注意：
telnet在 Ubuntu/Debian 上默认不装，需手动sudo apt install telnet；CentOS 7+ 默认也常被移除 - 别在公网对敏感端口（如
3306、6379）用telnet，会暴露服务指纹，且明文交互有风险
nc -zv 测试返回 succeeded! 就一定通？不一定
nc -zv 比 telnet 更适合脚本化判断，但它只发 SYN 包、不等 ACK 后续数据，属于“弱验证”。某些场景下它说通，实际业务仍失败。
-
nc -zv 192.168.1.100 80成功返回succeeded!，仅表示目标主机回应了 SYN-ACK，不代表 HTTP 服务真在跑 - UDP 测试（
nc -zuv）更不可靠：UDP 无连接，nc只发一个空包，收不到 ICMP “port unreachable” 就算“通”，但 DNS 服务可能根本没启 - Ubuntu 自带的
netcat-traditional不支持-w（超时），得用-G；而 CentOS 的nmap-ncat支持-w，参数不统一，写自动化脚本前务必nc -h | head -3看清版本 - 加
-w 2强制 2 秒超时很必要，否则默认卡住几十秒，脚本容易 hang 住
telnet 和 nc 都连不上，下一步盯死三件事
不是工具不行，是问题不在这一层。此时必须跳出“连不连得上”的思维，转去确认：目标机器是否真在监听？监听地址是不是 0.0.0.0？本地出向或远端入向规则有没有拦？
- 在目标服务器上执行
ss -tlnp | grep :<code>端口号，看Local Address:Port列是否为*:<code>端口号或0.0.0.0:<code>端口号；如果是127.0.0.1:<code>端口号，外部肯定连不上 - 检查远端防火墙：
sudo ufw status（Ubuntu）或sudo firewall-cmd --list-ports（CentOS），确认该端口确实在放行列表里 - 云环境别忘了安全组——
telnet和nc都无法绕过安全组策略，哪怕内网互通，端口没在安全组里放行，结果就是Connection timed out - 如果目标是容器或 Pod，还要确认端口是否通过
-p映射或 Service 正确暴露，docker ps或kubectl get svc得跟上
真正卡住人的，往往不是命令不会敲，而是看到 Connection refused 就去调网络，其实该去看 ss -tlnp；看到 succeeded! 就以为万事大吉，其实服务进程早崩了。工具只是探针，解读信号得靠分层意识。
