如何解决前端Axios请求报Net::ERR_CONNECTION_REFUSED连接拒绝问题

优质文章学习记录

— 23 min read
如何解决前端Axios请求报Net::ERR_CONNECTION_REFUSED连接拒绝问题

Net::ERR_CONNECTION_REFUSED是前端使用Axios发起HTTP请求时，最常见的网络层错误之一，该错误的出现与Axios语法、接口请求参数无关，也并非前端代码逻辑问题，核心是前端客户端无法与目标服务端建立基础的TCP连接，服务端对客户端发起的连接请求做出了拒绝响应。这类问题的排查需跳出前端代码本身，从「服务端运行状态」「前端请求配置」「网络链路通畅性」「端口/防火墙限制」四个核心维度逐步验证，本地开发环境还需额外检查代理转发配置，以下是从易到难的完整排查流程和针对性解决方案，覆盖本地、局域网、线上生产所有开发场景。


文章目录

一、核心认知：错误本质与核心诱因

在解决问题前，先明确该错误的底层逻辑，能避免盲目排查——该错误属于TCP/IP网络层异常，而非HTTP应用层异常，出现时客户端的请求甚至未能到达服务端的接口处理逻辑，仅在「建立TCP连接」阶段就被阻断。

1.1 错误的核心本质

TCP协议建立连接时需经过「三次握手」，Net::ERR_CONNECTION_REFUSED表示：前端客户端向服务端的指定IP+端口发送了TCP连接请求，但服务端未对该请求做出任何响应，直接拒绝了连接，导致三次握手无法完成，请求链路直接中断。

1.2 触发错误的四大核心诱因

所有场景下的连接拒绝，最终都能归为以下四类原因，按出现频率从高到低排序：

  1. 服务端未启动/启动失败：目标服务端的后端项目未运行，或启动时因代码错误、端口占用等原因崩溃，无进程监听指定端口；
  2. 前端请求配置错误：Axios的请求地址（URL）、端口号、协议（http/https）与服务端实际配置不匹配，请求了错误的目标地址；
  3. 网络链路不通：前端与服务端不在同一网络（如局域网开发时跨网段）、防火墙/安全软件拦截了连接请求、云服务器安全组未放行端口；
  4. 开发环境代理配置错误：Vue/React等项目通过devServer配置了接口代理，代理的目标地址（target）写错，导致请求被转发到无效地址，触发连接拒绝。

1.3 关键区分：避免与其他错误混淆

开发中易将该错误与跨域、接口404/500混淆，需通过错误提示精准区分，避免排查方向偏离：

  • Net::ERR_CONNECTION_REFUSED：TCP连接建立失败，请求未到服务端；
  • CORS跨域错误：TCP连接成功，请求已到服务端，仅HTTP层面因跨域策略被拦截；
  • 404 Not Found：TCP连接+HTTP请求均成功，服务端未找到对应接口；
  • 500 Internal Server Error：TCP连接+HTTP请求均成功，服务端处理接口时内部报错。

二、从易到难：分步排查与针对性解决方案

排查遵循**「先确认服务端→再检查前端本地配置→最后验证网络链路」**的原则，从最容易验证、出现频率最高的原因开始，逐步缩小排查范围，所有步骤均提供具体的验证方法和解决操作，新手也能直接跟进。

步骤1：验证目标服务端是否正常运行，有无进程监听指定端口

这是触发Net::ERR_CONNECTION_REFUSED最核心、最常见的原因，优先验证该点，能解决80%以上的问题。核心验证逻辑：确认服务端有进程正常监听Axios请求的「IP+端口」。

具体验证方法
  1. 检查服务端启动日志：打开后端项目的启动终端/日志文件，查看是否有「启动成功」「监听端口xxx」的提示，若有代码错误、端口占用等提示，说明服务端启动失败；
  2. 手动访问服务端地址：在浏览器地址栏直接输入服务端的基础地址（如http://localhost:3000、http://192.168.1.100:8080），若浏览器显示「无法访问此网站」且控制台报相同的连接拒绝错误，说明服务端未启动/无进程监听端口；
  3. 检查端口是否被占用/有无监听进程：通过命令行查看指定端口是否有进程在监听，不同系统命令不同：

