堡垒机高并发瓶颈本质是连接生命周期管理、内核资源调度与应用层复用策略三者失配；需分连接建立、维持、释放三阶段，结合ss/netstat查established、time_wait、close_wait、syn_recv状态，验证file-nr、ip_conntrack、somaxconn等内核参数，并检查ssh复用与会话超时配置。
堡垒机在高并发连接下出现性能瓶颈或崩溃，本质不是“连不上”，而是连接生命周期管理、内核资源调度与应用层复用策略三者失配的结果。排查不能只盯着日志或CPU，得从连接建立、维持、释放三个阶段逐层定位。
看连接状态分布，锁定真实瓶颈点
执行 ss -s 或 netstat -s | grep -i "tcp\|time_wait"，重点关注四类状态数量：
- ESTABLISHED：若远超预期并发数（如配置了2000个会话却看到1.5万 ESTABLISHED），说明连接未被及时回收，可能是客户端未正常登出，或堡垒机会话超时未触发清理；
- TIME_WAIT：单机每秒新建短连接超过 300，60 秒后就会堆积上万。若该值持续 >3 万且增长不止，说明客户端频繁断连（如终端自动重连、脚本未复用连接），堡垒机端口耗尽风险极高；
- CLOSE_WAIT：该状态堆积，代表堡垒机已收到 FIN，但自身应用层未调用 close()。常见于 SSH 会话异常中断后，堡垒机未及时释放 socket，需检查会话管理模块的异常兜底逻辑；
- SYN_RECV：若大量堆积，说明半连接队列（syn queue）被打满，可能被 SYN Flood 攻击，或内核参数 net.ipv4.tcp_max_syn_backlog 设置过低（默认常为 128 或 256，高并发建议调至 65535）。
查内核资源是否见顶
堡垒机本质是高连接密度的代理服务，极易触达系统级限制：
- 运行 cat /proc/sys/fs/file-nr，对比中间数值（已分配文件句柄数）与第三值（最大可分配数）。若接近上限（如 1048576），立刻检查 ulimit -n 和 fs.file-max 是否匹配业务规模；
- 执行 cat /proc/net/ip_conntrack | wc -l（若启用 nf_conntrack），确认连接跟踪表是否溢出。堡垒机做 NAT/协议解析时依赖此表，默认仅 65536 条，高并发下极易打满，导致新连接无法建立；
- 检查 net.core.somaxconn（全连接队列上限）和 net.core.netdev_max_backlog（网卡收包队列），二者均应 ≥ 65535，否则高并发建连请求会在内核层被丢弃，现象是客户端 connect timeout 但服务端无日志。
验连接复用与会话模型是否合理
堡垒机不是 Web 服务，不能靠 HTTP Keep-Alive 简单复用。它依赖的是 SSH 连接复用或通道复用机制：
- 确认客户端是否开启 ControlMaster（OpenSSH 的连接复用），避免每个命令都新建 TCP+SSH 握手。未启用时，一个用户开 10 个终端窗口，就产生 10 个独立连接；
- 检查堡垒机自身是否对后端目标主机做了连接池管理。例如，同一用户访问 5 台服务器，若每次新建到目标的 SSH 连接，且未复用，则堡垒机内部连接数会线性放大；
- 查看会话空闲超时设置（如 ClientAliveInterval 和 ClientAliveCountMax）。若设为 0 或过大，异常断连的会话长期滞留，占用 socket 和内存，最终拖垮进程。
抓包验证握手与挥手是否异常
在堡垒机服务器上执行：tcpdump -i any 'port 60022 or port 63389' -w bastion.pcap，然后用 Wireshark 分析：
- 是否存在大量重复 SYN（疑似攻击或客户端疯狂重试）；
- 三次握手是否完成？若大量停留在 SYN_SENT 或 SYN_RECV，说明网络路径或防火墙拦截；
- 四次挥手是否完整？若客户端发 FIN 后，堡垒机长时间不回 ACK/FIN，可能是应用卡死或线程阻塞；
- 是否存在大量重传（Retransmission）或零窗口通告（ZeroWindow）？指向网络丢包或接收方缓冲区满，需结合 netstat -i 查网卡错误计数。
