最近，我为一个跨境电商网站客户，在我们租用的香港云服务器（物理或 VPS 均可）上部署了一个基于静态 + PHP + API 混合的网站 — 静态页面 + Laravel 后端 + 若干 API 接口。客户要求全球访问速度快、尤其面向中国大陆 + 东南亚，因此我们选用了香港机房 + BGP 混合 CN2 线路 + SSD 存储 + Nginx 反向代理 + PHP-FPM。

香港云服务器基础配置如下：

部署完成后，我通过域名 + IP + hosts — 三种方式都能 ping 通，DNS 解析正常，但浏览器访问域名，却总是返回 “404 Not Found”。页面内容是 Nginx 默认的 404 页面。

起初我还以为是 DNS / 域名没生效，但 DNS 已经正常解析到香港云服务器 IP；于是我决定从最底层，也就是 Web — Nginx 配置 + 目录 + 权限 + 日志，逐步排查。下面是全过程。

排查思路与主要原因分析

根据我多年运维 Web + 静态／动态混合站点的经验，遇到 404 时，最常见的原因包括：资源不存在、路径配置错误、Nginx 配置错误、权限不足、rewrite / 路由规则冲突、后端未启动 / 路由不匹配、HTTP 与 HTTPS 配置分离、代理 / reverse‑proxy 配置错误等。

参考公开资料也证实这些是 Nginx + Web 服务碰到 404 的常见原因。

下面列出我排查的主要方向：

1. 请求的 URL 是否正确／拼写错误／路径错误
2. 文件是否真的存在于服务器，以及目录结构是否和 Nginx root / alias 匹配
3. Nginx 配置是否正确 — root / location / try_files / index / server_name / vhost 是否正确配置
4. 文件／目录权限／所属是否正确，Nginx（www-data 或 nginx 用户）是否有读取权限
5. 如果用了 PHP 或后端框架，是否是框架路由的问题；Nginx + PHP-FPM 的配置是否合理
6. 是否有 HTTP 与 HTTPS 的配置差异 — 有可能 HTTPS 正确但 HTTP 未配置（或反之）导致 404。
7. 如果用了反向代理（proxy_pass），是否 backend 服务挂了或路径不正确，导致 proxy 返回 404 或 Nginx 找不到资源

我当时的排查步骤（实战记录）

以下是我的真实命令、日志、思考与发现 — 可以当作“现场运维笔记”。

1. 基础检查 —— URL + DNS + ping + HOSTS

我先在本地 hosts 文件里强制把域名指向香港云服务器 IP，清除浏览器缓存，然后访问 http://myshop.example.com/，依然 404。

用 curl -I http://myshop.example.com/，得到响应：

HTTP/1.1 404 Not Found  
Server: nginx/1.24  
Date: Fri, 05 Dec 2025 10:00:00 GMT  
Content-Type: text/html  
Content-Length: 162  
Connection: keep-alive

→ 说明请求确实发到了 Nginx，Nginx 在运行，但它认为资源不存在。

确认 DNS 生效、域名解析没问题 → 排除 DNS 污染、域名没生效、IP 错误等。

于是问题很可能在 Web 服务配置或资源本身。

2. 检查服务器目录结构 + 静态资源是否就绪

ssh ubuntu@hongkong-server
cd /srv/www/myshop
ls -R

确认网站文件已经正确上传，包括首页 index.html 或 public/index.php（Laravel）等。

树结构大致如下：

/srv/www/myshop/
├── public/
│     ├── index.php
│     ├── css/
│     ├── js/
│     └── assets/
├── storage/
└── vendor/

也就是说，代码没问题，文件也在，但访问仍旧 404。说明只是 Web 服务没正确把请求“映射”过去。

3. 检查 Nginx 配置

我打开了对应站点的 Nginx vhost 配置文件 /etc/nginx/sites-available/myshop.conf，内容类似这样（我当时还没调通）：

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

    root /srv/www/myshop/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # 其他配置如静态资源 cache、expires 等略
}

然后我执行了：

sudo nginx -t

输出：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

→ 说明配置语法没问题。

然后重载：

sudo systemctl reload nginx

但浏览器访问依然 404。

这说明不是语法错误，而是“逻辑”/“路径映射 / 资源查找”问题。

4. 查看 Nginx 错误日志

这是关键一步 —— Nginx 错误日志通常可以告诉你具体它找不到哪个文件。

sudo tail -n 50 /var/log/nginx/error.log

日志里我看到类似：