Mac/Linux系统：打开终端，执行命令（替换为实际端口号）：

# 查看指定端口的监听进程lsof -i:8080 # 或简化版命令netstat -tulpn |grep8080

若执行后无输出，说明端口无进程监听。

Windows系统：打开CMD/PowerShell，执行命令（替换为实际端口号）：

# 查看指定端口的占用情况，找到PID（进程号）netstat -ano | findstr "8080"

若执行后无任何输出，说明该端口无进程监听；若有输出，可通过PID查看对应进程是否为目标后端服务。

针对性解决方案
  1. 重新启动后端服务：若服务端未启动，直接运行后端项目的启动命令（如Java的java -jar xxx.jar、Node.js的node app.js、SpringBoot的IDE启动）；
  2. 解决服务端启动失败问题：若启动日志有报错，按错误提示修复（如代码语法错误、依赖缺失）；若提示端口被占用，要么杀死占用端口的进程，要么修改后端服务的监听端口；
    • 杀死占用端口进程：Windows通过「任务管理器」根据PID结束进程，Mac/Linux执行kill -9 进程PID；
    • 修改后端端口：如SpringBoot修改application.yml的server.port，Node.js修改app.listen(新端口)；
  3. 确认服务端监听的是正确端口：确保后端服务监听的端口，与前端Axios请求的端口完全一致。

步骤2：检查前端Axios请求配置，确保地址/端口/协议完全正确

服务端启动正常后，若仍报连接拒绝，需检查前端请求配置——请求地址拼写错误、端口号写错、http/https混用是前端开发中高频的低级错误。

具体验证方法
  1. 查看Axios的实际请求地址：打开浏览器F12→Network面板，找到报红的请求，查看Request URL列，确认实际请求的地址是否为服务端的真实地址；
  2. 核对Axios的基础配置：检查项目中Axios的baseURL配置（全局配置）或单个请求的url（局部配置），重点核对3点：
    • 协议：服务端用http则前端不能写https（如服务端是http://localhost:3000，前端写https://localhost:3000会直接拒绝）；
    • 域名/IP：本地开发常用localhost/127.0.0.1，局域网开发需用服务端的本机IP（如192.168.1.105），不能用localhost；
    • 端口号：与服务端监听的端口完全一致，无多写/少写数字（如服务端3000，前端写3001）；
  3. 检查是否有硬编码的错误地址：部分开发会在单个请求中硬编码url，覆盖了全局baseURL，需排查是否有此类情况。
针对性解决方案
  1. http/https严格与服务端保持一致：若服务端未配置HTTPS证书，前端绝对不能用https协议发起请求，直接改为http。

单个请求仅写接口路径，不写完整地址：基于全局baseURL，单个请求只需写接口后缀，避免协议/端口错误：

// 正确：仅写接口路径，自动拼接baseURL service.get('/api/user/list')// 错误：硬编码完整地址，易出现拼写/端口错误// axios.get('http://localhost:3001/api/user/list')

统一Axios的全局baseURL配置：推荐在项目中全局配置Axios的baseURL，避免单个请求硬编码，减少错误率，示例：

// 正确配置Axios全局baseURL，根据环境区分import axios from'axios'const service = axios.create({// 本地开发：服务端本地地址// baseURL: 'http://localhost:3000',// 局域网开发：服务端本机IPbaseURL:'http://192.168.1.105:3000',timeout:5000})exportdefault service

步骤3：验证前端与服务端的网络链路是否通畅，无防火墙/安全软件拦截

服务端启动正常、前端配置正确后，仍报连接拒绝，需排查网络链路——前端和服务端不在同一网络、防火墙拦截连接是局域网/线上开发的常见原因。

具体验证场景与方法

