Git Push 失败问题总结与解决方法

1. 背景

在使用 VS Code Remote SSH 连接 ModelArts 训练环境后，可以正常编辑远端代码，但通过 VS Code Git 插件或命令行执行：

bash 复制代码

git push

时出现连接超时问题。

典型报错如下：

text 复制代码

ssh: connect to host github.com port 22: Connection timed out
fatal: Could not read from remote repository.

这个问题的核心不是 Git 仓库不存在，也不是本地 VS Code 配置错误，而是 ModelArts 远端训练环境访问 GitHub SSH 默认端口时被网络限制。

2. 问题现象

2.1 VS Code Git 插件报错

VS Code 弹窗中显示：

text 复制代码

Git: ssh: connect to host github.com port 22: Connection timed out

2.2 Git 日志中的关键信息

text 复制代码

git push origin main:main
ssh: connect to host github.com port 22: Connection timed out
fatal: Could not read from remote repository.

其中最关键的是：

text 复制代码

github.com port 22: Connection timed out

这说明 Git 正在通过 SSH 协议访问 GitHub 的 22 端口，但该端口在 ModelArts 环境中无法连通。

3. 根本原因

3.1 Git push 实际是在远端执行

在 VS Code Remote SSH 模式下：

text 复制代码

本地 Windows / VS Code
        ↓
远程连接到 ModelArts
        ↓
Git 操作在 ModelArts 远端 Linux 环境中执行

因此，虽然 VS Code 在本地运行，但 git push 使用的是远端 ModelArts 节点的网络环境。

如果 ModelArts 节点不能访问 GitHub 的 SSH 22 端口，Git push 就会失败。

3.2 Git 默认 SSH 地址会走 22 端口

如果仓库 remote 是这种形式：

bash 复制代码

git@github.com:USER/REPO.git

那么 Git 会默认使用 SSH 协议访问：

text 复制代码

github.com:22

而 ModelArts 环境中该端口通常不可用，因此出现 timeout。

4. 为什么配置代理后仍然失败？

4.1 `http_proxy` / `https_proxy` 对 SSH 协议无效

之前尝试配置：

bash 复制代码

export http_proxy=http://127.0.0.1:10240
export https_proxy=http://127.0.0.1:10240

但仍然报：

text 复制代码

ssh: connect to host github.com port 22: Connection timed out

原因是：

text 复制代码

http_proxy / https_proxy 只影响 HTTP/HTTPS 请求，
不会自动影响 SSH 协议。

如果 Git remote 仍然是：

bash 复制代码

git@github.com:USER/REPO.git

那么 Git 仍然走 SSH，而不是 HTTPS，因此代理环境变量不会生效。

4.2 `RemoteForward` 不是 Git 代理

SSH config 中配置过类似：

sshconfig 复制代码

RemoteForward 10240 127.0.0.1:7897

它的含义是：

text 复制代码

在远端 ModelArts 上打开 10240 端口，
并把它转发到本地机器的 7897 端口。

但是它本身只是端口转发，不会让 Git 自动使用该端口。

也就是说：

text 复制代码

RemoteForward 10240 ≠ Git 自动走代理

Git 是否走代理，取决于 Git 使用的是 HTTP/HTTPS 还是 SSH，以及是否正确配置了对应协议的代理。

5. 为什么 `10240` 和 `7897` 容易混淆？

假设本地代理服务运行在：

text 复制代码

127.0.0.1:7897

SSH 配置中有：

sshconfig 复制代码

RemoteForward 10240 127.0.0.1:7897

则链路含义是：

text 复制代码

ModelArts 远端 127.0.0.1:10240
        ↓
SSH RemoteForward 隧道
        ↓
本地 Windows 127.0.0.1:7897

因此，在远端 ModelArts 上如果要访问被转发过来的代理入口，应该使用：

bash 复制代码

http://127.0.0.1:10240

而不是：

bash 复制代码

http://127.0.0.1:7897

因为 7897 是本地 Windows 上的端口，远端 ModelArts 上不一定存在该端口服务。

不过，即使 10240 代理链路配置正确，它也主要影响 HTTP/HTTPS 请求，不会自动解决 SSH 走 22 端口的问题。

6. 最终有效解决方案

6.1 使用 GitHub 官方 SSH 443 端口

执行：

bash 复制代码

git config --global url."ssh://git@ssh.github.com:443/".insteadOf git@github.com:

这条命令会让 Git 自动把：

text 复制代码

git@github.com:USER/REPO.git

重写为：

text 复制代码

ssh://git@ssh.github.com:443/USER/REPO.git

7. 为什么这条命令能解决问题？

7.1 原来的访问路径

原始 Git remote：

bash 复制代码

git@github.com:USER/REPO.git

实际访问：

text 复制代码

Git
 ↓
SSH
 ↓
github.com:22
 ↓
连接超时

7.2 修改后的访问路径

执行：

bash 复制代码

git config --global url."ssh://git@ssh.github.com:443/".insteadOf git@github.com:

之后，Git 会自动改走：

text 复制代码

Git
 ↓
SSH
 ↓
ssh.github.com:443
 ↓
连接成功

7.3 本质区别

方式	访问地址	端口	ModelArts 中状态
默认 SSH	github.com	22	通常被封
GitHub SSH over 443	ssh.github.com	443	通常可用
HTTPS Git	github.com	443	通常可用

这条命令的本质是：

text 复制代码

不再让 Git SSH 访问 github.com:22，
而是改用 GitHub 提供的 ssh.github.com:443 入口。

