本文依据截至 2026-10-21 更新的公开 Gist 排障记录。下文是对该记录的归纳，并非在本博客中重新执行了实验，也不代表用户本人发言。结论只适用于记录中的具体环境和版本。
一次成功的 CLI 请求至少需要五个环节成立：凭据被正确保存、交给了预期进程、请求能够到达服务端、服务端认可相应身份，以及该身份有权访问目标资源。
这些环节不能互相代替。Vault 返回领取成功，只说明交接完成；身份接口返回正确账号，也不能代替目标仓库的权限检查。目标返回 404 时，同样不能直接断言它不存在——GitHub 对部分认证不足的私有资源请求也会返回 404。
实用的排查顺序是：先判断失败停在哪一层，再做最小对照。网络隧道尚未建立时，换一份凭据未必有用；目标权限未确认时，重复查询身份也不能提供新证据。
公开记录涉及两种凭据交付方式：
| 方式 | 命令进程拿到什么 | 主要边界 |
|---|---|---|
| 自建 Token Vault helper | 本次命令及其子进程可以使用的真实凭据 | 一次性领取链接过期，不会撤销已经领取的 Token |
| 记录中配置的 Network secret | 请求时使用的占位符 | 真实值由网络代理在允许的 HTTPS 目的地请求中替换 |
Vault 解决凭据保存与交接，不负责安装 CLI、修复网络或授予 GitHub 权限。Network secret 则把凭据替换放在网络层，因此仅查看本地环境变量或 CLI 的优先级规则，也不足以推断最终服务端收到的认证。
两种机制都需要明确的信任范围。Vault 服务及其 HTTPS 终止方可以处理真实凭据；使用 API 反代时，反代及其托管链路也进入这一范围。凭据可用不等于可以把它发送到任意地址。
公开记录中的成功结果应当分开理解：
| 路径 | 已有验证 | 不能据此推断 |
|---|---|---|
预配置默认 gh + Network secret + 已授权反代 | 身份及资源元数据读取；另有按 SHA 下载代码快照、内容校验，以及公开仓库创建和 Git Data API 发布记录 | 原生 Git clone / fetch / push 或任意附件传输均可用 |
Vault helper + 普通 gh 2.46.0 + 显式反代 URL | 0.1.8 使用说明下，实际领取、身份与获授权资源元数据 GET，以及临时状态清理 | 已具备前一条路径的写入、下载、分页或重定向能力 |
这张表的重点是证据归属。不能把默认环境认证成功写成 Vault 的成功，也不能把另一条路径的写入结果移植过来。
公开记录的一次对照说明：对测试使用的 gh 2.46.0，完整 URL 中的实际主机影响认证查找。即使同时传入 --hostname github.com，也不会强制自定义反代主机使用 GH_TOKEN。
该记录通过在 helper 启动的短生命周期子进程内，把凭据映射到 GH_ENTERPRISE_TOKEN，修正了这条显式 URL 路径。变量名并不表示必须创建一次持久化的 Enterprise 登录。
值得保留的是操作边界：映射只发生在获准子进程中，不打印值，不写入父 Shell 或持久登录配置，也不把展开后的秘密放入命令行参数。这是已测版本的行为；更换版本后仍应复核，不能当作所有 CLI 的通用规律。
同一个账号在两条请求路径上得到不同资源访问结果，是有价值的观察，但它不能证明平台内部在哪一层做了什么。记录没有完整审计平台网络层或反代服务端，因此不能断言某一凭据来源是最终成功的唯一原因。
类似地，SSH 测试停在 DNS 解析阶段，只能说明连接前置条件没有完成，不能进一步宣布某个目标端口已被封锁。换成 GraphQL、换一个 CLI 版本或者换一个入口，都应当分别验证，而不是凭名字推断它们绕开了相同问题。
经过明确授权和验证后，复杂配置可以留在环境里；日常操作只需要少量检查：
可维护的认证流程，不是隐藏所有复杂性，而是把复杂性放到有明确边界、可以重复验证的位置。证据需要足够具体，日常入口才能足够简单。
本文保留版权；代码仓库的 MIT 许可不覆盖本文。
]]>