按「本地开发→局域网开发→线上开发」分场景验证，核心逻辑：确保前端能通过网络访问到服务端的IP+端口。

  1. 本地开发场景（前端+服务端在同一台电脑）
    • 验证：用localhost/127.0.0.1访问服务端地址，若localhost能访问、127.0.0.1不能，大概率是本地hosts文件配置错误；
    • 额外检查：关闭本地的杀毒软件、防火墙（如Windows Defender、360安全卫士），部分安全软件会拦截本地端口的连接请求。
  2. 局域网开发场景（前端+服务端在不同电脑，同一局域网）
    • 验证1：前端电脑通过「ping 服务端IP」测试网络连通性，如ping 192.168.1.105，若出现「请求超时」，说明两台电脑不在同一网段/局域网不通；
    • 验证2：前端电脑在浏览器直接访问服务端的「IP+端口」，如http://192.168.1.105:3000，若报连接拒绝，说明服务端电脑的防火墙拦截了请求；
    • 关键注意：局域网开发时，前端Axios的baseURL必须写服务端的本机IP，不能写localhost（localhost仅指向当前电脑）。
  3. 线上生产场景（前端部署在服务器/CDN，服务端部署在云服务器）
    • 验证1：本地电脑通过浏览器访问线上服务端的「域名/公网IP+端口」，如https://api.xxx.com:8080，若报连接拒绝，说明云服务器的端口未开放；
    • 验证2：检查云服务器的安全组规则（阿里云/腾讯云/华为云均有），这是线上场景最容易忽略的点——云服务器的端口需在安全组中手动放行，否则即使服务端启动、服务器防火墙关闭，外部也无法访问；
    • 验证3：检查服务端服务器的系统防火墙（如Linux的iptables/firewalld，Windows的防火墙），确保放行目标端口。
针对性解决方案
  1. 本地开发：修复hosts文件（C:\Windows\System32\drivers\etc\hosts），确保127.0.0.1 localhost未被注释；临时关闭杀毒软件/防火墙，测试是否能连接。
  2. 局域网开发：
    • 将前端和服务端电脑连接到同一WiFi/交换机，确保在同一网段（IP前三位相同，如192.168.1.x）；
    • 关闭服务端电脑的系统防火墙：Windows在「设置→更新和安全→Windows安全→防火墙和网络保护」中关闭；Linux执行systemctl stop firewalld（临时关闭）；
  3. 线上生产场景：
    • 云服务器安全组放行端口：在云服务器控制台的「安全组」中，添加入站规则，放行服务端的监听端口（如8080、3000），允许所有IP访问（0.0.0.0/0）；
    • 服务器系统防火墙放行端口：Linux通过iptables/firewalld添加端口放行规则，Windows在防火墙高级设置中添加入站规则；
    • 确认服务端绑定的是公网IP：后端服务启动时，确保监听的是0.0.0.0（所有IP），而非127.0.0.1（仅本地访问），如Node.js的app.listen(3000, '0.0.0.0')。

步骤4：检查开发环境的代理配置，确保代理转发地址正确

Vue/React/Vite等前端项目，为了解决本地开发的跨域问题，会通过devServer.proxy（webpack）/server.proxy（Vite）配置接口代理——代理的target地址写错是开发中极易忽略的点，此时前端请求的是本地代理地址，代理服务器转发到错误的服务端地址，最终触发连接拒绝。

具体验证方法
  1. 确认项目是否配置了代理：查看项目配置文件（Vite为vite.config.js，Vue2为vue.config.js，React为src/setupProxy.js），是否有proxy相关配置；
  2. 检查代理的target地址：核心核对代理的target是否为服务端的真实地址（协议+IP+端口），是否存在端口、协议写错的情况；
  3. 验证代理是否生效：打开浏览器Network面板，查看Axios的请求地址是否为本地项目地址（如http://localhost:8080/api/user），而非服务端地址，若为本地地址，说明代理已生效，需重点检查target。
针对性解决方案

核心原则：代理的target必须是服务端的真实可访问地址，且配置后需重启前端项目（代理配置修改后不重启不生效），以下给出主流框架的代理正确配置示例。

