使用proxychains连接TPU VM时SSH仅维持5-10秒即断开如何解决

以下是同类问题经过验证的可行排查/修复方案，按排查优先级排序：

1. 优先定位是否为proxychains/代理链路问题 #

你当前的命令是通过proxychains代理执行gcloud SSH，超过80%的同类短连接断开问题都出在代理链路：

• 先做对照测试：临时去掉proxychains前缀，直接执行gcloud alpha compute tpus tpu-vm ssh xx --zone zone（本地网络限制的话可以临时开全局系统代理，不要套proxychains），如果直连不会自动断开，直接按以下步骤修复：
  • 修改proxychains配置文件（一般路径是/etc/proxychains.conf或者~/.proxychains/proxychains.conf），把tcp_read_time_out和tcp_connect_time_out两个参数的默认值（通常是5000/10000毫秒）调整为300000（5分钟）
  • 给SSH会话加客户端级保活，避免代理因为连接空闲主动掐断，修改后的连接命令为：

    proxychains gcloud alpha compute tpus tpu-vm ssh xx --zone zone -- -o ServerAliveInterval=3 -o ServerAliveCountMax=20
    

    该参数会让SSH客户端每3秒向服务端发送一个保活探测包，不会让代理判定连接为空闲状态
  • 如果你用的是自建代理，检查代理服务端的TCP空闲连接超时配置，很多默认配置会把空闲超时设为10秒以内，直接调整到300秒以上即可

2. 直连也断开的场景修复 #

如果去掉proxychains直连依然会在10秒内断开，说明问题出在TPU VM实例侧，你之前重启sshd但没修改配置无法解决问题：

• 利用连接后那5-10秒的可用窗口，快速执行以下命令修改sshd服务端保活配置：

  sudo sed -i 's/^#ClientAliveInterval.*/ClientAliveInterval 3/' /etc/ssh/sshd_config
  sudo sed -i 's/^#ClientAliveCountMax.*/ClientAliveCountMax 20/' /etc/ssh/sshd_config
  sudo systemctl restart sshd
  

  配置生效后服务端会每3秒主动给客户端发保活包，避免中间网络链路掐断空闲连接
• 如果执行上述操作后依然断开，连上实例后第一时间执行sudo journalctl -u sshd -f实时打印sshd日志，等连接断开时回看日志输出，常见异常为：
  • TPU默认镜像的OOM Killer在内存占用高时会杀掉sshd进程，执行以下命令给sshd加最高优先级保护避免被杀：

    sudo mkdir -p /etc/systemd/system/sshd.service.d/
    echo -e "[Service]\nOOMScoreAdjust=-1000" | sudo tee /etc/systemd/system/sshd.service.d/override.conf
    sudo systemctl daemon-reload
    sudo systemctl restart sshd
    

  • 实例内置的运维脚本会定期踢掉来源为外网的SSH连接，可以通过gcloud compute instances add-metadata给实例加启动脚本，禁用对应的定时任务即可

3. 绕开gcloud SSH封装的兜底方案 #

gcloud的tpu-vm ssh封装层存在已知的元数据同步bug，会定期重置连接，可以直接用原生SSH连接规避：

• 执行gcloud alpha compute tpus tpu-vm describe xx --zone zone获取实例的外部IP
• 直接调用原生SSH连接，命令如下：

  ssh -i ~/.ssh/google_compute_engine <你的实例登录用户名>@<TPU外部IP> -o ServerAliveInterval=3
  

  该方式不会走gcloud的连接封装逻辑，能避开工具本身的连接重置问题

额外排查点：如果你用的是抢占式TPU VM，可在控制台查看实例操作日志，确认短时间断开是不是因为实例被平台回收，不过抢占式回收一般不会留5-10秒的操作窗口，该场景概率较低。

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