返回

解决 Express+Vue 在 Vercel/Railway 部署的 CORS 502 错误

vue.js

好的，这是你要的博客文章内容：

搞定 Express + Vue 跨域：解决 Vercel 与 Railway 部署中的 CORS Preflight 502 难题

你是不是也遇到了这样的情况：Vue.js 前端部署在 Vercel，Express.js 后端放在 Railway，满心欢喜想调个 API，结果浏览器控制台给你甩来一个关于 Preflight 请求的 CORS 错误，还伴随着一个让人头疼的 502 Bad Gateway？特别是看到这个：

{
    "status": "error",
    "code": 502,
    "message": "Application failed to respond",
    "request_id": "..." // 一串请求 ID
}

别急，这问题挺常见的，尤其是在前后端分离部署的场景下。咱们来捋一捋，看看怎么把它摆平。

问题来了：Vercel 上的 Vue 调用 Railway 上的 Express API 报 502

简单说，就是你的 Vercel 前端（比如 https://lunartechlab-zelino.vercel.app）想请求 Railway 后端（比如 https://lunarexpress.lunartechlab.com/api/send-mail）的数据。因为域名、协议或端口不同源，浏览器会先发送一个叫做“Preflight”（预检）的 OPTIONS 请求，问问服务器：“嘿，哥们儿，这个 Vercel 来的请求，带着 Content-Type 头，用 POST 方法，你允许不？”

理想情况下，服务器收到 OPTIONS 请求，检查一下 CORS 配置，觉得没问题，就回个 2xx 状态码，告诉浏览器：“妥了，你发吧！” 然后浏览器才会发送真正的 POST 请求。

但现在的情况是，这个 OPTIONS 预检请求直接就失败了，还拿到了一个 502 错误。502 Bad Gateway 通常意味着作为网关或代理的服务器（这里可能是 Railway 的负载均衡器或反向代理）从上游服务器（也就是你的 Express 应用）那里收到了无效响应，或者根本没收到响应。

刨根问底：为啥 Preflight 请求会收到 502？

明明后端单独测是好的，为啥一加上跨域预检就挂了呢？几种可能性最大：

  1. Railway 上的 Express 应用真挂了或没启动对： 502 最直接的原因就是 Railway 没法成功访问你的应用进程。可能是应用崩溃了、启动时端口绑定错了、健康检查失败导致容器被重启或标记为不健康。
  2. CORS 中间件配置有问题或顺序不对： 你的 CORS 配置可能没生效，或者没正确处理 OPTIONS 请求。app.options('*', cors(corsOptions)) 这种写法本身是为了响应 OPTIONS，但它的位置或者 corsOptions 的具体内容可能有讲究。
  3. OPTIONS 请求被其他中间件拦路或者搞崩了： 在 CORS 中间件处理 OPTIONS 请求 之前 或 之后，可能有其他全局中间件（比如日志、认证、解析请求体的 express.json() 等）没有正确处理 OPTIONS 请求（OPTIONS 请求通常没有 body），导致程序出错崩溃。
  4. 环境变量或端口没配对： Railway 这类 PaaS 平台通常通过环境变量（如 PORT）指定应用应该监听的端口。如果你的 Express 应用写死了监听端口（比如 app.listen(3000)），而不是用 process.env.PORT，那 Railway 的请求就进不来。
  5. 代码里有“惊喜”： 比如你提到的 app.use(express.static(...)) 和 app.get('*', ...) 用来服务前端文件。这部分代码放在 Railway 后端是完全没必要的（前端由 Vercel 托管），还可能跟 API 路由或 CORS 处理产生冲突。

对症下药：一步步解决 CORS 和 502

咱们一个个来排查和解决。

1. 检查 Railway 后端状态和日志

