GitHub CLI的gh auth、gh api和gh pr主要访问GitHub API；gh repo clone或相关操作还可能调用系统Git。API请求成功，不代表Git HTTPS或SSH通道可用。排查时应把gh进程和Git进程拆开。
GitHub CLI常见网络动作
| 动作 | 主要链路 | 重点检查 |
|---|---|---|
| gh auth login | 认证与API端点 | 代理、浏览器/设备流程和Token |
| gh api/pr/issue | GitHub REST或GraphQL API | API主机、权限和限流 |
| gh repo clone | gh调用Git | HTTPS或SSH远程与Git代理 |
| gh release download | API与发布资源下载 | 重定向、对象存储和大文件 |
代理变量应设置在哪个环境
gh在终端、CI Runner、容器或远程开发机中运行，代理变量必须进入实际进程。桌面浏览器可以登录GitHub，并不代表CI服务账号和容器使用同一路径。代理密码不要留在Shell历史。
gh auth与Git凭据有什么区别
gh保存或读取的Token用于GitHub API，并可按用户选择辅助Git认证；Git自身还可能使用凭据管理器、SSH密钥或独立Token。应查询当前主机的gh认证状态和Git远程协议，但不要输出Token。
HTTPS与SSH为什么分别排查
HTTPS Git通常受Git的HTTP代理和凭据影响；SSH远程使用SSH配置、主机密钥和可能的ProxyJump或ProxyCommand。gh API可用时，SSH端口仍可能被企业网络阻断。
Git代理完整方法见Git HTTP代理、SSH与凭据安全。
GitHub Enterprise Server有什么不同
企业版实例使用组织自己的主机、证书和认证策略。应通过gh的主机配置明确目标，避免Token发送到错误主机。内部实例可能应直连或通过公司代理，公共GitHub则走外部出口。
407、401和403如何区分
- 407：企业代理认证；
- 401：GitHub Token无效或过期；
- 403：权限不足、组织策略或API限流；
- SSH Permission denied：SSH密钥或仓库权限；
- x509错误：系统或企业CA配置。
发布资源为何可能下载失败
Release资源可从API跳转到文件托管或对象存储，目标域名和传输大小与普通API不同。代理必须允许重定向目标和长时间下载。大文件中断后应校验哈希，不要只按文件名判断完整。
证书问题要同时检查gh与Git
gh和系统Git可能使用不同TLS实现或CA来源。给Git配置企业CA，不一定修复gh；反过来也一样。应分别验证API和仓库传输，并保留主机名校验。
CI中怎样使用Token
使用平台提供的短期或范围受限Token，按仓库和工作流最小授权。不要把个人长期Token写入脚本、镜像或普通变量。调试时关闭命令回显，并检查gh日志、Git远程URL和错误输出没有泄露Token。
限流不是代理超时
API达到速率限制时可能返回403或相关响应头，应查看限流状态并减少重复请求、使用缓存或等待重置。切换代理IP不会改变账号或Token的API配额，也不应被用来规避平台限制。
排查顺序
- 记录gh、Git版本和目标主机；
- 确认失败是API还是Git操作；
- 检查进程代理和Git远程协议；
- 区分407、Token、权限、限流和TLS；
- 用只读API和授权仓库分别测试；
- 核对Release重定向与大文件；
- 清理调试Token和详细日志。
结论
GitHub CLI代理问题必须拆分API与Git链路。gh认证成功只能证明API身份的一部分，仓库HTTPS、SSH和发布资源下载仍要按各自网络与凭据单独验证。
