curl 问题报告：OpenWrt 上 Git 在 HTTPS 代理 407 重试后崩溃

curl 项目在 2026 年 9 月 13 日收到一则问题报告：在一个基于 OpenWrt 的环境中，认证 HTTPS 代理返回 407 Proxy Authentication Required 后，git-remote-https 可复现地以 signal 11 终止。报告者称，预先强制选择 Basic 代理认证可避开质询与重连路径，并让 Git 请求完成。

该问题目前仍为 open，并带有“outdated”标签。维护者尚未确认根因、补丁或普遍回归结论。现有证据只适用于报告者的特定软件包与平台组合，不能扩展为所有 curl、Git、OpenWrt 或代理环境的结论。

报告中的环境

报告列出 iStoreOS 24.10.8、AArch64、Git 2.50.1、curl/libcurl 8.19.0 软件包、OpenSSL 3.0.21 与 nghttp2 1.63.0。代理是要求 HTTP Basic 认证的 HTTPS CONNECT 网关，目标使用 GitHub HTTPS smart HTTP。

报告中的跟踪信息显示：客户端先发送未认证 CONNECT，收到声明 Basic 的 407，开始重新连接，随后在第二次认证 CONNECT 发出前崩溃。

内部来源说明：curl 项目问题“git-remote-https segfaults after HTTPS proxy 407 challenge with libcurl 8.19.0 on OpenWrt; preemptive Basic works”，提交于 2026 年 9 月 13 日；复核时仍为 open，标签为 TLS、connecting and proxies、outdated。

这并不是简单的连通性结论

报告者提供了三组有价值的对照：

• 不提供凭据时，Git 按预期收到 407 并正常报错退出，没有崩溃。
• 预先强制 Basic 代理认证时，Git 操作完成。
• 独立 curl 通过同一认证 HTTPS 代理工作正常。

这些现象把报告中的失败范围缩小到特定 Git 与 libcurl 组合所经历的质询、重连或认证重试路径，但不能证明具体哪个组件存在缺陷，也不能说明代理不可用。

运营人员应保留这一层次区分：网关可达、TLS 成功且凭据有效时，某个客户端集成仍可能在 407 状态转换中失败。

使用受控 A/B 矩阵复现

只使用获准测试的代码仓库与代理账户。固定目标、网关、客户端主机、凭据和网络路径，然后比较：

1. Git 不带代理凭据，预期干净地返回 407。
2. Git 使用常规质询式认证。
3. Git 显式选择获批认证方式。
4. 独立 curl 通过同一网关。
5. 同一设备上的另一组 Git 与 libcurl 软件包。
6. 若条件允许，在参考操作系统中运行相同软件包构建。

不要把密码放在命令行，也不要粘贴到跟踪记录。使用操作系统认可的凭据机制；共享证据前必须删除 Proxy-Authorization、用户名、网关地址、仓库 Token 和私密路径。

严格限制临时规避范围

报告中的预先 Basic 配置只是一个环境的观察结果，不是通用建议。采用前必须确认代理侧 TLS 边界符合安全策略，并确保凭据绝不会通过未加密连接发送。

优先使用针对仓库或主机的 Git 设置，避免全局改动。记录原始配置、验证回滚，并确认无关目标不会继承该设置。规避成功也不能替代根因调查，因为镜像或软件包更新后，崩溃路径可能再次出现。

系统化处理 407 可参考curl 代理认证 407 排错指南。若不同客户端认证结果不一致，还应执行代理凭据编码验证。

测试当前受支持软件包

由于问题带有 outdated 标签，升级处理前应在设备可用的最新受支持 Git、curl 和 libcurl 软件包上复现。不要直接替换生产二进制。创建测试镜像，保留相同代理与仓库矩阵，并比较首个失败阶段。

记录 Git 版本、curl 版本、libcurl 功能列表、TLS 后端、CPU 架构、C 库、HTTP/2 库、软件包来源和准确代理协议。Git 可能加载与独立 curl 不同的 libcurl，因此“curl 能用”不代表两者使用相同库或选项。

HTTPS 代理 TLS 与密码套件兼容性测试可先确认代理侧与目标侧 TLS 边界都符合策略，再把重点转向认证重试。

安全收集崩溃证据

只收集必要信息：

• 失败边界的脱敏 Git 与 curl 跟踪。
• 退出信号，以及策略允许时的符号化回溯。
• 软件包版本和依赖链接关系。
• 删除凭据后的预期 407 响应头。
• 每个 A/B 案例的结果与时间戳。
• 第二次认证 CONNECT 是否真正发出。
• 干净进程与设备重启后是否仍会崩溃。

核心转储可能包含凭据、URL、环境变量、内存内容和客户数据，未经审查不得公开。应限制诊断资料访问权限并设置保留期限。

运营响应检查清单

• 辅助进程持续崩溃时停止自动重试。
• 使用独立且获批的客户端确认代理基本能力。
• 分别记录代理 TLS、407 认证和目标 TLS 结果。
• 对比质询式认证与显式选择认证方式。
• 确认 Git 实际加载的 libcurl。
• 在预发布环境测试当前受支持的软件包集。
• 把临时配置限制在目标主机或仓库。
• 分享前脱敏跟踪并审查崩溃资料。
• 保留首次失败指标，不能用规避后的重试成功覆盖。

常见问题

该问题是否证明 curl 8.19.0 遇到所有认证代理都会崩溃？

不能。这只是一则特定 OpenWrt 软件包组合的开放报告，目前没有确认普遍根因。

独立 curl 请求成功是否能完全排除代理问题？

它只确认一个客户端路径能够使用网关。Git 的 libcurl 链接、选项与重试行为可能不同，因此该对照能缩小范围，却不能单独定案。

是否应全局强制 Basic 代理认证？

不应。只有在安全策略允许时，才把它作为经过严格范围测试的临时选项；限定目标、要求代理侧 TLS，并保留回滚方案。

合规说明

只测试自有或明确获准评估的代理账户、仓库和系统。保护凭据与崩溃资料，遵守供应商和目标端限制，不得为通过测试而关闭 TLS 校验。