首次启动网站时，看到 Nginx 进程处于 active (running)，并不代表新加坡服务器上的网站已经可以从公网访问。服务可能只监听本机，TCP 80 端口也可能被防火墙拦截，或者请求没有匹配到正确的站点配置。

对于首次上线的静态页面，最小可用路径是：准备一台可通过 SSH 管理、具备公网访问条件的 Ubuntu 主机，安装 Ubuntu 软件源中的 Nginx，创建一个可读取的网页目录，完成站点配置并通过 nginx -t 检查，随后分别验证本机请求和公网请求。域名解析不是第一步的硬性条件，可以先使用 curl --resolve 在不修改 DNS 的情况下验证 Nginx 和网站目录是否工作。

先划定基础验证的范围

这里的“基础验证”是确认以下链路已经成立：

客户端
  ↓
服务器公网地址与 TCP 80
  ↓
Nginx 监听端口
  ↓
server_name 匹配站点
  ↓
root 指向网站目录
  ↓
index.html 返回 HTTP 响应

这套方法适合首次部署静态 HTML 页面，或者在应用尚未接入前确认 Web 层是否正常。它不包含 PHP、Node.js、Python 应用、数据库、反向代理、HTTPS 证书和正式上线前的安全加固。

新加坡服务器的地域不会改变 Ubuntu 和 Nginx 的基本配置方式。地域可能影响访问路径和访问者体验，但不能用来替代端口、监听地址、域名匹配和文件权限验证。判断网站是否“可用”，应以实际请求能否获得预期 HTTP 响应为准。

开始前需要具备的条件

• 已获得 Ubuntu 服务器的 SSH 登录方式。
• 登录账号可以使用 sudo。
• 服务器能够访问 Ubuntu 软件源，至少可以完成软件包更新和安装。
• 已知服务器公网 IPv4 地址，或者已经准备好一个用于测试的域名。
• 如果服务器处于云平台或托管平台，还需要确认平台侧的入站规则允许 TCP 80。具体规则名称和管理位置取决于平台，不能仅凭 Ubuntu 内部状态判断。

如果只是验证 Nginx，域名可以暂时不接入 DNS。后文使用 example.com 作为示例域名，执行命令前应替换为自己的域名。

Nginx 如何处理首次请求

Nginx 收到请求后，通常会根据监听地址、端口和请求中的 Host 头选择 server 配置块。选中站点后，Nginx 再根据 root 找到文件目录，并根据 index 查找默认首页。

例如：

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

    root /var/www/example.com;
    index index.html;

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

访问 http://example.com/ 时，Nginx 会尝试读取：

/var/www/example.com/index.html

因此，以下几个条件缺一不可：

• listen 80; 对应客户端实际访问的端口。
• server_name 与请求中的域名一致。
• root 指向真实存在的网站目录。
• 首页文件名称与 index 配置一致。
• Nginx 进程能够穿过目录并读取网页文件。
• 服务器和平台侧的网络规则允许外部访问。

直接访问公网 IP 时，如果请求没有携带匹配的域名，Nginx 可能返回默认站点，而不是目标站点。这也是“浏览器能打开页面，但打开的是 Nginx 默认页”的常见原因。

在 Ubuntu 上完成最小部署

以下命令适用于使用 APT 和 systemd 的 Ubuntu 主机。先通过 SSH 登录服务器，再执行操作。

1. 更新软件包索引并安装 Nginx

sudo apt update
sudo apt install -y nginx

安装完成后，先确认命令和版本可用：

nginx -v

这里不需要预先指定某个版本号。Ubuntu 软件源提供的 Nginx 包应以当前主机的软件源和系统版本为准。如果 apt update 失败，应先处理软件源、DNS 或服务器出网问题，不要直接修改 Nginx 配置来绕过安装错误。

2. 启动并设置 Nginx 随系统启动

sudo systemctl enable --now nginx
sudo systemctl status nginx --no-pager

状态中看到 active (running)，只能说明 systemd 认为服务进程正在运行。还需要继续检查监听端口和实际 HTTP 响应。

确认 TCP 80 是否被 Nginx 监听：

