autossh隧道新增失效求助：替换旧隧道即可正常运行

从你描述的现象来看，连接数限制确实是一个值得怀疑的方向，但还有其他几个潜在因素也会导致这种「替换旧隧道新隧道就正常，反过来旧隧道失效」的情况，咱们一步步拆解分析：

1. SSH服务端/客户端的连接数限制 #

这是最有可能的核心原因，分两部分排查：

• 服务器端限制：SSH服务（sshd）有两个关键配置会直接影响并发会话/隧道数量：

  • MaxSessions：控制单个SSH连接允许开启的最大会话数（SSH隧道属于会话的一种），默认值通常是10。如果你当前运行了20条隧道，要是这些隧道都挂在同一个SSH主连接下，早就超过默认限制了——这时候新增隧道会被拒绝，但替换掉旧隧道相当于释放了一个会话名额，新隧道就能挤进去。
  • MaxStartups：控制并发未认证的SSH连接数，默认是10:30:100（前10个正常处理，10-30个按30%概率拒绝，超过30个全部拒绝）。如果你的autossh实例启动时短时间内发起大量连接，可能触发这个限制。
    你可以登录到SSH服务器上，用命令查看当前配置：

  grep -E "MaxSessions|MaxStartups" /etc/ssh/sshd_config
  

• 客户端系统限制：每个SSH隧道都会占用一个文件描述符，而Linux系统对每个进程的文件描述符数量有限制（默认通常是1024）。如果你的autossh进程已经占用了接近上限的文件描述符，新增隧道就会失败，替换旧隧道则会释放一个描述符，让新隧道能正常启动。
  查看当前shell的文件描述符限制：

  ulimit -n
  

2. autossh的运行机制与资源冲突 #

autossh本身不会限制隧道数量，但如果你的所有autossh实例共享了某些资源，就可能出现资源抢占的情况：

• 检查你启动autossh的命令是否使用了-M参数指定监控端口，如果多个实例用了同一个监控端口，会导致冲突；
• 尝试给新隧道单独指定一个监控端口，比如：

  autossh -M 20001 -o GatewayPorts=yes -i /home/user/.ssh/user -NL 192.168.0.2:80:1.2.3.4:80 user@servernew.com
  

  （注意监控端口不要和其他服务冲突）

3. 隐形的端口/目标端限制 #

虽然你用了不同的本地端口，但还有两个容易忽略的点：

• 本地端口占用：确认192.168.0.2:80真的没有被其他进程占用，用命令检查：

  ss -tulpn | grep ":80"
  

• 目标服务器限制：目标服务器（1.2.3.4）的防火墙或安全组可能限制了单个源IP的并发连接数，当你新增隧道时触发了这个限制，但替换旧隧道时，旧隧道的连接被释放，新隧道就能建立。可以用telnet 1.2.3.4 80测试直接连接是否能成功，或者联系目标服务器管理员确认规则。

4. SSH配置的冗余问题 #

注意到你成功的命令里重复了多次-o GatewayPorts，虽然最后-o GatewayPorts=yes会覆盖前面的参数，但冗余配置可能带来潜在的解析问题，建议简化命令，只保留一次-o GatewayPorts=yes，避免不必要的干扰。

排查步骤建议 #

1. 先检查SSH服务器的MaxSessions配置，如果小于当前隧道数，修改为更大的值（比如30），然后重启sshd服务；
2. 查看客户端的文件描述符限制，如果较低，临时调整为ulimit -n 2048，测试新增隧道是否正常；
3. 启动新隧道时加上-v参数开启调试日志，查看具体的错误信息：

   autossh -v -o GatewayPorts=yes -i /home/user/.ssh/user -NL 192.168.0.2:80:1.2.3.4:80 user@servernew.com
   

   日志里会明确告诉你是连接被服务器拒绝、文件描述符不足还是其他问题；
4. 检查目标服务器的连接限制，确认源IP没有被限流。

内容的提问来源于stack exchange，提问作者useresxi