GOPROXY设置后仍超时，主因是GOPRIVATE或GONOPROXY优先级更高而拦截请求；需按匹配顺序排查，确认direct回退、HTTPS可达性、GONOPROXY前缀匹配规则及CI/CD环境变量继承。
GOPROXY 不是“开了就能用”，设错、漏配、被覆盖，都会导致 go get 卡住或报错 module not found。国内开发必须配，但配得不对比不配还麻烦。
为什么 GOPROXY 设置了还是超时？
最常见原因是代理地址不可达，或被 GOPRIVATE/GONOPROXY 拦截——Go 的代理决策有明确优先级，不是只看 GOPROXY：
-
GOPRIVATE匹配优先级最高：只要包路径以其中任一前缀开头（如git.internal.company.com），直接跳过代理，走git clone或 HTTPS 直连 -
GONOPROXY次之：也是前缀匹配，不支持*通配符（*.company.com无效，必须写全git.internal.company.com） - 都不匹配，才轮到
GOPROXY列表，从左到右依次尝试
所以如果你设了 GOPROXY=https://goproxy.cn,direct，但同时又写了 GOPRIVATE=github.com/myorg，而你要拉的模块是 github.com/myorg/lib，那它根本不会进代理，而是直连 GitHub —— 此时超时就是 GitHub 访问问题，不是代理没生效。
GOPROXY 值末尾的 direct 不能省
direct 不是可选项，是 fallback 机制的关键。漏掉它，私有模块或未命中代理缓存的模块会直接失败：
- 正确：
GOPROXY=https://goproxy.cn,direct→ 代理查不到就直连 - 错误：
GOPROXY=https://goproxy.cn→ 代理返回 404 或超时，go不会自动回退，直接报错 - 更错：
GOPROXY=https://goproxy.cn, direct→ 中间多一个空格，Go 会把第二项解析为空字符串，启动时就报invalid GOPROXY value
验证方式不是 echo $GOPROXY，而是运行 go env GOPROXY，看输出是否完全一致（包括逗号、无空格、末尾 direct）。
立即学习“go语言免费学习笔记（深入）”；
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
CI/CD 和 Docker 里 GOPROXY 容易失效
本地终端里配好了，不等于构建环境也生效。CI/CD 流水线和 Docker 构建都是干净容器，go env -w 的配置不会继承：
- GitHub Actions：必须在
steps里显式执行go env -w GOPROXY=https://goproxy.cn,direct - GitLab CI：在
before_script加同样命令，或用export GOPROXY=...临时覆盖 - Dockerfile：在
RUN步骤开头加go env -w GOPROXY=https://goproxy.cn,direct，别只靠ENV GOPROXY=...—— 后者不触发 Go 内部配置加载逻辑
一个典型现象：本地 go mod tidy 秒完成，CI 却卡在 downloading github.com/xxx。这不是网络问题，是代理根本没设上。
代理能用，但 go.sum 校验失败？别乱关 GOSUMDB
代理只是加速下载，模块完整性校验由 GOSUMDB 控制。国内访问 sum.golang.org 可能失败，但直接设 GOSUMDB=off 是危险操作：
-
GOSUMDB=off→ 完全跳过校验，恶意篡改的依赖也能通过 - 更稳妥做法：保留校验，换可用的 sumdb 镜像，例如
GOSUMDB=sum.golang.org+https://goproxy.cn/sumdb（部分镜像支持） - 若内网完全离线，再考虑
GOSUMDB=off，但必须配合私有模块仓库 + 审计流程，不能当成默认方案
真正容易被忽略的是：代理和校验是两套独立系统。你调通了 GOPROXY，不代表 GOSUMDB 就自动适配；两者都得单独验证。
