开发环境代理不生效的根源是请求未经过dev server：需确认Network中请求是否发往localhost（走代理）而非直连后端，检查路径匹配、target可达性及代理日志提示。

开发环境代理配置不生效，是前端跨域报错的常见“假象”——实际请求根本没走本地 dev server 的代理，而是直连了后端地址，自然触发浏览器跨域限制。关键要确认请求是否真的被代理、代理规则是否匹配、目标服务是否可达。

检查请求是否真正经过 webpack/vite 代理

打开浏览器开发者工具的 Network 面板，发起一个本该被代理的请求（如 /api/users），观察：

• 请求的 Protocol 是 http 还是 https？如果是 http://localhost:8080/api/users，说明它发给了本地 dev server；如果显示的是后端真实地址（如 http://192.168.1.100:3000/api/users），说明压根没走代理，可能是路径写错了或代理未启用
• 查看响应头中是否有 X-Powered-By: Express 或其他后端标识 —— 若有，大概率已成功代理；若返回 ERR_CONNECTION_REFUSED 或空响应，说明代理转发失败，不是跨域问题，而是代理链路不通

核对代理配置的路径匹配逻辑

webpack-dev-server 和 vite 的代理都基于 path pattern 匹配，且默认区分前导斜杠和大小写，常见陷阱：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• vite.config.ts 中写 "/api": { target: "http://localhost:3000" }，只能匹配以 /api 开头的请求，但 fetch("api/users")（无前导 /）不会命中 —— 必须写成 fetch("/api/users")
• webpack 的 devServer.proxy 若用对象写法，pathRewrite 默认不自动去除前缀；需手动加 rewrite: (path) => path.replace(/^\/api/, '') 或改用函数式配置
• vite 中开启 changeOrigin: true 并不能解决路径不匹配，只影响 Host 头；匹配失败时它根本不会转发

验证代理目标服务是否可访问且路径正确

代理只是“转发”，不解决后端本身的问题：

立即学习“Java免费学习笔记（深入）”；

• 在终端执行 curl -v http://localhost:3000/api/users（替换为你 proxy.target 的地址），确认后端服务正在运行、接口存在、没有 404 或认证拦截
• 注意：代理不会自动携带 cookie 或 authorization header，若后端需要鉴权，需在代理配置中显式设置 secure: false（target 是 https 时）、changeOrigin: true，并确保前端请求带 credentials：fetch("/api/users", { credentials: "include" })
• vite 中若 target 是 https:// 地址，需加 secure: false 才允许代理到非安全源（仅限开发环境）

快速定位：用最简配置排除干扰

临时删掉所有复杂代理规则，只留一条最基础的测试项：

• vite 示例：

  proxy: {
    "/test-api": {
      target: "http://httpbin.org",
      changeOrigin: true,
      rewrite: (path) => path.replace(/^\/test-api/, "")
    }
  }

  然后访问 http://localhost:5173/test-api/get，看能否拿到 httpbin 响应 —— 成功说明代理机制正常，问题出在原配置；失败则检查 node 版本、防火墙或公司代理软件拦截
• 同时打开 dev server 启动日志（vite 默认会打印 proxy info），确认控制台出现类似 [vite] Proxying to http://localhost:3000 的提示，没有则配置未加载