在公司或家庭内网开发时，经常遇到代码写好了却推不上远程仓库的情况。尤其是用 Git 推送代码到远程仓库，看着命令行提示“Connection timed out”或者“Could not resolve host”，挺让人抓狂的。其实问题不一定出在 Git 本身，更多是网络环境限制导致的。
为什么内网环境下 Git 推送容易失败？
很多公司或局域网使用的是内网 IP，没有公网访问权限。当你执行 git push 到 GitHub、GitLab 或公司自建的 Git 服务器时，如果该服务器在外部网络，而你的网络出口被防火墙拦截或 NAT 映射没配好，连接自然就断了。
比如你在办公室写完一个功能，兴冲冲地敲下：
git add .
git commit -m "完成用户登录模块"
git push origin main结果返回：
ssh: connect to host github.com port 22: Connection timed out
fatal: Could not read from remote repository.这时候别急着重装 Git，先看看是不是网络问题。
用内网穿透解决 Git 推送难题
如果你的开发机在内网，但又必须把代码推到外网 Git 服务器，可以借助内网穿透工具打通链路。比如常用的 frp、ngrok 或花生壳，能把本地的 Git 服务“映射”出去。
假设你公司在用自建 GitLab，但 GitLab 服务器部署在办公室内网，外部无法访问。这时可以在内网服务器上部署 frpc 客户端，把本地的 Git 端口（通常是 22 或 8080）通过公网服务器转发出来。
配置示例（frpc.ini）：
[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 60022然后你在外部网络就可以通过公网 IP 的 60022 端口 SSH 连接到内网的 Git 服务。接着修改本地仓库的远程地址：
git remote set-url origin git@your-public-ip:60022/username/project.git再执行 git push，就能顺利上传了。
避免频繁输入密码的小技巧
每次推送都要输 SSH 密钥密码太烦人。可以用 ssh-agent 缓存密钥：
eval $(ssh-agent)
ssh-add ~/.ssh/id_rsa之后在同一会话中，git push 就不会再提示输入密码了。
HTTPS 和 SSH 哪个更适合内网推送？
如果公司防火墙只放行 HTTPS 流量，那用 SSH 推送肯定走不通。这时候可以把远程仓库地址从 SSH 换成 HTTPS：
git remote set-url origin https://github.com/username/project.git配合个人访问令牌（Personal Access Token），就能绕过密码验证限制，适合在受限网络中使用。
内网开发不是阻碍，只要链路通了，Git 推送就跟在家一样顺畅。关键是要搞清楚网络在哪一环断了，再用合适的穿透方式接上。