基于Arch的Antergos系统curl代理SSL版本错误及Git/HTTPS请求失败解决方案

遇到这种代理环境下curl和Git的HTTPS报错，我在Arch系系统上也碰到过类似情况，结合你描述的「关代理就正常、换代理仍报错」的现象，大概率是curl的代理配置、SSL证书链或者依赖问题，给你一步步排查解决的方案：

1. 先确认curl的代理配置是否正确 #

首先得确保curl能正确识别代理设置，可能是环境变量没生效或者配置文件出错了：

• 先检查当前终端的代理环境变量：

  echo $http_proxy $https_proxy $ALL_PROXY
  

  要注意：HTTPS代理的地址通常也是http://开头（除非是socks代理），比如http://123.123.123.123:8080。如果变量为空，先手动临时设置试试：

  export http_proxy=http://你的代理IP:端口
  export https_proxy=http://你的代理IP:端口
  

  设置完后用curl -v https://example.com测试，看是否能正常连接。

• 检查curl的全局或用户配置文件：
  看看/etc/curlrc（全局）或者~/.curlrc（用户）里有没有错误的配置，比如强制了旧版TLS、错误的代理地址，或者禁用了证书验证的奇怪设置。如果有，先备份文件再删除，然后重新测试。

2. 修复SSL证书链（Arch系常见问题） #

Arch系的SSL证书由ca-certificates包管理，新系统或更新后可能出现证书未正确生成的情况，这会导致代理环境下SSL验证失败：

• 更新证书包并重新生成证书存储：

  sudo pacman -Syu ca-certificates
  sudo update-ca-trust
  

  这一步是很多时候解决此类问题的关键，执行完后再测试curl的HTTPS请求。

3. 测试curl的SSL/TLS版本兼容性 #

有些代理服务器只支持特定版本的TLS，curl默认的TLS范围可能不兼容：

• 尝试指定TLS 1.2或TLS 1.3测试：

  curl -v --tlsv1.2 https://example.com
  # 或者试试TLS1.3
  curl -v --tlsv1.3 https://example.com
  

  如果某个版本能成功，你可以在~/.curlrc里添加一行tlsv1.2（或者对应版本），让curl默认使用这个版本。

• 临时禁用证书验证（仅用于测试，不要长期用，不安全）：

  curl -v -k https://example.com
  

  如果这样能成功，说明还是证书验证的问题，回到步骤2重新处理证书即可。

4. 同步Git的代理配置 #

Git可能不继承系统的代理环境变量，需要单独配置：

• 先查看当前Git的代理设置：

  git config --global --get http.proxy
  git config --global --get https.proxy
  

  如果配置的代理不对，或者为空，手动设置：

  git config --global http.proxy http://你的代理IP:端口
  git config --global https.proxy http://你的代理IP:端口
  

  要是想让Git直接用系统的环境变量，就清空Git的代理配置：

  git config --global --unset http.proxy
  git config --global --unset https.proxy
  

5. 排查pacman安装的软件是否影响curl #

你提到用pacman装了若干软件，可能某个软件修改了curl的依赖或配置：

• 查看最近安装的软件包：

  pacman -Q --sort m | tail -20
  

  重点看和网络、SSL、curl相关的包（比如libcurl、代理工具等），如果有可疑的包，可以尝试重新安装curl和它的依赖：

  sudo pacman -S --reinstall curl libcurl
  

按照这个顺序排查，应该能解决你的问题。

内容的提问来源于stack exchange，提问作者Neel Basu