JS访问localhost跨端口API报net::ERR_CONNECTION_REFUSED排查

这个现象的本质根本不是端口没开、也不是防火墙拦截，是大家很容易搞错的寻址逻辑错位：服务端语境下的localhost，和客户端浏览器语境下的localhost，根本不是指同一个东西。

• 你在服务器本机执行curl http://localhost:7070/latest能通，是因为这时候localhost的解析对象就是服务器本身，请求直接走到了本机7070端口的Node服务上，和你看到的7070端口开放的状态完全匹配。
• 但你在前端JS代码里写死http://localhost:7070/latest，当用户用浏览器打开你托管的Flask网页时，这个localhost的解析主体是用户自己正在用的设备，浏览器会优先找用户自己电脑/手机上运行在7070端口的服务——根本不会把请求发到你跑Node、Flask的那台服务器上，自然会抛出ERR_CONNECTION_REFUSED错误。
• 之前你把地址换成192.168.68.72能正常访问，是因为这个IP是固定指向你的服务器的，不管用户在哪打开浏览器，请求都会路由到对应的服务器机器，自然能找到7070端口的Node服务。

简单类比：你在自家书房的架子上放了一盒茶叶（服务器上的7070服务），你自己在书房喊一声“茶叶在吗”（服务器本地curl）肯定有回应。但你给来访的客人留了字条“去你家厨房的架子上拿茶叶”（代码里写localhost:7070），客人在自己家找当然找不到，直到你改成留具体的门牌号“XX路XX号书房架子拿”（写局域网IP），客人才能找对地方。

你之前用netstat -tnlp看到7070端口处于开放状态，这个验证是完全有效的，但它只能证明服务器侧的端口监听状态正常，和浏览器侧的请求能不能正确路由到这个端口没有直接关系——很多人会把端口监听状态当成浏览器连接成功的充要条件，这是这个问题里最容易踩的认知陷阱。

完全可以实现自托管场景下的灵活访问，不需要把IP写死在代码里，两种生产环境常用的实现方式可以直接用：

• 方案一：Flask侧反向代理转发（最优解）
  直接在Flask服务上配置路径转发规则，把前端发起的所有/api前缀的请求，直接代理到同服务器127.0.0.1:7070的Node接口上。
  这种模式下前端代码里的接口地址直接写相对路径/api/latest就行：因为网页和接口请求是同域的，浏览器发起请求时会自动拼接当前网页的访问域，不管用户是用localhost、局域网IP、公网IP还是域名打开你的Flask网页，都能自动匹配对应的转发规则，完全不需要修改硬编码地址。
  额外优势：Node服务不需要对外暴露端口，只需要监听本地回环地址127.0.0.1就行，能减少不必要的端口暴露风险。
• 方案二：动态拼接当前访问域（轻量解）
  如果不想配置反向代理逻辑，可以在前端JS里动态从window.location对象获取当前网页的访问协议、域名，自动拼接Node服务的地址。
  比如写接口地址时不要硬编码完整路径，改成动态拼接的格式：

  // 自动获取当前网页的协议和域名，拼接API端口
  const apiBaseUrl = `${window.location.protocol}//${window.location.hostname}:7070`;
  $.getJSON(`${apiBaseUrl}/latest`, res => {
    // 处理接口返回逻辑
  })
  

  这种方式不需要修改后端服务的配置，不管用户用什么地址打开网页，JS都会自动适应当前的访问域，不会出现地址不匹配的问题。

避坑提醒：不要尝试通过加CORS头的方式解决这个问题——CORS是解决跨域访问的权限校验问题，解决不了“浏览器把localhost解析到用户本地设备”的本质寻址错误，就算配了全量CORS规则，照样会报连接拒绝。

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