连接超时但ping通、curl报Connection refused，说明主机可达但目标端口无服务监听；常见原因包括服务未启动、绑定地址错误（如仅127.0.0.1）或防火墙拦截。
连接超时但 ping 通，curl 报 Connection refused
说明目标主机可达，但服务没在监听对应端口。常见于服务未启动、监听地址绑定错误或防火墙拦截入站连接。
实操建议：
- 用
ss -tlnp | grep :（如ss -tlnp | grep :80）确认服务是否真正在监听，注意看Local Address:Port列 —— 若显示127.0.0.1:80，则只响应本地请求；应为*:80或0.0.0.0:80才能接受外部连接 - 检查服务配置文件中类似
bind、listen、host的参数，Nginx 默认listen 80等价于listen *:80，但某些应用（如 Redis）默认只绑127.0.0.1 -
systemctl status看服务状态，journalctl -u查启动失败日志--since "1 hour ago"
curl 或 wget 卡住不返回，无报错也无响应
典型表现是命令挂起数秒后才报 Operation timed out 或直接退出，不是 DNS 解析慢就是 TCP 握手失败，也可能是中间设备（如代理、负载均衡器）静默丢包。
实操建议：
- 先用
timeout 5 curl -v http://example.com加超时，配合-v看卡在哪一步：若停在* Trying x.x.x.x:80...，说明 SYN 发出后没收到 SYN-ACK，大概率是目标端口过滤或路由不通 - 换用
telnet example.com 80或nc -zv example.com 80绕过 HTTP 层直测 TCP 连通性 —— 如果连不上，问题不在应用层 - 对比
curl http://ip-address和curl http://domain-name行为差异，确认是否 DNS 导致（可临时改/etc/hosts绑定 IP 测试）
netstat / ss 显示大量 TIME_WAIT 或 CLOSE_WAIT
TIME_WAIT 多通常正常（主动关闭方维持 2MSL），但若占满端口导致新连接失败（报 Cannot assign requested address），就得调优；CLOSE_WAIT 多则说明本机应用没正确关闭 socket，有资源泄漏风险。
实操建议：
- 查
CLOSE_WAIT进程：ss -tanp state close-wait | awk '{print $7}' | sort | uniq -c | sort -nr，定位到 PID 后用ps -p看是什么程序-o comm=,cmd= - 临时缓解
TIME_WAIT压力：echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse（仅对客户端有效），但别开tcp_tw_recycle（已废弃且在 NAT 环境下会断连） - 真正治本是修复应用：Python 的
requests要复用Session，Node.js 的http.Agent需设keepAlive: true，避免短连接高频创建销毁
ssh 连得上但 scp/rsync 失败，提示 stdin: is not a tty 或卡在认证后
本质是远程 shell 启动方式不同：交互式 ssh 分配伪终端（tty），而 scp/rsync 使用非交互式 shell，某些 .bashrc/.profile 中的阻塞操作（如 read、sleep、卡顿的命令）会导致它卡死。
实操建议：
- 在远程用户家目录下检查
~/.bashrc和~/.profile，注释掉所有非必要输出或交互语句（尤其echo、read、source外部脚本等） - 测试非交互式执行：
ssh user@host 'echo hello'—— 若卡住或无输出，问题就在这里 - 更稳妥的做法是把环境初始化逻辑移到
~/.bash_profile，并在.bashrc开头加[[ -n $PS1 ]] || return，确保只在交互 shell 中加载
if [[ -n $PS1 ]]; then # 只有交互式 shell 才执行以下内容 source ~/.bash_aliases export EDITOR=vim fi
网络异常排查最易被忽略的是「默认行为差异」：比如 systemd 服务默认不读 /etc/profile，Docker 容器里 sh 可能不是 bash，甚至同一命令在不同发行版的 ss 输出字段顺序都可能不一样。动手前先确认上下文，比盲目套命令更省时间。