示例1：Vue3/Vite项目（vite.config.js）
import{ defineConfig }from'vite'import vue from'@vitejs/plugin-vue'exportdefaultdefineConfig({plugins:[vue()],server:{port:8080,// 前端项目端口proxy:{// 匹配所有以/api开头的请求，转发到target'/api':{target:'http://192.168.1.105:3000',// 服务端真实地址（必须正确）changeOrigin:true,// 开启跨域代理（必配）rewrite:(path)=> path.replace(/^\/api/,'')// 可选：重写路径，根据服务端接口调整}}}})
示例2：Vue2/@vue/cli项目（vue.config.js）
module.exports ={devServer:{port:8080,proxy:{'/api':{target:'http://localhost:3000',// 服务端本地地址changeOrigin:true,pathRewrite:{'^/api':''}}}}}
示例3：React/create-react-app项目（src/setupProxy.js）

需先安装http-proxy-middleware：npm install http-proxy-middleware --save-dev

const{ createProxyMiddleware }=require('http-proxy-middleware') module.exports=function(app){ app.use('/api',createProxyMiddleware({target:'http://192.168.1.105:3000',changeOrigin:true,pathRewrite:{'^/api':''}}))}
关键代理配置注意点
  1. changeOrigin: true是必配项，开启后代理服务器会模拟服务端的域名，避免跨域；
  2. 代理配置修改后，必须重启前端项目，否则配置不生效；
  3. 前端Axios的baseURL需配置为前端项目的本地地址（如http://localhost:8080），才能触发代理转发。

步骤5：终极验证：通过curl/postman测试，排除前端项目环境问题

若以上步骤均验证无误，仍报连接拒绝，需排除前端项目本身的环境问题（如依赖冲突、配置污染），通过curl命令或Postman直接发起请求，测试服务端地址是否可访问。

具体验证方法
  1. Postman测试：打开Postman，输入服务端的接口地址，发起请求，若能正常响应，说明服务端和网络均无问题，问题出在前端项目。

curl命令测试：打开前端电脑的终端/CMD，执行curl命令（替换为服务端真实地址）：

# 测试GET请求curl http://192.168.1.105:3000/api/user/list # 测试POST请求curl -X POST -d "name=test" http://192.168.1.105:3000/api/user/add

若curl命令也报「Connection refused」，说明问题与前端项目无关，回到步骤3重新排查网络/防火墙；若curl命令能正常获取接口返回值，说明前端项目环境有问题。

针对性解决方案

若curl/Postman能正常访问，仅前端项目报连接拒绝，按以下步骤处理：

  1. 重启前端项目，清除项目缓存（如Vite的node_modules/.vite，webpack的node_modules/.cache）；
  2. 重新安装Axios依赖：npm uninstall axios && npm install axios，排除依赖损坏问题；
  3. 检查项目中是否有其他网络相关配置（如mock服务、请求拦截器），是否拦截/修改了Axios的请求地址；

简化请求代码，用原生fetch测试，排除Axios本身的问题：

// 用原生fetch测试，若能正常请求，说明Axios配置有问题fetch('http://192.168.1.105:3000/api/user/list').then(res=> res.json()).then(data=> console.log(data)).catch(err=> console.log(err))

三、不同开发场景的专属排查重点

不同的开发场景（本地/局域网/线上），触发连接拒绝的核心原因不同，针对性聚焦排查重点，能大幅提升排查效率，以下是各场景的核心排查点总结：

场景1：本地开发（前端+服务端在同一台电脑）

核心排查点：

  1. 服务端是否正常启动，有无进程监听指定端口；
  2. 前端Axios的地址是否为localhost/127.0.0.1，端口与服务端一致；
  3. 本地杀毒软件/防火墙是否拦截了端口连接；
  4. 代理配置的target是否为localhost/127.0.0.1+正确端口。

场景2：局域网开发（前端+服务端在不同电脑）

核心排查点：

  1. 前端和服务端是否连接到同一WiFi/交换机，是否在同一网段；
  2. 前端Axios/代理的地址是否为服务端的本机IP（不能用localhost）；
  3. 服务端电脑的系统防火墙是否关闭，是否放行目标端口；
  4. 服务端是否监听0.0.0.0（而非127.0.0.1），允许局域网访问。

场景3：线上生产场景（前端/服务端部署在服务器）

核心排查点：

  1. 云服务器的安全组规则是否放行服务端的监听端口（入站规则）；
  2. 服务器的系统防火墙（iptables/firewalld）是否放行目标端口；
  3. 服务端是否监听0.0.0.0，允许公网访问；
  4. 前端Axios的地址是否为服务端的公网IP/域名，协议（http/https）与服务端一致；
  5. 服务端部署后是否正常启动，有无进程监听指定端口（通过lsof -i:端口验证）。

四、高频避坑点：这些细节会导致排查反复

即使掌握了排查步骤，若忽略以下细节，仍会出现「排查后仍报错误」的情况，这些是开发中极易踩坑的点，需重点注意：

避坑1：代理配置修改后未重启前端项目

代理配置（vite.config.js/vue.config.js）属于项目启动时的静态配置，修改后若不重启前端项目，配置不会生效，前端仍会按旧的target地址转发请求，导致连接拒绝。
解决方案：修改代理配置后，必须执行npm run dev/serve重启项目。

避坑2：服务端绑定127.0.0.1，拒绝局域网/公网访问

后端服务启动时，若监听的是127.0.0.1，则仅允许服务端本机访问，局域网/公网的前端请求会被直接拒绝；正确的做法是监听0.0.0.0，允许所有IP访问。
示例：Node.js服务端正确监听配置

// 错误：仅本地访问，局域网/公网无法连接// app.listen(3000, '127.0.0.1', () => console.log('服务启动'))// 正确：允许所有IP访问，局域网/公网均可连接 app.listen(3000,'0.0.0.0',()=> console.log('服务启动'))

避坑3：线上云服务器只关闭系统防火墙，未配置安全组

云服务器（阿里云/腾讯云）有安全组和系统防火墙两层防护，即使关闭了系统防火墙，若安全组未放行端口，外部请求仍会被拒绝；安全组是云服务器的第一道防护，必须优先配置。
解决方案：在云服务器控制台，找到对应实例的安全组，添加入站规则，放行服务端端口，来源选择「0.0.0.0/0」（允许所有IP）。

避坑4：http和https混用，服务端无HTTPS证书仍用https请求

若服务端未配置SSL证书，未开启HTTPS服务，前端强行用https协议发起请求，会直接触发TCP连接拒绝；协议必须严格匹配，无证书则用http，有证书则用https。

避坑5：局域网开发时，前端Axios写localhost而非服务端IP

localhost和127.0.0.1均指向当前电脑，局域网开发时，前端电脑的localhost指向前端本身，而非服务端电脑，请求localhost会导致连接到前端电脑的无效端口，触发拒绝。
解决方案：局域网开发时，前端所有请求地址必须写服务端的本机IP（如192.168.1.105）。

五、总结：Net::ERR_CONNECTION_REFUSED通用排查流程

Axios请求报Net::ERR_CONNECTION_REFUSED的排查，核心是跳出前端代码，聚焦「TCP连接建立」的全链路，该错误与Axios、前端逻辑无关，只需按「从易到难、分场景聚焦」的原则逐步验证，以下是可直接套用的通用排查流程，覆盖所有场景：

通用排查步骤（按执行顺序）

  1. 验证服务端：检查服务端是否正常启动，有无进程监听目标端口，启动日志是否无报错；
  2. 验证前端配置：检查Axios的baseURL/请求url，确保协议、IP/域名、端口与服务端完全一致；
  3. 验证网络链路：本地/局域网/线上按对应场景，检查网络是否连通、防火墙/安全组是否放行端口；
  4. 验证代理配置：开发环境检查proxy的target地址是否正确，修改后是否重启前端项目；
  5. 终极验证：用curl/Postman测试服务端地址，排除前端项目环境问题；
  6. 细节检查：确认服务端监听0.0.0.0、无http/https混用、无端口占用。

核心解决思路（3句话概括）

  1. 先定服务端：服务端未启动/无端口监听是核心原因，优先验证并确保服务端正常运行；
  2. 再核配置：前端请求地址、代理target的协议/IP/端口，必须与服务端完全一致，无任何拼写错误；
  3. 最后查网络：网络链路的防火墙/安全组/网段问题，是本地外场景的主要诱因，需按场景针对性放行端口、确保网络连通。

遵循以上流程和解决方案，能快速定位并解决99%以上的Net::ERR_CONNECTION_REFUSED问题，同时养成「先验证服务端，再检查前端，最后排查网络」的排查思维，后续遇到同类网络连接问题，也能高效解决。

【专栏地址】
更多 Vue实战BUG调试、网络请求、Axios优化、前端工程化解决方案，欢迎订阅我的 ZEEKLOG 专栏：🔥全栈BUG解决方案

Read more

私人 AI 随身带！OpenClaw+cpolar 外网访问完整教程

私人 AI 随身带！OpenClaw+cpolar 外网访问完整教程

前言 在人人都用 AI 的时代，拥有一台完全私有、本地运行、数据不泄露的私人 AI，已经成为很多人的刚需。OpenClaw 就是这样一款宝藏工具，可绝大多数人都用错了方式 —— 只把它放在家里电脑上，出门就用不了。结果就是：部署时兴致勃勃，用几天后慢慢闲置，明明花了时间搭建，却没能发挥一半价值。我自己踩过这个坑，也试过各种办法突破局域网限制，要么配置复杂，要么不稳定，直到遇见 cpolar。它能轻松把本地服务映射到公网，安全加密、多平台兼容、新手友好。把 OpenClaw 和 cpolar 组合在一起，就等于把私人 AI 装进口袋，上班、出差、旅行，只要有网就能用。这篇文章不讲难懂原理，只给可直接复制的操作，带你从零完成外网访问，让私人 AI 真正随身带、随时用。 1 OpenClaw和cpolar是什么？

Trae IDE 安装与使用保姆级教程：字节跳动的 AI 编程神器

一、Trae 是什么？ Trae（发音 /treɪ/）是字节跳动推出的 AI 原生集成开发环境（AI IDE），于 2025 年 1 月正式发布。与传统的 IDE + AI 插件组合不同，Trae 从底层架构上就将 AI 能力深度集成，实现了真正意义上的"AI 主导开发"。 核心定位 Trae 以 “自主智能体（Agent）” 为核心定位，彻底重构了传统开发流程： * Chat 模式：智能代码补全、问答、解释和优化 * Builder 模式：自然语言一键生成完整项目框架 * SOLO 模式：AI 自主规划并执行开发任务 版本划分 版本定位核心特色适用人群Trae

保姆级教程：Windows本地部署Ollama+OpenClaw，打造你的AI赚钱系统（APP开发/量化/小说/剪辑）

摘要：想用AI搞钱但卡在技术门槛？本文手把手教你用一台Windows电脑，零成本本地部署Ollama大模型+OpenClaw智能中枢，赋予AI开发APP、量化分析、编写小说、剪辑辅助等“赚钱技能”。全程无需编程基础，跟着鼠标点、照着命令敲，即可拥有24小时待命的AI员工。 一、写在前面 很多朋友对AI变现跃跃欲试，却常被这些问题劝退： * 云端部署太贵，API调用怕浪费钱 * 技术文档看不懂，不知道从哪下手 * 数据隐私担忧，不敢把敏感资料上传 其实，你手头那台Windows电脑完全能胜任！本文将带你搭建一套完全本地化、免费、可扩展的AI生产力系统，让AI帮你写代码、分析表格、生成文案、处理视频，真正把AI变成你的“赚钱工具”。 系统架构： * 本地大脑：Ollama + DeepSeek模型，负责理解任务、生成内容 * 智能中枢：OpenClaw（原名OpenClaude），负责调用各类工具（Skill） * 赚钱技能：通过安装Skill包，让AI具备特定领域的实操能力 适用人群：

2026年3月13日AI热点：芯片大战、Agent爆发、安全争议

2026年3月13日AI热点：芯片大战、Agent爆发、安全争议 今日AI圈发生了什么？十大热点一文打尽 ChatGPT o3 pro | Claude 3.7 | Gemini 2.5 pro免费用 👉 AI工具集 今天的AI圈依然热闹非凡！从芯片巨头的大手笔投入，到Agent时代的全面爆发，再到AI安全争议愈演愈烈…让我带你一篇看完今日AI十大热点！ 🔥 十大AI新闻 1. Anthropic 起诉美国国防部 Anthropic就供应链风险认定起诉五角大楼，称这一认定可能让其损失数十亿美元。特朗普政府表示不排除对Anthropic采取进一步行动。 2. Nvidia 投资260亿美元开发开源模型 最新文件显示，Nvidia计划投入260亿美元构建开源权重AI模型，展现其对开源生态的承诺。 3. Meta 发布4款新AI芯片 Meta推出了MTIA 300芯片，用于训练Instagram和Facebook的排序推荐系统。MTIA 400/450/500将在2027年前支持生成式AI推理。 4. Google Gemini 登陆 Chrome