GCP平台VM中git fetch、git pull命令挂起无响应如何排查

按以下顺序从易到难排查，不需要改动业务配置：

• 第一步先定位卡滞位置，执行带debug参数的命令获取详细日志：
  GIT_TRACE=1 GIT_SSH_COMMAND="ssh -vvv" git fetch
  根据最后停留的日志段直接定位问题域：
  • 停在Connecting to github.com port 22：属于22端口出站链路不通
  • 停在SSH认证、host key校验阶段：属于认证配置问题
  • 停在对象枚举、包接收阶段：属于链路传输参数问题
• 优先处理最高发的22端口出站拦截问题：
  先执行nc -zv github.com 22测试连通性，如果超时无响应，就是实例到GitHub 22端口的出站流量被拦截——这类问题不需要你修改本地配置，多是GCP区域出口策略调整、组织级VPC防火墙规则更新导致。
  直接用GitHub支持的443端口承载SSH流量验证，编辑~/.ssh/config添加以下配置：

  Host github.com
    Hostname ssh.github.com
    Port 443
    User git
  

  配置完成后先执行ssh -T git@github.com验证，返回认证成功提示后再执行git操作即可恢复。
• 排查GCP侧网络配置：
  • 检查实例所在VPC的出站防火墙规则，确认是否有新增的拒绝公网22端口出站的策略，组织级管理员下发的统一规则不会触发本地配置变更通知。
  • 如果实例通过Cloud NAT访问公网，查看NAT监控和日志，确认是否存在端口耗尽、出站连接超时配置异常、丢包的情况。
• 排查MTU不匹配问题：
  如果debug显示SSH连接已建立，但传输数据时挂死，基本是MTU配置不匹配导致。GCP VPC默认MTU为1460，如果实例网卡MTU配置为1500，会出现大包传输丢包、连接卡滞的问题。
  执行ping -M do -s 1432 github.com（1432+28字节ICMP头=1460，匹配GCP VPC默认MTU）验证，如果能通，直接把实例网卡MTU调整为1460即可：临时调整执行sudo ip link set dev [你的网卡名，一般是ens4] mtu 1460，永久调整需修改系统网络配置文件。
• 最后排查基础解析和配置异常：
  • 执行nslookup github.com确认DNS解析结果正常，无解析劫持到错误IP的情况。
  • 删除~/.ssh/known_hosts中所有github.com相关的条目，重新连接验证host key，避免历史异常key导致的连接卡滞。

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