2025/12/05 10:05:12 [error] 1234#0: *45 open() "/srv/www/myshop/public/index.html" failed (2: No such file or directory), client: …, server: myshop.example.com, request: "GET / HTTP/1.1", host: "myshop.example.com"

关键是它试图访问 index.html，并报不存在。可事实上，我的首页是 index.php，而非 index.html。因为 try_files $uri $uri/ =404; 这一规则，对于根路径 /，$uri 会被解析为 /，Nginx 会先尝试 /srv/www/myshop/public/ + / → /srv/www/myshop/public/ ，然后 /srv/www/myshop/public// → 同目录，最后都失败，就返回 404。它并不会自动 fallback 到 index.php。

这个逻辑是很多人踩坑的点，也是我当时漏掉的：try_files 默认用 =404，其实我们希望 root path 能 fallback 到 index.php（适用于 PHP + Laravel、SPA、框架等情景）。很多公开资料也提到 “如果没有正确配置 try_files / index，会导致 404”。

真正的问题 & 解决方法 — 改写 Nginx 配置 + 调整 try_files

根据日志和目录结构，我意识到 “根路径 / 不应该只 try_files $uri $uri/ =404 ”，而应该 fallback 到 index.php。

于是，我修改了 Nginx 配置为：

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

    root /srv/www/myshop/public;
    index index.php index.html;

    location / {
        # 对于 Laravel / PHP 框架 / SPA，尝试 uri，再 uri/，最后 fallback index.php 并带参数
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # 其他配置如静态资源 cache, security headers 等略
}

然后重新 test + reload：

sudo nginx -t && sudo systemctl reload nginx

接着浏览器刷新 —— 页面终于正常加载，首页、CSS、JS、API 一切正常。

同时，我通过 curl -I 也确认响应是 HTTP/1.1 200 OK + 正确页面内容，而不是 404。

完整排查清单 & 推荐流程

基于我这次实战经历 + 结合社区通用经验，这里总结一个“404 排查 & 解决”标准清单 / 流程 —— 非常适合你写成博客教程 + 给客户／同事用。

我踩过的坑 & 教训（真实反思）

坑 1 — 默认 try_files … =404：这是很多人忽略的问题。刚开始我以为 “root + index index.php” 就够了，但静态请求之外，框架入口（index.php）没 fallback，就会 404。

坑 2 — 忘了检查错误日志 — 日志会直接告诉你它找哪个文件找不到，省了很多盲目猜测时间；刚开始我只依赖浏览器页面 + status code，看不到原因。

坑 3 — 权限没问题，但如果你用了 alias 而不是 root，或 document_root + SCRIPT_FILENAME 拼接不当，也会导致 PHP-FPM 无法正确加载文件，间接导致 404 / 500。虽然这次没遇到 alias，但以前做过一次 alias 配置导致后台全 404 的惨痛教训。

坑 4 — HTTP/HTTPS 配置不一致：之前曾有一次，我配置了 HTTPS 正常（443 + ssl + root + index），但忘记配置 80 端口或者 vhost，被别人通过 HTTP 访问时全 404。

所以，现在我的“新部署” checklist 中都会特别把第 6、8、10 步设为必须检查项目。

扩展场景 —— 当你的服务架构更复杂时，还可能引起 404 的原因

如果你的部署涉及反向代理 / load‑balancer / CDN（比如你在香港云，前面还有某个 ALB / ELB / CDN + edge server），可能是转发规则不正确 — backend path / URL 重写规则不对。公开资料也提到，当是 ALB / ELB 时，如果没有相应转发策略，也可能返回 404。

如果你的网站是 SPA（单页面应用），前端路由（history mode）没有正确 fallback，也会导致子路由 404，这时候必须改 try_files $uri $uri/ /index.html; 或 /index.php。

如果你用了 HTTPS，并且重写规则或 redirect / HSTS / SSL 配置不正确，也可能让 HTTP 路由失效。

“香港云服务器 + Nginx + PHP”部署经验教训

写这篇文章，是因为刚刚帮一个客户从 “报 404” 到 “页面正常” 的过程，让我深刻体会到：很多“部署失败”并不是硬件不够坚固 / 网络不够快 / 云服务器不好，而是 配置细节 的问题。尤其是像 try_files，root/alias，index，location，vhost 这些看似“基础”的配置，如果不对，整个站点就等于“不可访问”。

对于我们这种为跨境电商、企业站、游戏、直播、短视频等业务提供“香港云 + 高性能 + 高并发 + 稳定链路”的服务供应商来说，上线前必须做一个严格的“配置 + 权限 + 路由 + 后端 + 日志 + 回归测试”清单，把这些细节当作标准化流程的一部分