我写排查记录，不是因为报错本身有多稀奇，而是最后的原因经常不在第一条日志里。

这里目前留下了三类现场：pip 访问镜像站返回 403、应用安装时出现 Hash 不一致，以及 OrbStack 容器访问微服 WordPress 时的 IPv6 解析问题。它们分别落在出口网络、依赖包和地址解析上，表面看起来并没有多少共同点。

真正共用的是排查顺序：先保留原始错误，再确认运行环境和请求实际去了哪里，最后用一个更小的测试验证判断。能绕过去不等于找到了根因，日志里同时出现的报错也不一定都重要。

这些结论带着当时的版本和网络条件。遇到相似问题时，可以复用判断方法，不要只复制最后一条命令。