git 2.29+ 默认禁用不安全的 http:// 协议，报“transport http not allowed”需将 remote url 改为 https:// 或 git@；若仍失败，检查是否因缺失 libcurl、代理干扰或服务端重定向至 http 导致。
git remote URL 用了 http:// 却报 “transport http not allowed”
Git 默认从 2.29 版本起禁用不安全的 http:// 协议（非加密），直接拒绝解析这类 URL。这不是配置错误，而是安全策略升级后的硬性拦截。
- 运行
git --version确认是否 ≥ 2.29；旧版本不会报这个错，但存在凭证泄露风险 - 检查远程地址：
git remote get-url origin，如果输出是http://github.com/xxx/yyy.git，这就是根源 - 别试图用
git config --global http.sslVerify false绕过——它只影响 HTTPS 的证书校验，对http://协议本身无效 - 正确做法是立刻切换为
https://或git@协议：git remote set-url origin https://github.com/username/repo.git
为什么 git clone https://... 有时也报 “transport http not allowed”
表面是 HTTPS，实际可能是 Git 尝试降级到 HTTP（比如重定向响应头含 Location: http://...），或环境变量强制禁用了所有基于 HTTP 的 transport。
- 检查是否有残留的协议限制：运行
env | grep -i protocol，重点看GIT_PROTOCOL_FROM_USER是否被设为0；如果是，执行unset GIT_PROTOCOL_FROM_USER - 确认远程服务端没返回异常重定向：用
curl -I https://github.com/username/repo.git看响应头是否含Location: http:// - 某些企业 Git 服务器配置了错误的 Web 重定向规则，导致客户端收到 HTTP 跳转，触发 Git 的协议拦截
- 临时验证是否是服务端问题：换一个已知正常的仓库（如
https://github.com/git/git.git）测试能否 clone
编译安装 Git 后仍报此错，大概率是依赖缺失
手动编译的 Git 如果没链接 libcurl，就会丢失对 https:// 的支持，进而 fallback 到尝试 http:// 并被拦截。
- 检查是否启用了 curl 支持：
git --build-options | grep curl，输出应含libcurl=1 - 若为
0，说明编译时未找到libcurl-devel（CentOS/RHEL）或libcurl4-openssl-dev（Ubuntu/Debian） - 重新安装依赖后，必须清理并重编译：
make clean && make configure && ./configure --with-curl && make && sudo make install - macOS 用户用 Homebrew 安装时，确保
curl是系统原生版本而非自制版冲突：brew unlink curl && brew install git
代理配置干扰 transport 协议选择
设置了 http.proxy 但代理本身不支持 HTTPS CONNECT 隧道，Git 会悄悄放弃 HTTPS 并尝试走明文 HTTP，从而触发拦截。
- 临时关闭代理验证：
git config --global --unset http.proxy和git config --global --unset https.proxy - 若必须走代理，请确认代理支持 HTTPS 隧道（即能处理
CONNECT github.com:443请求） - 某些老旧 HTTP 代理仅支持 GET/POST，遇到 Git 的
smart HTTP协议（需 PROPFIND、MKCOL 等）会静默失败，最终 fallback 到被禁用的 plain HTTP - 绕过代理只针对 GitHub：
git config --global http.https://github.com.sslVerify true+git config --global http.https://github.com.proxy ""
