M1 Mac Monterey下TypeScript调用API遇Cloudflare JA3哈希拦截求助

可能原因 #

• Node.js架构与TLS实现差异：M1 Mac的Node.js为ARM64架构，默认可能使用系统自带的Secure Transport库，而非Windows x86 Node.js常用的OpenSSL。两者在TLS握手时的加密套件优先级、扩展字段支持上存在差异，导致生成的JA3哈希被Cloudflare的规则判定为异常流量。
• 系统级TLS配置干扰：Monterey系统的全局TLS配置（如Keychain中的自定义证书、系统网络扩展工具）可能修改了Node.js的TLS握手流程，改变了JA3指纹特征。
• axios默认行为的环境差异：虽然表面提示“启用Cookie”，但核心是JA3哈希问题——axios在ARM Node.js环境下的默认HTTPS代理设置、握手参数可能和Windows环境或浏览器/Postman不一致，触发Cloudflare的拦截规则。

排查方向 #

1. 验证Node.js环境差异 #

• 运行node -p process.arch确认当前Node.js为arm64，再通过Rosetta 2安装x86版本的Node.js（比如用nvm: arch -x86_64 zsh后安装nvm和对应Node.js版本），重新运行代码看是否仍触发拦截。
• 执行node -p process.config查看Node.js的TLS相关配置，对比Windows同事的输出，确认是否使用了不同的TLS库（Secure Transport vs OpenSSL）。

2. 强制统一TLS握手参数 #

• 手动指定axios的HTTPS代理加密套件，匹配浏览器/Postman的JA3哈希对应的套件组合，示例代码：

  const axios = require('axios');
  const https = require('https');
  
  // 复制浏览器的加密套件顺序
  const tlsAgent = new https.Agent({
    ciphers: 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305',
    secureProtocol: 'TLSv1_2_method',
    ALPNProtocols: ['http/1.1']
  });
  
  axios.get('YOUR_API_URL', { httpsAgent: tlsAgent });
  

• 使用ja3包生成当前请求的JA3哈希（npm install ja3后在代码中引入），和浏览器的JA3哈希（可通过在线工具或浏览器插件获取）对比，定位差异点。

3. 排查系统网络与TLS配置 #

• 关闭全局代理、VPN，禁用系统防火墙或网络监控工具（如Little Snitch），重新测试请求，排除第三方工具对TLS握手的干扰。
• 打开Keychain Access，检查是否存在未信任的自定义TLS证书或配置，尝试移除或重置相关条目后再测试。

4. 抓包对比握手细节 #

• 使用Wireshark抓取M1 Mac上axios请求的TLS握手包，对比浏览器/Windows同事的请求包，重点查看加密套件列表、ALPN扩展、SNI字段的差异，定位导致JA3哈希不同的具体因素。

5. 替换HTTP客户端验证 #

• 改用node-fetch或got等其他HTTP客户端执行相同请求，若问题消失，说明是axios在ARM Node.js环境下的特定实现导致；若问题依旧，则问题根源在Node.js或系统TLS配置。

内容的提问来源于stack exchange，提问作者Chris Stephens