跨域调用远程REST API遇TypeError: Network request failed问题求助

这种情况我之前也碰到过好几次，太让人头疼了——明明curl能通，本地环境也没问题，就是浏览器里死活发不出请求，连tcpdump都抓不到包，说明请求根本没从浏览器层面发出去。结合你描述的现象，我梳理几个最可能的排查方向，你可以挨个试：

1. 先检查混合内容拦截（最常见的隐形坑） #

现代浏览器默认会阻止从HTTPS页面发起HTTP请求的混合内容，这种情况下浏览器会直接拦截请求，连网络请求都不会发起，刚好符合你说的「tcpdump无数据、Network面板无记录」的现象。

• 确认你的前端页面是HTTPS还是HTTP，远程API的协议是啥？如果页面是HTTPS，API是HTTP，那十有八九是这个问题。
• 解决办法：要么把API改成HTTPS，要么在浏览器临时关闭混合内容拦截（仅用于测试），或者在开发环境下把前端页面改成HTTP。

2. 浏览器扩展/隐私设置拦截 #

很多隐私类、广告拦截类的扩展会悄悄拦截跨域请求，尤其是针对IP地址的API。

• 试试用浏览器无痕模式（自动禁用所有扩展）发起请求，如果能正常发送，那就是某个扩展在搞鬼，挨个排查你的扩展就行。
• 检查浏览器的隐私设置：比如是否开启了「增强型跟踪保护」「阻止第三方Cookie」，这些设置有时候会影响跨域请求的触发。

3. 前端代码的隐性错误 #

虽然本地环境正常，但替换远程IP后可能引入了代码层面的问题，导致请求根本没被执行：

• 打开浏览器的Console面板，仔细看有没有除了TypeError: Network request failed之外的其他错误（比如变量未定义、URL拼接错误），有时候前面的报错会中断请求代码的执行。
• 把请求的URL打印到控制台，确认是正确的远程IP，没有拼写错误、多余的斜杠或者端口问题。

4. CORS预请求或响应头问题 #

虽然你用curl没问题，但浏览器的CORS机制比curl严格：

• 如果你的GET请求不是「简单请求」（比如带了自定义请求头、Content-Type不是text/plain/multipart/form-data/application/x-www-form-urlencoded），浏览器会先发OPTIONS预请求。如果服务器没配置OPTIONS请求的响应头，浏览器会直接拦截后续的GET请求。
• 你可以在本地用curl模拟OPTIONS请求试试：

  curl -X OPTIONS http://远程IP/API路径 -H "Origin: 你的前端页面域名"
  

  看看服务器返回的响应头里有没有Access-Control-Allow-Origin、Access-Control-Allow-Methods这些字段。

5. 服务器端的User-Agent拦截（可能性较低） #

有些服务器会针对请求的User-Agent做限制，只允许curl等工具的请求，拒绝浏览器的：

• 用curl模拟浏览器的User-Agent试试：

  curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36" http://远程IP/API路径
  

  如果这个请求失败，说明服务器可能拦截了浏览器的User-Agent，需要调整服务器配置。

按照上面的顺序排查，大概率能找到问题——我之前碰到过两次都是混合内容拦截的问题，一开始完全没想到，因为curl能通就以为网络没问题，结果是浏览器偷偷把请求拦了。

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