sudo ss -ltnp | grep ':80'

正常情况下，应能看到本机地址上的 LISTEN 记录，并能识别出 Nginx 进程。若没有任何输出，先检查：

sudo systemctl status nginx --no-pager
sudo journalctl -u nginx --no-pager -n 50

3. 创建测试页面

以下示例使用 /var/www/example.com 作为网站目录。目录名称可以根据实际域名调整。

如果该目录或首页已经存在，不要直接覆盖生产文件；应先备份，或者改用新的测试目录。

sudo install -d -m 755 /var/www/example.com

cat <<'HTML' | sudo tee /var/www/example.com/index.html >/dev/null



    
    


    
A5IDC Nginx OK
    
This page confirms that the Ubuntu and Nginx basic deployment is responding.


HTML

sudo chmod 644 /var/www/example.com/index.html

这里使用简单的静态文件，是为了把问题范围限定在 Nginx、目录、端口和网络链路。如果连静态页面都无法返回，就没有必要先排查应用运行时或数据库。

可以检查目录和文件权限：

namei -l /var/www/example.com/index.html

父目录需要具备可遍历权限，文件需要具备可读权限。示例中的 755 和 644 是常见的静态文件权限，并不意味着所有应用都必须使用相同权限。

4. 创建 Nginx 站点配置

下面的配置适合首次验证一个静态网站。它只监听 IPv4 的 TCP 80，避免在尚未确认 IPv6 可用时增加额外变量。

如果配置文件已经存在，请先备份：

if sudo test -e /etc/nginx/sites-available/example.com; then
    sudo cp -a /etc/nginx/sites-available/example.com \
        /etc/nginx/sites-available/example.com.bak
fi

然后创建或更新配置文件：

cat <<'NGINX' | sudo tee /etc/nginx/sites-available/example.com >/dev/null
server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

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

    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;
}
NGINX

需要注意：

• example.com 和 www.example.com 必须替换为实际使用的域名。
• root 必须与前面创建的目录完全一致。
• try_files ... =404 表示请求的文件不存在时返回 404，不会把错误伪装成首页成功。
• 这段配置只处理 HTTP 静态文件，不会自动提供 HTTPS，也不会代理到后端应用。

启用站点配置：

sudo ln -s /etc/nginx/sites-available/example.com \
    /etc/nginx/sites-enabled/example.com

如果系统提示目标链接已经存在，不要使用覆盖参数强行替换。先查看它指向哪里：

readlink -f /etc/nginx/sites-enabled/example.com

确认没有误改其他站点后，再决定是否调整链接。

5. 语法检查后再重新加载

配置文件发生变化后，先执行：

sudo nginx -t

只有看到语法检查成功，才执行重新加载：

sudo systemctl reload nginx

reload 通常比直接 restart 更适合配置变更，因为它会尝试让新的工作进程加载配置，不需要无条件中断现有连接。若 nginx -t 失败，不要继续 reload，应根据错误提示修正文件。

例如，如果需要撤销刚刚创建的站点链接，只能在确认该链接由本次操作创建、且没有其他站点依赖它时执行：

sudo unlink /etc/nginx/sites-enabled/example.com
sudo nginx -t
sudo systemctl reload nginx

unlink 只删除站点启用目录中的符号链接，不会删除 sites-available 中的目标文件，但仍应确认路径无误后再执行。

按层次验证网站是否可用

先验证本机请求

使用请求头指定域名，检查 Nginx 是否能匹配新站点：

curl -i -H 'Host: example.com' http://127.0.0.1/

正常情况下，响应应包含类似以下内容：

HTTP/1.1 200 OK
Content-Type: text/html

并且响应正文中能看到页面里的 A5IDC Nginx OK。

如果本机请求返回 404，重点检查 root、index.html 和 server_name。如果返回的是默认 Nginx 页面，说明请求可能匹配了默认站点，而不是新建的站点配置。

不修改 DNS 验证公网访问

在一台与服务器不同网络的客户端上执行。可以使用本地电脑、办公网络或其他具备公网出口的环境，但不要只在服务器内部测试。