8. 第一次连接时的提示是什么意思？

执行：

bash 复制代码

ssh -T -p 443 git@ssh.github.com

可能看到：

text 复制代码

The authenticity of host '[ssh.github.com]:443' can't be established.
ECDSA key fingerprint is SHA256:...

这不是错误，而是 SSH 第一次连接新主机时的正常安全确认。

如果确认连接的是 GitHub，可以输入：

text 复制代码

yes

之后 SSH 会把该主机指纹写入：

bash 复制代码

~/.ssh/known_hosts

后续连接就不会再重复询问。

9. 验证方法

9.1 查看当前 remote

bash 复制代码

git remote -v

如果显示类似：

text 复制代码

origin  git@github.com:USER/REPO.git (fetch)
origin  git@github.com:USER/REPO.git (push)

也没有问题，因为 insteadOf 会在 Git 操作时自动重写 URL。

9.2 测试 GitHub SSH 443 是否可用

bash 复制代码

ssh -T -p 443 git@ssh.github.com

成功时通常会看到类似：

text 复制代码

Hi USER! You've successfully authenticated, but GitHub does not provide shell access.

9.3 测试 push

bash 复制代码

git push

如果 key 和仓库权限没有问题，此时应该可以正常 push。

10. 备选解决方案

10.1 方案 A：继续使用 SSH，但强制走 443

推荐命令：

bash 复制代码

git config --global url."ssh://git@ssh.github.com:443/".insteadOf git@github.com:

优点：

不需要改仓库 remote
仍然使用 SSH key
适合已经配置好 GitHub SSH key 的环境

10.2 方案 B：改用 HTTPS remote

也可以把 remote 改成 HTTPS：

bash 复制代码

git remote set-url origin https://github.com/USER/REPO.git

然后：

bash 复制代码

git push

这种方式走 HTTPS 443 端口，通常不会触发 SSH 22 端口问题。

缺点是可能需要配置 GitHub token 或凭据管理。

10.3 方案 C：通过 HTTP/HTTPS 代理访问

如果要让 Git 的 HTTPS 请求走代理，可以配置：

bash 复制代码

git config --global http.proxy http://127.0.0.1:10240
git config --global https.proxy http://127.0.0.1:10240

注意：该方法只对 HTTPS remote 有意义，例如：

bash 复制代码

https://github.com/USER/REPO.git

如果 remote 仍然是：

bash 复制代码

git@github.com:USER/REPO.git

则该代理配置不会解决 SSH 22 端口问题。

11. 常用排查命令

查看 remote

bash 复制代码

git remote -v

查看 Git URL 重写配置

bash 复制代码

git config --global --get-regexp url

测试 GitHub 默认 SSH 22 端口

bash 复制代码

ssh -T git@github.com

如果超时，说明 22 端口不可用。

测试 GitHub SSH 443 端口

bash 复制代码

ssh -T -p 443 git@ssh.github.com

如果能进入认证阶段，说明 443 通道可用。

测试当前 Git push

bash 复制代码

git push

12. 如何撤销该配置？

如果之后不想使用 URL 重写，可以执行：

bash 复制代码

git config --global --unset url."ssh://git@ssh.github.com:443/".insteadOf

然后查看是否删除成功：

bash 复制代码

git config --global --get-regexp url

13. 最终结论

本次问题的关键点是：

text 复制代码

Git push 使用 SSH remote 时，默认访问 github.com:22。
ModelArts 环境中 github.com:22 无法连通，因此 push 超时。

有效解决方法是：

bash 复制代码

git config --global url."ssh://git@ssh.github.com:443/".insteadOf git@github.com:

该方法会让 GitHub SSH 从默认 22 端口切换到 443 端口，从而绕过 ModelArts 对 22 端口的网络限制。

一句话总结：

text 复制代码

不是 VS Code Git 插件的问题，
也不是 RemoteForward 配置本身的问题，
而是 Git SSH 默认走 22 端口；
改用 GitHub SSH over 443 后即可解决。

Git Push 失败问题总结与解决方法

1. 背景

2. 问题现象

2.1 VS Code Git 插件报错

2.2 Git 日志中的关键信息

3. 根本原因

3.1 Git push 实际是在远端执行

3.2 Git 默认 SSH 地址会走 22 端口

4. 为什么配置代理后仍然失败？

4.1 http_proxy / https_proxy 对 SSH 协议无效

4.2 RemoteForward 不是 Git 代理

5. 为什么 10240 和 7897 容易混淆？

6. 最终有效解决方案

6.1 使用 GitHub 官方 SSH 443 端口

7. 为什么这条命令能解决问题？

7.1 原来的访问路径

7.2 修改后的访问路径

7.3 本质区别

8. 第一次连接时的提示是什么意思？

9. 验证方法

9.1 查看当前 remote

9.2 测试 GitHub SSH 443 是否可用

9.3 测试 push

10. 备选解决方案

10.1 方案 A：继续使用 SSH，但强制走 443

10.2 方案 B：改用 HTTPS remote

10.3 方案 C：通过 HTTP/HTTPS 代理访问

11. 常用排查命令

查看 remote

查看 Git URL 重写配置

测试 GitHub 默认 SSH 22 端口

测试 GitHub SSH 443 端口

测试当前 Git push

12. 如何撤销该配置？

13. 最终结论

4.1 `http_proxy` / `https_proxy` 对 SSH 协议无效

4.2 `RemoteForward` 不是 Git 代理

5. 为什么 `10240` 和 `7897` 容易混淆？