这是第一步，也是最重要的一步。502 大概率是应用本身的问题。

  • 原理： 查看应用在 Railway 上的部署状态、实时日志，可以发现应用是否正常运行、有没有报错崩溃、监听端口是否正确。
  • 操作步骤：
    1. 登录 Railway Dashboard。
    2. 进入你的 Express 项目。
    3. 查看 Deployments （部署）页面，确认最近的部署是否成功 (Success) 并且是 Active 状态。
    4. 切换到 View Logs （查看日志）或类似标签页，仔细阅读应用启动日志和运行日志。
      • 看有没有类似 Error: listen EADDRINUSE: address already in use :::8080 这样的端口冲突错误。
      • 看有没有应用启动失败的堆栈跟踪。
      • 尝试从 Vercel 前端发起请求，同时观察 Railway 的实时日志，看收到 OPTIONS 或 POST 请求时有没有错误信息。
  • 进阶技巧：
    • 在 Express 应用中加入更详细的日志记录，尤其是在中间件的入口和出口、重要的业务逻辑处。可以使用 morgan (用于 HTTP 请求日志) 或者 winston、pino (用于应用内部日志)。
// 例如，使用 morgan 记录 HTTP 请求
const morgan = require('morgan');
// ... 其他 require
const app = express();

// 放在其他 app.use 之前，或者根据需要调整位置
app.use(morgan('dev')); // 'dev' 格式提供简洁彩色输出，适合开发

// ... 你的 CORS 设置、路由等

app.listen(port, () => {
  console.log(`Server listening on port ${port}`); // 确认监听端口日志
});

2. 优化 Express CORS 中间件配置

确保 CORS 配置正确且在需要的地方生效。

  • 原理： cors 中间件需要能够处理 Preflight (OPTIONS) 请求，并为实际请求（GET, POST 等）添加正确的 CORS 响应头（如 Access-Control-Allow-Origin, Access-Control-Allow-Methods 等）。
  • 代码示例与解释：
    • 你的 corsOptions 看上去是合理的，明确指定了 origin、methods 和 allowedHeaders。
    • 关键在于中间件的使用时机。通常建议将 app.use(cors(corsOptions)) 放在所有 API 路由处理之前，让所有请求都能应用这个配置。
    • 单独处理 app.options('*', cors(corsOptions)) 是一个常见做法，确保 OPTIONS 请求被快速响应。但是，也可以只用一个全局的 app.use(cors(corsOptions))，cors 中间件内部会自动处理 OPTIONS 请求。为了简化和避免潜在冲突，推荐先尝试只用全局的。
const express = require("express");
const cors = require("cors");
const app = express();

// **非常重要** ：从 Vercel 获取的 Origin 可能不完全是你手写的那个
// 建议在后端打印出来看看 req.headers.origin 是啥，或者用更灵活的配置
const allowedOrigins = ["https://lunartechlab-zelino.vercel.app"]; // 可以根据需要添加本地开发环境 http://localhost:xxxx

const corsOptions = {
  origin: function (origin, callback) {
    // 允许没有 origin 的请求（比如 Postman、服务器间调用）或 origin 在白名单里的请求
    if (!origin || allowedOrigins.indexOf(origin) !== -1) {
      console.log('CORS check passed for origin:', origin); // 调试用
      callback(null, true);
    } else {
      console.error('CORS check failed for origin:', origin); // 调试用
      callback(new Error("Not allowed by CORS"));
    }
  },
  methods: ["GET", "POST", "OPTIONS"], // 明确加入 OPTIONS，虽然 cors 库通常会处理
  allowedHeaders: ["Content-Type", "Authorization"], // 根据你实际需要调整，比如可能需要 Authorization
  credentials: true, // 如果前端需要携带 cookie，后端必须为 true
  optionsSuccessStatus: 200 // 让 OPTIONS 请求返回 200，某些旧浏览器或代理可能需要 204
};

// **放在所有 API 路由之前全局应用 CORS 配置** 
// cors() 内部会处理 OPTIONS 请求，一般无需再单独 app.options('*', cors())
app.use(cors(corsOptions));