将示例地址替换为服务器真实公网 IPv4：

curl --resolve example.com:80:198.51.100.10 -i http://example.com/

198.51.100.10 是文档示例地址，不能直接当作真实服务器地址使用。--resolve 的作用是让 curl 连接指定 IP，同时发送 Host: example.com，因此可以在 DNS 尚未生效或尚未修改时验证：

• 服务器公网地址是否可达；
• TCP 80 是否开放；
• Nginx 是否监听公网接口；
• server_name 是否匹配；
• 网站目录和首页是否能返回。

如果需要只查看状态码，可以使用：

curl --resolve example.com:80:198.51.100.10 \
    -sS -o /dev/null -w 'HTTP %{http_code}\n' \
    http://example.com/

返回 HTTP 200，并且正文测试标记正确，才可以认为这条基础 HTTP 链路已经通过。若返回 301 或 302，应进一步确认是否存在其他配置或应用跳转，不要把“能跳转”直接等同于目标页面已正常返回。

DNS 接入后的验证

完成 DNS 配置后，可以直接请求域名：

curl -i http://example.com/

也可以先查看域名解析到的地址：

getent ahosts example.com

如果 DNS 查询结果不是预期的服务器地址，或者同时存在不可用的 IPv6 地址，应先处理解析记录，再判断 Nginx 是否正常。不要因为浏览器偶尔打开成功，就忽略不同网络环境可能命中不同地址的情况。

防火墙检查不能跳过

Ubuntu 内部的 Nginx 监听正常，并不代表公网一定能访问。先查看 UFW 是否启用：

sudo ufw status verbose

如果状态为 inactive，不要为了测试而贸然启用 UFW。启用防火墙前若没有先放行 SSH，可能导致当前管理连接无法继续。

如果 UFW 已经处于启用状态，并且现有规则没有允许 HTTP，可以添加 TCP 80：

sudo ufw allow 80/tcp
sudo ufw status numbered

这条规则会影响所有通过该主机访问 TCP 80 的网站，不只影响当前测试站点。添加前应记录已有规则；回滚时，只能删除确认由本次操作添加、且没有其他网站依赖的规则：

sudo ufw delete allow 80/tcp

除了 Ubuntu 内部防火墙，还要检查服务器所在平台的入站访问控制。如果本机执行 curl http://127.0.0.1/ 成功，而外部请求超时，平台侧的 TCP 80 规则、上游网络策略或公网地址绑定状态都应纳入排查范围。

不同结果代表什么

排查时建议按由外到内的低风险顺序进行：先确认访问地址和端口，再确认平台与主机防火墙，然后检查 Nginx 监听和站点匹配，最后检查目录及文件权限。不要一遇到 404 就重装 Nginx，也不要在尚未确认配置错误时删除默认配置。

查看最近请求和错误日志：

sudo tail -n 50 /var/log/nginx/example.com.access.log
sudo tail -n 50 /var/log/nginx/example.com.error.log

如果外部请求没有出现在目标站点的访问日志中，说明请求可能没有到达该 server 配置块，或者被其他网络层拦截。若日志中出现请求但状态码异常，则应继续检查站点匹配、文件路径和权限。

什么时候可以判定基础验证通过

新加坡服务器上的 Ubuntu 与 Nginx 基础部署，可以在同时满足以下条件时判定为通过：

1. nginx -t 返回语法检查成功。
2. systemctl status nginx 显示服务处于运行状态。
3. ss -ltnp 显示 Nginx 正在监听 TCP 80。
4. 本机使用目标 Host 请求时返回预期测试页面。
5. 外部客户端使用 curl --resolve 或真实 DNS 请求时，能够获得预期状态码和页面内容。
6. 目标站点访问日志中出现了这次外部请求。

这套结果证明的是“Ubuntu 上的 Nginx 静态 HTTP 链路可用”，并不证明 HTTPS、应用运行时、数据库、上传功能或高并发能力已经准备完毕。后续如果接入动态应用，应在保留当前静态验证结果的基础上，再单独验证反向代理、应用进程、超时、权限和 TLS 配置，避免把多个变量同时引入首次上线过程。