GitHub 和 Git 代理怎么配置：查看、清理、设置与令牌存放

GitHub 访问不稳定时，很多人会在 Git 里配置代理。代理能解决网络问题，但也容易留下历史配置，导致之后排查变复杂。

这篇整理 Git 代理的几个常用操作。

查看当前配置

先看 Git 全局配置：

git config --global -l

也可以直接查看配置文件：

cat ~/.gitconfig

如果项目里还有局部配置，还要进入仓库查看：

git config --local -l

很多代理问题不是没有配置，而是全局和局部配置互相覆盖。

清除全局代理

如果想恢复直连，可以清除全局代理：

git config --global --unset http.proxy
git config --global --unset https.proxy

清完后再看一遍：

git config --global -l

确认 http.proxy 和 https.proxy 不再出现。

设置代理

如果本机有 SOCKS5 代理，可以这样设置：

git config --global http.proxy 'socks5://127.0.0.1:1080'
git config --global https.proxy 'socks5://127.0.0.1:1080'

端口要按自己的代理客户端实际配置填写。不要照抄端口后就默认可用。

HTTP 代理和 GitHub 令牌分开管理

代理配置只解决网络访问问题，不等于认证。GitHub token、SSH key、用户名密码要单独管理。

建议：

• token 不写进公开仓库。
• token 不放在 README 示例里。
• 需要长期保存时放私密笔记或系统钥匙串。
• 过期或泄露后及时吊销。
• CI/CD 使用专门的密钥管理方式。

网络配置和身份凭据是两件事，混在一起很危险。

排查顺序

GitHub 拉取或推送失败时，可以按这个顺序看：

1. 当前仓库 remote 地址。
2. 是否走 HTTPS 还是 SSH。
3. 全局代理和局部代理。
4. 本机代理服务是否启动。
5. token 或 SSH key 是否有效。
6. GitHub 是否可从浏览器访问。
7. 公司或本地网络是否拦截。

代理不是万能开关。先确认失败发生在网络层还是认证层，排查会快很多。