让项目离开我的电脑：从 localhost 到 Nginx

第一次把项目放上服务器时，我以为最重要的是把代码传过去，然后执行和本地一样的启动命令。

程序确实启动了，浏览器却打不开。后来端口通了，两个域名又显示成同一个网站。接着刷新页面出现 404，静态资源路径也开始报错。本地环境替我隐藏的细节，在服务器上一个接一个出现。

从 localhost 走到公网，不是一次文件复制，而是把项目放进一套新的网络、权限与进程环境。

先画清楚请求走过的路

排查部署问题前，我会先写出最短链路：

域名解析 → 服务器端口 → Nginx → 应用端口或静态目录 → 应用响应

如果浏览器没有拿到预期页面，就沿着这条路径逐层确认。域名是否解析到正确地址，防火墙是否允许访问，Nginx 是否加载了正确配置，应用是否真的监听目标端口，每一层都能独立验证。

把链路画出来之后，“网站打不开”就不再是一个巨大而模糊的问题。

两个域名为什么跑进了同一个站点

我遇到过多个域名最终显示同一页面的情况。原因并不神秘，通常是 Nginx 没有匹配到预期的 server_name，于是请求落到了默认站点，或者多个配置指向了相同的 root 与代理目标。

这类问题让我形成了固定检查：

• 每个站点的域名匹配是否清楚
• 静态站点的 root 与入口文件是否正确
• 动态应用的 proxy_pass 是否指向实际监听端口
• 是否残留默认配置或重复的服务块
• 修改后是否通过语法检查并重新加载

只改配置文件却没有让 Nginx 重新加载，是另一种很常见的“我明明改了”。

日志比浏览器的空白页更诚实

浏览器通常只告诉我 404、502 或一个空白页面。Nginx 访问日志、错误日志和应用日志会提供更具体的方向。

502 往往意味着代理目标没有正常响应，404 可能发生在 Nginx，也可能来自应用路由。静态资源加载失败时，还要检查构建后的路径、权限和前端基础地址。

我会先确认错误由哪一层返回，再决定修改哪里。这样可以避免在前端、Nginx 和后端之间来回碰运气。

部署完成不等于进程暂时活着

手动运行一条命令后关闭终端，应用可能随之退出。一次正式部署还需要考虑进程如何保持、异常后是否恢复、日志放在哪里、配置与密钥如何管理。

根据项目规模，可以选择进程管理工具、系统服务或 Docker。工具并不是重点，重点是让启动方式明确、状态可查、失败可追踪，并避免把敏感配置直接写入仓库。

我的部署检查表

现在我会在交付前至少确认这些内容：

1. 构建命令和生产启动命令能够重新执行
2. 环境变量、数据库与外部服务配置完整
3. Nginx 域名、静态目录或代理端口正确
4. 进程在退出终端后仍能稳定运行
5. 日志路径明确，常见错误可以定位
6. 关键页面、刷新路由和静态资源都经过测试

localhost 给了我快速试验的空间，服务器则迫使我面对真实边界。项目能够被外部访问的那一刻，不只是部署成功，也意味着我开始理解代码以外的运行环境。