Go模块拉取卡在SSH步骤本质是Git协议层连接阻塞或认证失败，不受GOPROXY控制，需检查DNS、密钥、GOPRIVATE/GONOPROXY/GONOSUMDB三者同步配置。
Go 模块依赖拉取卡在 SSH 相关步骤（比如 git@github.com、git@gitlab.internal），本质不是代理没配好，而是 Git 协议层的连接被阻塞或认证失败——Go 会默默调用系统 git 命令走 SSH，而这个过程不受 GOPROXY 控制，也不响应 Ctrl+C，超时动辄几十秒。
go mod download 卡在 git clone ssh://… 或 git -c core.autocrlf=false clone
这是最典型的 SSH 超时现象。执行 go mod download -v 后最后一行停在类似：
git -c core.autocrlf=false clone --mirror --filter=blob:none ssh://git@gitlab.example.com/my/lib /path/to/cache
说明 Go 已放弃走 HTTP 代理，转而调用本地 git 执行 SSH 克隆，但 SSH 连接未建立成功。
- 先确认是否真走 SSH：检查
go.mod中模块路径是不是以git@开头（如git@github.com:user/repo）；HTTP 路径（如https://github.com/user/repo）不会触发此问题 - 手动复现：复制上面那行
git clone …命令，在终端里单独运行，看是卡在Connecting to gitlab.example.com…还是报Permission denied (publickey) - SSH 配置优先级高于环境变量：Go 完全依赖系统
git和ssh行为，GOPROXY对它无效
SSH 连接慢或超时的三类根因与对应动作
不是所有“SSH 超时”都该改 Git 配置，得先区分是网络、密钥还是 DNS 层的问题。
立即学习“go语言免费学习笔记（深入）”；
-
DNS 解析慢：SSH 默认用系统 resolver，若内网 DNS 不稳定，
ssh gitlab.example.com可能卡 15–30 秒。临时验证：time ssh -o ConnectTimeout=5 -o BatchMode=yes gitlab.example.com exit；若耗时远超 5 秒，加Host gitlab.example.com\n AddressFamily inet到~/.ssh/config强制 IPv4 -
SSH 密钥未加载或权限错误：运行
ssh-add -l看密钥是否已载入；私钥文件权限必须是600（chmod 600 ~/.ssh/id_rsa），否则 OpenSSH 直接拒绝使用 -
跳过密码提示强制失败：Go 调用
git时加了-c core.askpass=，导致交互式密码输入被禁用。如果没配密钥，就会卡住不动——这不是超时，是永久挂起。必须配密钥，不能依赖密码登录
私有模块走 SSH 时 GOPRIVATE 和 GONOPROXY 必须同时设
只设 GOPRIVATE 不够，GONOPROXY 和 GONOSUMDB 必须同步配置，否则 Go 仍会尝试把 SSH 模块 URL 提交给代理校验，返回 404 后再 fallback 到 Git，白白多一次失败请求。
- 正确设置（以
gitlab.example.com为例）：go env -w GOPRIVATE="gitlab.example.com"go env -w GONOPROXY="gitlab.example.com"go env -w GONOSUMDB="gitlab.example.com" - 三个值必须完全一致，少一个都会导致行为异常；逗号分隔多个域名，不支持通配符（
*.example.com无效） - 设完后运行
go env GOPRIVATE GONOPROXY GONOSUMDB逐个确认，别只信文档说“设了就行”
调试 SSH 模块拉取失败的最小闭环流程
别一上来就改全局环境变量，先用最小范围验证问题在哪一层。
- 进项目目录，删掉
go.sum和vendor/（如有），避免缓存干扰 - 临时关闭代理：
GOPROXY=direct go mod download -v—— 如果立刻失败且报错含Permission denied (publickey)，就是密钥问题；如果仍卡住，就是 SSH 层网络或 DNS 问题 - 抓包定位（Mac/Linux）：
ssh -vvv gitlab.example.com看输出停在哪一步（debug1: Connecting to gitlab.example.com [10.1.2.3] port 22？还是卡在debug1: kex_input_ext_info: server-sig-algs=？） - 终极验证：用
git clone手动克隆同一仓库到空目录，成功了，Go 就没理由失败——失败一定是 Go 的上下文（如工作目录、环境变量、go.mod 写法）和你手动操作不一致
SSH 模块拉取失败，90% 的时间花在等待上，而不是报错上。关键不是“怎么让它快”，而是“怎么让它立刻失败并给出明确原因”。一旦你能让 git clone 在 3 秒内返回 Permission denied 或 Connection refused，Go 的问题就解了一半。
