从域名到 Node.js：一次云服务器请求经过了哪些层？

项目部署到云服务器后，最容易混淆的不是命令，而是"请求到底经过了谁"。浏览器输入域名后，DNS 只负责找到 IP；安全组和防火墙负责放行；Nginx 负责把请求分给静态文件或 Node.js；Node.js 再访问 MySQL 完成业务。本文沿着这条链路梳理前后端分离项目的部署结构，并给出一份可用于排查问题的检查表。内容来自部署学习笔记，示例配置和命令运行未验证。

先看最终请求链路

text 复制代码

浏览器输入域名
    ↓
DNS：域名 → 公网 IP
    ↓
安全组 / Linux 防火墙
    ↓
Nginx
    ├── 前端请求 → 静态文件
    └── /api 请求 → Node.js
                         ↓
                       MySQL

理解部署时，建议先记住这条链路，再分别看每个节点的职责。

前端和后端分别产出什么？

React + TypeScript 项目在开发阶段通常使用：

bash 复制代码

npm run dev

发布前使用：

bash 复制代码

npm run build

构建后会产出 dist 等静态文件。HTML、CSS、JavaScript 和图片不需要 Node.js 逐个执行业务逻辑，Nginx 就可以直接返回。

Node.js 项目则提供动态 API，例如：

text 复制代码

/api/todos → JSON

因此生产环境的基本职责分离是：

text 复制代码

Nginx：文件和请求分流
Node.js：业务逻辑和 API
MySQL：持久化数据

DNS 只负责"找到入口"

用户访问：

text 复制代码

https://example.com

DNS 会把域名解析为一个 IP：

text 复制代码

example.com → 云服务器公网 IP

查询可能涉及本机缓存、递归 DNS、根域名服务器、.com 顶级域名服务器和权威 DNS 服务器。缓存命中时，系统可能直接使用已有结果。

这里有一个重要边界：

DNS 不返回网页，也不执行 API。它只帮助客户端定位网络入口。

拿到 IP 后，浏览器还要访问相应端口，后面才轮到 Nginx 处理。

两层网络防线：安全组和防火墙

云服务器的访问控制通常有两层：

防线	位置	解决的问题
安全组	云厂商网络层	外部流量能否到达服务器端口
防火墙	Linux 系统内部	服务器是否接受该端口连接

常见端口包括：

text 复制代码

80   HTTP
443  HTTPS
3306 MySQL

网站通常要考虑 80 和 443；MySQL 的 3306 不应默认向整个公网开放。部署笔记还提到，后端启动失败时，要检查防火墙、宝塔面板中的端口设置以及数据库权限。

Nginx：同一个域名下的分流器

Nginx 既是 Web 服务器，也可以是反向代理。简化配置如下：

nginx 复制代码

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
    }
}

它的含义是：

在 80 端口接收 HTTP 请求。
匹配访问域名 api.example.com。
location / 匹配路径。
将请求转发到当前云服务器的 3001 端口。

这里的 127.0.0.1 是 Nginx 所在服务器本机，不是开发者的电脑。如果 Node.js 和 Nginx 在同一台云服务器上，这种写法很常见。

前后端同机部署时，分流思路可以表示为：

text 复制代码

/          → 返回 dist 中的前端文件
/api/...   → 代理给 Node.js

笔记中出现了 3001 和 3006 两个端口示例，因此端口不能死记，必须以 Node.js 实际监听端口和 Nginx 配置为准。

开发时的 mock，生产时的真实后端

部署笔记记录了一个很有价值的对比：

text 复制代码

开发阶段：/api/todos → Vite mocks
生产阶段：/api/todos → Nginx → Node.js

前端代码可以保持相同的请求路径，但后面真正处理请求的组件发生了变化。

这也解释了一个常见问题：本地页面能请求 /api/todos，不代表生产服务器已经配置正确。上线后至少要确认：

生产 Nginx 是否匹配 /api/。
Node.js 是否正在运行。
Nginx 代理端口是否和 Node.js 监听端口一致。
安全组和防火墙是否允许必要连接。
Node.js 使用的数据库配置是否正确。

宝塔降低操作门槛，但不改变架构

笔记使用 Linux 云服务器，并提到宝塔面板和 /www/wwwroot 网站目录。可以这样区分：

text 复制代码

Linux  → 操作系统
宝塔   → 可视化管理工具
Nginx  → Web 服务和反向代理
Node.js → 业务运行时

宝塔让安装和配置更容易，但真实运行的仍然是 Nginx、Node.js、MySQL 等服务。宝塔面板本身也有管理端口，不能因为"有面板"就忽略端口暴露和访问来源限制。

数据库和 Node.js 环境也要隔离

部署笔记建议创建两个 MySQL 库：

text 复制代码

dev
production

这样开发测试不会直接污染线上数据。实际项目还应继续明确账号权限、备份、迁移和连接来源；这些内容不在本次材料中。

Node.js 版本则可以用 nvm 管理。不同项目可能要求不同版本，服务器准备阶段应先确认项目要求，避免依赖安装或运行时版本不匹配。

一份故障排查顺序

出现问题时不要先反复重启服务，可以从外到内排查：

text 复制代码

域名 → DNS → 安全组 → 防火墙 → Nginx → Node.js → MySQL

现象	先查什么
域名无法访问	DNS 记录和域名状态
请求超时	安全组、防火墙、目标端口
页面 404	Nginx 的静态目录和路径匹配
Nginx 502	Node.js 是否运行、代理端口是否正确
页面正常但 API 失败	`/api/` 代理和后端日志
后端启动失败	Node.js 版本、数据库权限和环境配置

部署自检清单

text 复制代码

[ ] 域名已经解析到正确公网 IP
[ ] 80 / 443 等必要端口已按需放行
[ ] 前端已经 npm run build
[ ] Nginx 指向正确的静态文件目录
[ ] /api/ 代理到正确的 Node.js 端口
[ ] Node.js 服务正在运行
[ ] dev 和 production 数据库没有混用
[ ] MySQL 没有无条件暴露给公网
[ ] 生产环境已规划 HTTPS
[ ] 宝塔面板端口已限制访问来源

最后记住组件边界

部署问题之所以容易绕，是因为多个组件共同参与了一个请求。把职责拆开后，判断会清晰很多：

DNS：把域名指向 IP。
安全组和防火墙：决定连接能不能进来。
Nginx：接收请求，返回静态文件或反向代理。
Node.js：执行后端业务并返回 JSON。
MySQL：保存业务数据。
宝塔：提供可视化管理入口。

下一步可以拿一个真实项目，逐项核对域名、端口、Nginx 路径、Node.js 进程和数据库连接。本文没有读取实际项目配置，所有示例代码和命令运行未验证。

标签：云服务器 Nginx Node.js DNS 部署