Composer不支持GitHub API专用代理，仅能通过全局http-proxy/https-proxy或github-oauth配置解决；前者需成对设置且格式严格，后者更稳定可靠。
Composer 本身不支持“GitHub API 的本地代理”这种配置——它没有 github-proxy 或类似配置项，也不能把 GitHub API 请求转发到本地代理服务。所谓“本地代理”是误读，真正能起作用的是：用 http-proxy/https-proxy 全局配置让所有 HTTP/HTTPS 流量（含 GitHub API）走代理，或用 github-oauth 认证绕过限流。两者目的不同，不能混用。
为什么不能配“GitHub API 专用代理”
Composer 没有按域名或 API 类型分流代理的能力。它的 http-proxy 和 https-proxy 是全局生效的底层 HTTP 客户端设置，对所有目标（packagist.org、api.github.com、raw.githubusercontent.com）一视同仁。你无法单独指定“只让 GitHub API 走 127.0.0.1:8080，其他走直连”。强行在 repositories 里改 URL 为本地地址（比如 "url": "http://localhost/github"）只会导致 404 或解析失败——Composer 不会自动重写请求头或做反向代理映射。
真正有效的两种稳定方案
遇到 GitHub API 卡顿或 403，优先判断是网络连通性问题，还是认证限流问题：
- 如果
curl -i https://api.github.com/rate_limit返回X-RateLimit-Remaining: 0→ 是认证缺失，必须配github-oauth.github.com - 如果
curl -i https://api.github.com/rate_limit直接超时或连接拒绝 → 是网络不通，才需要http-proxy/https-proxy
二者互斥，不要同时启用再互相干扰。例如：已配了 Token 却又设了错误代理，反而可能因代理不可达导致认证请求失败，最终退回到未认证状态，触发限流。
proxy 配置必须成对且格式严格
http-proxy 和 https-proxy 必须同时设置，缺一不可。即使你的代理地址是 http://127.0.0.1:7890，也要分别执行：
composer config --global http-proxy http://127.0.0.1:7890 composer config --global https-proxy http://127.0.0.1:7890
常见错误包括：
- 只设
http-proxy，结果 GitHub API（HTTPS）请求 fallback 直连失败 - 代理地址含特殊字符（如
@、:）未 URL 编码，导致Invalid URI supplied - 在 PowerShell 中直接粘贴 token 或 proxy 地址，
$被解释为变量而截断
验证是否生效：运行 composer config --global --list | grep -E "(http-proxy|https-proxy)"，应输出两行且值一致。
Token 配置比代理更优先、更可靠
对于绝大多数国内用户，配 github-oauth.github.com 是更轻量、更稳定的解法。它不依赖外部代理服务稳定性，也不受 DNS 或 TLS 握手影响，只需一次写入即可提升限额至 5000 次/小时。操作链极短：
composer config --global github-oauth.github.com your_token_here
注意三点：
- host 名必须是
github.com，不是api.github.com或www.github.com - Token 必须带
repo权限（public_repo对纯公开包够用，但含 fork 或私有依赖时建议全repo） - Windows 用户无需
chmod 600，但要确认%APPDATA%\Composer\auth.json未被系统设为只读
Token 生效后，Composer 所有 GitHub 相关请求（metadata 查询、dist zip 下载链接生成）都会自动携带 Authorization: Bearer 头，不再受匿名限流约束——这才是真正的“稳定性提升”，而非靠脆弱的代理链中转。
