代理中的fake-ip导致的git-ssh提交失败问题

不使用旁路由,直接使用 sparkle 来进行代理时,突然出现了 git pull 报错问题。之前好像也没有出现过

#status / growing #type / debug #resource / git

[!info] related notes

代理中的fake-ip导致的git-ssh提交失败问题

Git SSH 协议被代理拦截 (Connection closed) 的排查与终极解决

🚩 问题现象

在使用代理工具(如 Clash / Mihomo)的网络环境下,执行 git pullgit push (SSH 协议) 时,终端报错并直接断开连接:

Connection closed by 198.18.0.x port 22  
fatal: Could not read from remote repository.

🔍 排查过程与根本原因

这个问题通常是由代理机制和节点服务商的防火墙规则叠加导致的,共分为两层阻碍:

阻碍一:代理工具的 Fake-IP 机制拦截

  • 现象:报错信息中的 IP 是 198.18.x.x 这种保留网段地址。
  • 原因:代理软件启用了 Fake-IP 模式,Git 的 SSH 客户端尝试解析 github.com 时,拿到了这个虚假 IP。但代理内核没有正确处理或转发 SSH (TCP 22 端口) 的流量,导致握手失败,直接被 Closed。

阻碍二:代理服务商(节点)屏蔽 22 端口

  • 现象:通过代理规则排除了 Fake-IP 拦截后,Git 拿到了 GitHub 的真实 IP (20.205.x.x),但依然报错 Connection closed。使用 ssh -T -v git@github.com 开启 Debug 模式排查,发现连接卡死在互相发送 SSH 版本号的阶段(Local version string SSH-2.0…)。
  • 原因:流量虽然成功交给了本地代理端口(如 127.0.0.1:7890),但绝大多数机场/代理节点为了防止服务器被用来进行 SSH 暴力破解,会在服务端强制阻断所有对外的 22 端口流量。数据出不去,导致连接死锁。

✅ 终极解决方案:走 443 端口伪装流量

针对节点屏蔽 22 端口的“绝杀”方案,是利用 GitHub 官方提供的 443 端口 SSH 中继服务(ssh.github.com)。443 是标准的 HTTPS 网页端口,代理节点不会对其进行拦截。

操作步骤

  1. 编辑 SSH 客户端配置文件:

    vim ~/.ssh/config
  2. 填入或修改为以下配置(注意替换你的实际代理端口号):

    Host github.com
        HostName ssh.github.com
        User git
        Port 443
        # 指定通过本地代理转发流量 (假设代理混合端口为 7890)
        # Linux/macOS/WSL 环境使用 nc (需确保安装了 netcat-openbsd)
        ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p
    
        # 如果是纯 Windows Git Bash 环境,请注释掉上一行,使用下面这行:
        # ProxyCommand connect -S 127.0.0.1:7890 %h %p
  3. 保存后,再次执行 git pushgit pull 即可瞬间秒连。

💡 避坑补充

Git 自带的 git config --global http.proxy 代理配置仅对 HTTP/HTTPS 协议有效。如果是 git@github.com:… 格式的 SSH 协议仓库,Git 会将网络连接委托给系统底层的 SSH 客户端处理,因此必须去修改 ~/.ssh/config 才能让代理生效。

创建于 2026/3/2 更新于 2026/5/27