// 如果你用了 express.json() 或 express.urlencoded() 解析请求体，确保它们也在 CORS 之后
// 并且它们不应该干扰 OPTIONS 请求（OPTIONS 请求没 body）
app.use(express.json());
app.use(express.urlencoded({ extended: true }));


// --- 你的 API 路由 ---
app.post("/api/send-mail", (req, res) => {
  // ... 处理邮件发送逻辑 ...
  console.log("Received request for /api/send-mail");
  // 模拟成功响应
  res.status(200).json({ status: "success", message: "Email sent conceptually!" });
});

// --- 其他路由或错误处理 ---

// ... 服务器监听代码 ...
  • 安全建议：
    • 绝对不要 在生产环境中使用 origin: '*'，除非你的 API 是完全公开的。精确指定允许的源 origin。
    • allowedHeaders 只列出前端确实会发送的头。
    • credentials: true 要与前端 axios 配置中的 withCredentials: true 配对使用，且 origin 不能是 '*'。

3. 确认 Express 监听端口

确保应用监听 Railway 期望的端口。

  • 原理： PaaS 平台通过内部网络路由流量到你的应用容器的指定端口，这个端口通常由平台通过环境变量设定。
  • 代码示例：
const port = process.env.PORT || 8080; // Railway 通常设置 PORT 环境变量，提供一个备选端口（比如 8080 或 3000）

app.listen(port, '0.0.0.0', () => { // 监听 '0.0.0.0' 确保接受来自任何 IP 的连接（在容器内）
  console.log(`Server listening actively on port ${port}`);
});
  • 操作步骤：
    1. 检查你的 app.listen 代码，确保使用了 process.env.PORT。
    2. 如果 Railway 提供了设置环境变量的地方，确认 PORT 变量没有被你意外覆盖。通常不需要手动设置 PORT，平台会自动注入。

4. 移除 Express 中不必要的静态文件服务

你的 Express 后端运行在 Railway，Vue 前端由 Vercel 提供服务，Express 不需要也没能力（跨域限制）去服务 Vercel 上的前端静态文件。

  • 原理： 让各个服务职责单一。Vercel 负责高效地全球分发前端静态资源，Railway 专注运行后端 API 逻辑。混合在一起会增加复杂度、引起潜在路由冲突，还可能拖慢后端响应。
  • 操作步骤：
    • 删除或注释掉你 Express 代码中类似下面的行：
// --- 删除或注释掉以下内容 ---
// const path = require('path'); // 如果只在这里用了 path，也删掉
// app.use(express.static(path.join(__dirname, "../../vuejs/dist")));
// app.get("*", (req, res) => {
//   res.sendFile(path.join(__dirname, "../../vuejs/dist/index.html"));
// });
// --- 删除结束 ---

5. （可选）理解并修正 Vercel 代理（如果需要）

你提供的 vercel.json 配置试图使用 Vercel 的重写功能作为代理。但你的 axios 代码是直接请求 Railway 的 URL，所以这个 vercel.json 实际上并没有被用到，并且它的目标 destination 写错了。

