带有账密的 ISP 住宅代理，海外服务器请求正常， macOS 本地 curl 持续失败

大家好，最近在调优量化交易的网络架构时遇到了一个非常诡异的网络连通性问题，折腾了一圈没找到根本原因，特来向各位网络/DevOps 大佬求助。

📌 核心现象

我手里有一个带有账号密码认证的 HTTP 代理（类似住宅/节点代理池）。
运行同一条 curl 测试指令请求 google 的时间戳 API：

• 在海外 Linux 服务器上： 秒回，完全正常。


• 在本地 macOS 上： 无法连通（无论是否开启 Clash TUN 模式）。

测试指令如下：
curl -v -xhttp://[USERNAME]:[PASSWORD]@[PROXY_IP]:[PROXY_PORT]/" https://www.google.com

💻 运行环境比对

** [环境 A：本地（无法连通）] **

• OS: macOS (Apple Silicon / Intel)


• 网络环境: 国内直连 / 挂载了 Clash Verge (无论关闭代理、开启系统代理还是开启 TUN 模式，该指令均失败)


• Curl 版本: macOS 自带 (SecureTransport / LibreSSL)

** [环境 B：服务器（正常连通）] **

• OS: Ubuntu 22.04 / CentOS


• 网络环境: 海外机器


• Curl 版本: Linux 自带 (OpenSSL)

🤔 我的猜测与疑问

结合以上现象，我目前有几个猜测，希望大佬们帮忙看看哪个最有可能，或者指导一下下一步的抓包排查方向：

1. GFW 阻断？ 本地发往海外 [PROXY_IP] 的代理请求是明文 HTTP 握手，是不是直接被运营商或 GFW 识别并重置（ RST ）了？


2. 代理服务商白名单限制？ 这种带账密的代理，服务商后台是否通常会绑定请求端的公网 IP ？因为服务器 IP 可能在白名单内，而我本地宽带 IP 每天都在变。


3. 底层 SSL 库差异？ macOS 自带的 curl 库与目标代理服务器之间，在建立 CONNECT 隧道时的 SSL 握手失败了？

如果有大佬遇到过类似“本地挂代理调不通，服务器畅通”的坑，或者知道怎么用 tcpdump 精准抓这个过程的包，恳请指点迷津！感激不尽。