如何解决前端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

深度解析 GitHub Copilot Agent Skills：如何打造可跨项目的 AI 专属“工具箱”

前言 随着 GitHub Copilot 从单纯的“代码补全”工具向 Copilot Agent（AI 代理） 进化，开发者们迎来了更高的定制化需求。我们不仅希望 AI 能写代码，更希望它能理解团队的特殊规范、掌握内部工具的使用方法，甚至在不同的项目中复用这些经验。 Agent Skills（代理技能） 正是解决这一痛点的核心机制。本文将深入解析 Copilot Skills 的工作原理，并分享如何通过软链接（Symbolic Link）与自动化工作流，构建一套高效的个人及团队知识库。 一、 什么是 Agent Skills？ 如果说 Copilot 是一个通用的“AI 程序员”，那么 Skill（技能） 就是你为它配备的专用工具箱。 它不仅仅是一段简单的提示词（Prompt），而是一个包含元数据、指令和执行资源的标准文件夹结构。当
OpenClaw配置 GLM-4.7 Flash+DuckDuckGo 实现飞书机器人联网问答

OpenClaw配置 GLM-4.7 Flash+DuckDuckGo 实现飞书机器人联网问答

摘要 OpenClaw+GLM-4.7 Flash+DuckDuckGo：手把手教你搭建飞书群聊联网问答机器人。本文提供一套100% 免费的落地方案，详解 OpenClaw 安装、GLM-4.7 Flash 模型配置、DuckDuckGo 搜索插件启用、飞书应用创建与网关对接、群聊白名单配置等关键步骤，附完整命令与避坑指南，实现飞书内 @机器人即可获取实时联网信息，打造高效团队协作 AI 工具。 效果展示 准备工作 node.js安装 下载地址 https://nodejs.org/en/download 安装完成。 git 安装 下载地址 https://git-scm.com/install/windows 上图普通用户默认选择，我是程序员，因此选择第二项 接下来的步骤都是保持默认选择，点击Next，
国内如何升级GitHub Copilot到专业版

国内如何升级GitHub Copilot到专业版

国内外的AI编程工具我用过很多，用的时间比较长的是Cursor，后来Cursor在国内不能用了，就又回去试了一下GitHub Copilot，结果被惊艳到了，在VS Code里用起来很丝滑，体验很好，感觉VS Code团队在AI编程这块上真是下功夫了，现在其体验已经不输Cursor。 我一直是VS Code的粉丝，感觉还是原生的VS Code用起来最舒服，现在VS Code里的Copilot体验已经做的很好，就没有理由再用其他替代编辑器了。 VS Code里的Copilot每月有一定的免费额度，用完之后就需要开通专业版才能继续使用。我用完免费额度之后，已经被其良好的体验所打动，就想升级到专业版，但是如何付费成了问题。在网上搜了一下，说是国内的信用卡不能用，而之前好用的wildcard虚拟信用卡服务现在也停了，试了一下网友推荐的胡桃卡，试了好几次也没有支付成功，还被扣了很多手续费。 现在还有什么方式能支付升级到copilot专业版呢？ 后来发现GitHub Copilot升级页面上的支付方式那里也支持paypal，就在Payment method那里，credit card旁边有
文心一言开源版部署及多维度测评实例

文心一言开源版部署及多维度测评实例

文章目录 * 第一章 文心一言开源模型简介 * 第二章 模型性能深度实测 * 2.1 通用能力基准测试 * 2.1.1 文本生成质量 * 2.1.2 数学推理能力 * 2.2 极端场景压力测试 * 2.2.1 高并发性能 * 2.2.2 长上下文记忆 * 第三章 中文特色能力解析 * 3.1.2 文化特定理解 * 3.2 行业术语处理 * 3.2.1 法律文书解析 * 3.2.2 医疗报告生成 * 第四章 开源生态建设评估 * 4.1 模型可扩展性验证 * 4.