咱们分两种情况讨论：

  • 情况 A: 继续直接调用 Railway URL（就像你现在这样）

    • 原理： 简单直接，浏览器直接与后端通信，需要后端正确配置 CORS。这是你目前遇到的场景。
    • 操作：
      • 你的 axios 代码保持不变（请求 https://lunarexpress.lunartechlab.com/api/send-mail）。
      • 删除或修正 vercel.json 文件。如果不再需要任何 Vercel 的特殊路由规则，可以直接删除它。如果还有其他规则（比如单页面应用 fallback），保留它们，但删除关于 /api 的 rewrite。一个典型的 Vue SPA fallback 可能是： 
        // vercel.json for a standard Vue SPA (no backend proxy)
{
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}
    • 重点： 确保前面几步（检查 Railway 日志、配置 Express CORS、检查端口）都已完成。

  • 情况 B: 使用 Vercel 作为代理（隐藏后端 URL，可能简化 CORS）

    • 原理： 前端 axios 请求 Vercel 自己域名下的一个路径（比如 /api/send-mail）。Vercel 收到这个请求后，在服务器端把它转发给真实的 Railway 后端地址。对浏览器来说，请求始终发往 Vercel 的同源地址，从而避免了浏览器端的 CORS Preflight 检查 。注意，这并不意味着 后端不需要 CORS 配置，只是浏览器行为变了。后端可能仍需配置 CORS 来允许 Vercel 服务器的请求（虽然通常 Vercel 到 Railway 不会触发严格的浏览器 CORS 限制，但最好还是配置好，或者至少确认不配也没问题）。
    • 操作：
      1. 修改 vercel.json ，让它正确地代理 /api 开头的请求到你的 Railway 后端： 
        // vercel.json - Configuring Vercel as a proxy
{
  "rewrites": [
    // Proxy /api requests to your Railway backend
    {
      "source": "/api/(.*)", // 匹配所有 /api/ 开头的路径
      "destination": "https://lunarexpress.lunartechlab.com/api/$1" // 转发到 Railway 后端对应路径
    },
    // Vue SPA fallback (keep this if you need it)
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}
      2. 修改前端 axios 请求 ，让它请求 Vercel 的相对路径： 
        import axios from "axios";

export const sendEmail = async (formData) => {
  try {
    // **注意这里的 URL 变了！不再是 Railway 的完整 URL** 
    // 假设你的 Vercel 域名是 lunartechlab-zelino.vercel.app
    // 请求会发往 https://lunartechlab-zelino.vercel.app/api/send-mail
    // 然后 Vercel 会把它转发到 https://lunarexpress.lunartechlab.com/api/send-mail
    const response = await axios.post(
      "/api/send-mail", // 使用相对路径或基于 Vercel 域名的路径
      formData
      // 如果后端 CORS 需要 credentials: true，这里也要加上
      // { withCredentials: true }
    );
    return response.data;
  } catch (err) {
    // 错误处理：可能是网络问题，也可能是后端返回的错误
    console.error("Error sending email:", err.response ? err.response.data : err.message);
    throw err; // 重新抛出，让调用方处理 UI 反馈等
  }
};
      3. 部署 Vercel 和 Railway 的更新。
    • 优点： 可能绕开复杂的浏览器 CORS Preflight 问题，隐藏后端真实 URL。
    • 缺点： 增加了一层转发，可能略微增加延迟；排查问题时需要考虑 Vercel 代理层。

给新手的建议： 先尝试 情况 A ，即直接调用 Railway URL 并把后端的 CORS 配置搞对。这是理解 CORS 工作原理的基础。只有当这个方案确实搞不定，或者有隐藏后端 URL 的需求时，再考虑使用 Vercel 代理（情况 B）。

防患未然：部署和调试小贴士

  • 本地模拟： 尽量在本地模拟 Vercel + Railway 的部署环境。比如本地启动 Vue 开发服务器 (npm run serve)，同时本地启动 Express 服务器 (node server.js)，配置好 Express 的 CORS 允许本地前端源（http://localhost:xxxx），看本地跨域是否工作。
  • 善用浏览器开发者工具： F12 打开 Network 面板，仔细查看失败的 OPTIONS 或 POST 请求。
    • 看 Headers 标签页，确认请求的 Origin, Access-Control-Request-Method, Access-Control-Request-Headers 是什么。
    • 看 Response 标签页（虽然 502 可能没啥内容），或者看 Status Code 是不是 502。
    • 看 Console 面板的 CORS 错误详细信息。
  • 细读平台文档： Railway 和 Vercel 都有关于部署 Node.js 应用、自定义域名、环境变量、日志、代理等的详细文档，遇到平台相关问题时多查查。

通过上面这些步骤，按理说你应该能定位并解决掉那个烦人的 CORS Preflight 502 问题了。祝你好运！