关键在于区分请求是否抵达目标服务器及TLS握手在哪一环中断：代理（如Zscaler）解密HTTPS并替换证书，破坏信任链，导致fetch验证失败；正确方案是将代理根CA导入系统信任库或通过NODE_EXTRA_CA_CERTS/https.Agent显式加载，而非禁用校验。
识别代理环境对 fetch 证书校验的干扰，关键在于区分「请求是否真正抵达目标服务器」以及「TLS 握手阶段在哪一环中断」。代理（尤其是 SSL/TLS 检查型代理如 Zscaler、Palo Alto WSA、Blue Coat）会主动解密 HTTPS 流量，用自己的证书替换原始服务端证书——这直接破坏了标准证书信任链，导致 node-fetch 或浏览器 Fetch API 在证书验证阶段失败。
典型干扰现象与定位方法
以下表现高度提示代理正在干预 TLS 层：
- TLS 握手超时或失败：curl -v https://api.example.com 显示 * TLS handshake timed out 或 * SSL certificate problem: unable to get local issuer certificate
- 证书颁发者异常：用 openssl s_client -connect api.example.com:443 -servername api.example.com | openssl x509 -noout -issuer 返回 CN=Zscaler Intermediate Root CA 或类似企业私有 CA 名称，而非 Let’s Encrypt / DigiCert 等公信 CA
- SNI 字段丢失：Wireshark 抓包发现 ClientHello 中无 Server Name Indication 扩展（SNI 为空），常见于老旧透明代理配置
- 仅特定网络复现：在公司内网/教育网/ZPA 接入环境下报错，切换手机热点后立即正常
- Node.js 进程报错明确指向证书：如 UNABLE_TO_VERIFY_LEAF_SIGNATURE、SELF_SIGNED_CERT_IN_CHAIN，且发生在 fetch 调用初期（response 未生成）
生产环境安全解决方案
禁用证书校验（rejectUnauthorized: false）绝不可用于生产。正确做法是让运行时信任代理注入的根证书：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 将代理根 CA 导入系统信任库：Windows 用户需双击 .crt 文件 → “安装证书” → 存储位置选“受信任的根证书颁发机构”；macOS 用户用钥匙串访问 → “系统”钥匙串 → 拖入并设为“始终信任”
-
为 Node.js 显式指定额外 CA 证书路径：设置环境变量
NODE_EXTRA_CA_CERTS=/path/to/zscaler-root.crt，确保所有 node-fetch、axios、https.Agent 等调用均加载该证书 -
在代码中精准注入可信 CA（适用于容器或多环境部署）：
const fs = require('fs'); const https = require('https'); const fetch = require('node-fetch'); <p>const ca = fs.readFileSync('/app/certs/zscaler-root.pem'); const agent = new https.Agent({ ca });</p><p>fetch('<a href="https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca">https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca</a>', { agent }) .then(r => r.json()) .catch(e => console.error('Fetch failed:', e.message)); -
前端场景下避免代理干扰：若使用 Vite/Webpack Dev Server 代理（如
/api→ 后端），确保 fetch 请求走相对路径（fetch('/api/users')），由开发服务器服务端转发——此时 TLS 校验发生在开发服务器与后端之间，前端完全不参与证书验证
调试与验证要点
完成配置后，必须验证是否真正生效：
- 在 Node.js 中执行
console.log(require('tls').rootCertificates.length)，数值应明显大于默认值（通常增加 1+ 条） - 运行
node -e "require('https').get('https://api.example.com', r => console.log(r.statusCode))"，确认返回 200 而非证书错误 - 检查 Network 面板中 fetch 请求的 Security 标签页，确认“Connection”显示为 Secure，且证书路径包含你导入的代理根 CA
- 若仍失败，启用 Node.js TLS 调试：
NODE_OPTIONS='--trace-warnings' NODE_TLS_REJECT_UNAUTHORIZED=0 node your-app.js（仅临时诊断，勿留生产）
代理对证书校验的干扰本质是中间人行为，解决思路不是绕过安全机制，而是把代理的合法身份纳入信任体系。只要根证书可信、路径配置准确、运行时加载到位，fetch 就能像直连公网服务一样完成安全通信。
