如何用宝塔面板在香港服务器配置多站点的伪静态、SSL与反向代理？

在香港服务器上使用宝塔面板配置多站点，核心是为每个域名单独建立 Nginx 虚拟主机，再分别设置伪静态、SSL 证书和反向代理。静态站点直接读取文件，PHP 站点通过重写规则进入应用入口，后端应用则由 Nginx 接收 HTTPS 请求后转发到本机服务，三种处理方式不要混在同一个站点中盲目叠加。

下面以 Ubuntu 22.04 LTS、宝塔 Linux 面板、Nginx、PHP 8.2 为操作环境，配置三个示例站点。上线目标是：域名访问正确、PHP 路由正常、HTTPS 证书有效、后端端口不对公网开放，并且任何配置变更都能验证和回滚。示例域名和 IP 均需替换为自己的实际值，文中的输出说明用于判断结果，不代表实际执行记录。

一、准备环境、域名与配置备份

1. 明确三个站点的职责

三个域名可以使用同一个公网 IP。Nginx 根据请求中的域名选择虚拟主机，HTTPS 握手时通过 SNI 选择证书，因此无需为每个站点分配独立 IP。

香港服务器的部署位置不改变上述配置方式。实际影响访问体验的因素还包括服务器到访问者的线路、带宽和应用响应时间，不能仅凭部署地区判断访问效果。

面向多站点网站、业务后台和接口服务，A5数据提供中国香港物理服务器租用，覆盖入门建站、Xeon Gold与AMD EPYC等配置，并配备SSD或NVMe存储方案。结合CN2及国际带宽、多IP等资源，能够为PHP站点、数据库和Nginx反向代理应用提供相应的服务器部署基础。

2. 核对系统与软件

以下终端命令适用于 Ubuntu 22.04，以具有 sudo 权限的账户执行；涉及 /www/server 配置修改时，建议进入受控的 root 运维会话。

cat /etc/os-release
command -v curl
command -v dig
command -v python3
ss -lntp

缺少辅助工具时，可安装：

sudo apt-get update
sudo apt-get install -y curl dnsutils python3

该命令更新软件包索引并安装所列工具，不执行全系统升级。生产环境应先确认软件源和变更窗口。

未安装宝塔面板时，从宝塔官网获取适用于该系统的安装方式，核对来源后执行。在面板的软件商店安装 Nginx 和 PHP 8.2，不要同时启用 Apache 占用 80、443 端口。本文的 PHP 演示不依赖数据库；部署真实程序时，再按其要求安装数据库和 PHP 扩展。

3. 确认域名解析和端口放行

将三个域名的 A 记录指向服务器公网 IPv4，例如 203.0.113.10。这是文档示例地址，不能直接用于上线。

dig +short A www.example.com
dig +short A shop.example.com
dig +short A app.example.com
dig +short AAAA app.example.com

预期三个 A 记录返回实际公网 IPv4。若存在 AAAA 记录，还要确认服务器 IPv6、监听配置和 IPv6 防火墙均可用；否则部分访问或证书验证可能走到错误的 IPv6 地址。

在云平台安全组和服务器防火墙中核对：

• 对公网开放 TCP 80、443。
• SSH 和宝塔管理端口仅向受信任管理 IP 开放。
• 不对公网开放后端 3000 端口。
• 服务器能够访问所选证书签发服务。

先检查系统是否启用了 UFW：

sudo ufw status verbose

不要为了本教程直接执行 ufw enable，以免丢失远程管理连接。若 UFW 已启用，确认缺少规则后再添加：

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

防火墙修改前记录原规则，并保留云平台控制台访问方式。回滚时只删除本次新增的规则，不清空已有规则；安全组也按同样原则处理。

4. 备份宝塔站点配置

宝塔常见的 Nginx 配置位置为：

/www/server/nginx/conf/nginx.conf
/www/server/panel/vhost/nginx/
/www/server/panel/vhost/rewrite/
/www/server/panel/vhost/cert/

先核验本机实际路径：

/www/server/nginx/sbin/nginx -V 2>&1
ls -ld /www/server/panel/vhost/nginx
ls -ld /www/server/panel/vhost/rewrite

如果路径不同，以本机安装位置为准，不要照抄后续路径。

以下备份命令按常见路径执行，备份文件包含证书私钥，不应放进网站目录：

BACKUP="/root/bt-backup-$(date +%Y%m%d-%H%M%S)"

(
  umask 077
  mkdir -p "$BACKUP"
  cp -a /www/server/panel/vhost "$BACKUP/"
  cp -a /www/server/nginx/conf/nginx.conf "$BACKUP/"
)

printf '备份目录：%s\n' "$BACKUP"

站点代码和数据库应另外备份。这里的配置备份不能替代业务数据备份。

二、建立三个独立站点并验证 HTTP

1. 在面板中添加站点

进入宝塔面板的“网站”页面，分别添加三个站点：

1. www.example.com：选择纯静态，不创建数据库。
2. shop.example.com：选择 PHP 8.2，按应用需要决定是否创建数据库。
3. app.example.com：先选择纯静态，稍后配置反向代理。

每个域名只绑定到对应站点。不要把三个域名全部添加到同一个站点后，再期望它们自动访问不同目录。

确认网站目录、运行目录和默认文档。本文 PHP 示例直接使用站点根目录；若实际框架要求入口位于 public 目录，应在面板中设置相应运行目录，并确认有效配置中的 root 已指向它，而不是将整个项目根目录公开。

2. 放入可识别的验证文件

仅在新建的演示目录中创建以下文件。已有网站不要覆盖 index.html 或 index.php，应先备份并使用不冲突的测试文件。

静态站点示例：

<!doctype html>
<html lang="zh-CN">
<head>
  <meta charset="utf-8">
  <title>静态站点验证</title>
</head>
<body>
  <h1>Static site OK</h1>
</body>
</html>

保存为：

/www/wwwroot/www.example.com/index.html

PHP 站点示例：

<?php
header('Content-Type: text/plain; charset=utf-8');
echo "PHP route OK\n";

保存为：

/www/wwwroot/shop.example.com/index.php

通过面板文件编辑器创建即可。确认文件可被 Web 服务读取，不要用 chmod -R 777 处理权限问题。框架需要写入缓存或上传目录时，只对必要目录设置写权限。

3. 验证域名与虚拟主机绑定

在另一台能访问服务器的机器上执行：

curl -I http://www.example.com/
curl http://shop.example.com/

静态页面应返回正常的 HTTP 状态；PHP 页面应输出 PHP route OK。

DNS 尚未切换时，可强制连接目标服务器：

curl --resolve www.example.com:80:203.0.113.10 \
  http://www.example.com/

该命令仍携带正确的域名，仅替换本次连接地址。若返回其他站点内容，应检查域名绑定、重复的 server_name 和默认站点，而不是先改伪静态规则。

三、为 PHP 站点配置伪静态

1. 根据程序路由选择规则

伪静态不是把动态页面变成静态文件，而是将没有对应实体文件的 URL 交给应用入口处理。

以入口文件为 index.php 的程序为例，在 shop.example.com 的“伪静态”编辑区填写：

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

这条规则依次检查实际文件、目录，均不存在时转交 index.php，并保留查询参数。

它适用于这类入口路由，不是所有 PHP 程序的通用配置。程序有专用 Nginx 规则时，优先按其部署说明设置。

静态站点通常不需要入口重写。普通静态网站找不到文件时应返回 404；前端单页应用若要求刷新路由仍返回首页，可使用：

location / {
    try_files $uri $uri/ /index.html;
}

不要把该规则用于 PHP 站点，否则可能把错误路由甚至接口响应替换成 HTML 首页。

2. 避免重复的 location

宝塔站点主配置通常已经包含类似引用：

include /www/server/panel/vhost/rewrite/shop.example.com.conf;

在面板“伪静态”页面保存规则后，不要又在主配置里重复粘贴一个 location /。

如果已有 location /，应判断它是否负责缓存、前端路由或代理，然后修改原规则，而不是并列新增。PHP 执行通常还依赖宝塔生成的配置引用，例如：

include enable-php-82.conf;

不要为了添加伪静态删除 PHP 执行配置，否则可能导致 PHP 无法执行，甚至产生源代码暴露风险。

3. 检查语法并验证路由

后续示例统一使用以下变量，适用于当前终端会话：

NGINX=/www/server/nginx/sbin/nginx
MAINCONF=/www/server/nginx/conf/nginx.conf

"$NGINX" -t -c "$MAINCONF"

成功时应出现类似信息：

syntax is ok
test is successful

确认测试通过后再重载：

"$NGINX" -s reload -c "$MAINCONF"

这适用于运行中的 Nginx 使用上述二进制和主配置的情况。可先用 ps -ef | grep '[n]ginx: master' 核对；路径不一致时，应使用对应实例的重载方式。

验证不存在的实体路径：

curl -i 'http://shop.example.com/article/100?from=test'

演示站应返回 200 和 PHP route OK。真实应用可能返回其业务页面或应用层 404，判断重点是请求是否进入了应用入口，而不是所有 URL 都必须返回 200。

四、分别申请 SSL，并保留续期通道

1. 每个站点独立申请证书

进入各站点的“SSL”页面，选择 ACME 证书申请方式。首次配置建议使用文件验证，确认 HTTP 可以访问后，再申请 HTTPS 证书。

分别为三个站点申请只包含所需域名的证书。申请前检查：

• 证书中的每个域名均解析到正确服务器。
• TCP 80 可从公网访问。
• 没有错误的 AAAA 记录。
• 验证路径未被鉴权、代理或重写规则拦截。
• 若使用 CDN，验证请求能够正确到达源站。

通配符证书通常需要 DNS 验证；使用 DNS API 时，应限制凭据权限，并保护凭据文件。本文的三个独立站点不需要依赖通配符证书。

2. 验证 HTTPS 后再开启跳转

证书部署后执行：

curl -I https://www.example.com/
curl -I https://shop.example.com/
curl -I https://app.example.com/

此时 app.example.com 尚未配置后端，可暂时返回默认页面，但不应有证书域名不匹配或证书链错误。

DNS 未切换时，可这样验证源站：

curl --resolve www.example.com:443:203.0.113.10 \
  -I https://www.example.com/

--resolve 会保留正确的 HTTPS 域名和 SNI。正式验收不要使用 -k，否则会掩盖证书问题。

HTTPS 正常后，再在面板中开启“强制 HTTPS”：

curl -I http://www.example.com/

预期返回跳转响应，且 Location 指向对应域名的 HTTPS 地址。检查三个站点，避免复制配置后跳到了其他站点。

3. 确认自动续期不会被破坏

保留宝塔生成的证书验证相关 include 或 location，不要为了简化配置删除。尤其在配置全站反向代理时，证书验证路径应仍由本机处理，而不是交给后端应用。

同时确认面板中的自动续期任务已启用，并检查其最近执行状态。首次签发成功，不代表后续续期一定成功；域名解析、80 端口或验证路径变化后都应重新核对。

首次上线不必立即启用长期 HSTS。先完成域名、证书和跳转验收，再根据业务需要设置，避免证书异常时增加浏览器侧回退难度。

五、为应用站点配置反向代理

1. 先让本机后端可用

反向代理的作用是由 Nginx 接收请求，再转发给后端 HTTP 服务。它不会自动启动业务程序。

如果已有应用，先确认其监听在 127.0.0.1:3000：

ss -lntp | grep ':3000'
curl -i http://127.0.0.1:3000/

预期能看到回环地址监听，并获得应用响应。若监听为 0.0.0.0:3000，应优先调整应用绑定地址；不要仅依赖“外部暂时访问不到”判断安全。

没有现成应用时，可用以下临时服务验证代理链路。它仅用于演示，不是生产应用服务器。执行前确认 3000 端口未被使用，且示例目录和服务文件不存在；已有同名资源时应停止操作。

sudo mkdir /srv/a5-demo
sudo mkdir /srv/a5-demo/public
echo 'Backend ready' | sudo tee /srv/a5-demo/public/index.html >/dev/null
sudo chmod 755 /srv/a5-demo /srv/a5-demo/public
sudo chmod 644 /srv/a5-demo/public/index.html

在 /etc/systemd/system/a5-demo.service 新建：

[Unit]
Description=Temporary HTTP backend for reverse proxy verification
After=network.target

[Service]
Type=simple
User=www-data
Group=www-data
ExecStart=/usr/bin/python3 -m http.server 3000 --bind 127.0.0.1 --directory /srv/a5-demo/public
Restart=on-failure
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Ubuntu 22.04 通常提供 www-data 用户，仍应先用 id www-data 核验。启动服务：

sudo systemctl daemon-reload
sudo systemctl enable --now a5-demo.service
curl http://127.0.0.1:3000/

预期输出 Backend ready。示例服务只公开演示目录，不应放入配置、私钥或业务数据。

2. 配置整个域名转发

可以通过宝塔“反向代理”页面设置目标地址 http://127.0.0.1:3000。不同面板版本生成的配置位置可能不同，保存后应检查实际规则。

以下是等价的手工配置，放在 app.example.com 对应的 server 块内：

location / {
    proxy_pass http://127.0.0.1:3000;

    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_connect_timeout 5s;
    proxy_read_timeout 60s;
    proxy_send_timeout 60s;
}

面板生成规则和手工规则选择一种维护方式，不要重复创建 location /。 手工配置时，应保留面板的 SSL、日志、安全限制和证书验证部分，并保证该站点的伪静态文件没有冲突规则。纯代理站点也不需要 PHP 执行处理。

这里的地址头按“浏览器直接连接这台 Nginx”的单层入口设计：覆盖客户端提交的转发地址，避免直接信任其自报 IP。前面还有 CDN 或负载均衡时，需要只信任指定代理地址，并配置真实 IP 处理，不能无条件信任任意来源的请求头。

后端应用还应仅信任来自本机 Nginx 的代理头。否则它可能判断协议错误，产生 HTTPS 重定向循环、错误回调地址或 Cookie 设置异常。

3. 区分路径保留和路径剥离

若只代理 /api/，proxy_pass 是否带结尾斜杠会影响上游路径。

保留 /api/ 前缀：

location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

请求 /api/users，上游收到 /api/users。

剥离 /api/ 前缀：

location /api/ {
    proxy_pass http://127.0.0.1:3000/;
}

请求 /api/users，上游收到 /users。

这是简单前缀匹配场景下的行为。选择哪一种取决于后端路由，不要通过反复添加重写规则补救错误路径。

4. 验证代理结果

语法检查通过后重载：

"$NGINX" -t -c "$MAINCONF" &&
"$NGINX" -s reload -c "$MAINCONF"

再从外部机器访问：

curl -i https://app.example.com/

演示服务应返回 200 和 Backend ready。若本机直连成功、域名访问失败，优先检查 Nginx 配置和日志，不要先扩大后端监听范围。

六、按由外到内的顺序处理异常

1. 域名不通或证书申请失败

先检查 DNS、IPv6、安全组和本机防火墙，再检查 Nginx 是否监听：

ss -lntp | grep -E ':(80|443)\b'

• 没有监听：检查 Nginx 服务和配置测试结果。
• 本机访问正常、外部连接超时：重点检查安全组、防火墙和网络路径。
• 返回了其他站点：检查域名绑定及重复虚拟主机。
• 证书验证失败：检查验证域名、80 端口、验证路径及 CDN 缓存或回源配置。

不要通过关闭所有防火墙来排查。可保留最小规则，并在必要时从第二个网络测试。

2. PHP 路由返回 404 或 502

先确认真实文件 /index.php 能否执行：

curl -i https://shop.example.com/index.php
curl -i https://shop.example.com/article/100

真实入口正常、虚拟路径 404，通常应检查伪静态是否被正确引用、运行目录是否正确，以及应用自身路由。

两者均异常时，再检查 PHP 8.2 服务、PHP 配置引用和文件权限。PHP-FPM 的套接字路径随安装方式变化，应从本机配置和日志确认，不要猜测路径后直接修改。

3. 反向代理返回 502、504 或循环跳转

先检查上游：

curl -i http://127.0.0.1:3000/
systemctl status a5-demo.service --no-pager
journalctl -u a5-demo.service -n 50 --no-pager

后两条仅适用于本文演示服务，生产环境换成真实应用服务名。

• 上游连接失败：检查程序是否运行、监听地址和端口是否一致。
• 上游正常，Nginx 返回 502：检查实际代理地址及错误日志。
• 返回 504：检查应用处理时间、数据库或外部依赖，不要只增加超时。
• 不断跳转 HTTPS：检查后端是否正确识别并信任 X-Forwarded-Proto。
• 代理后路径 404：核对 /api/ 前缀和结尾斜杠处理。

日志路径以站点配置中的 access_log、error_log 为准：

grep -nE 'access_log|error_log' \
  /www/server/panel/vhost/nginx/app.example.com.conf

不要假定所有站点共用同一日志文件。

七、上线验收与回滚检查项

上线验收

• 三个域名分别进入正确站点，没有串站。
• 静态文件正常，缺失文件的响应符合站点设计。
• PHP 真实入口和伪静态路由均按预期工作。
• 三个 HTTPS 域名的证书有效，验证过程未使用 -k。
• HTTP 跳转到对应 HTTPS 域名，没有重定向循环。
• 本机直连上游与外部代理访问均正常，路径处理符合后端路由。
• 后端仅监听回环地址，公网未开放 3000 端口。
• SSL 自动续期任务、验证路径和错误日志已核对。
• 配置备份、代码备份及业务数据备份均可定位。

配置回滚

修改失败时，只恢复本次改动的站点文件和伪静态文件，不要直接覆盖整个共享配置目录。以下示例适用于恢复 shop.example.com，备份路径需替换为实际值：

BACKUP=/root/bt-backup-20260101-120000

cp -a "$BACKUP/vhost/nginx/shop.example.com.conf" \
  /www/server/panel/vhost/nginx/shop.example.com.conf

cp -a "$BACKUP/vhost/rewrite/shop.example.com.conf" \
  /www/server/panel/vhost/rewrite/shop.example.com.conf

"$NGINX" -t -c "$MAINCONF" &&
"$NGINX" -s reload -c "$MAINCONF"

恢复前先保留当前失败配置，便于分析差异。若证书也被替换，需同步核对证书路径、文件权限和有效期，不要把已过期证书恢复上线。

临时后端不再使用时：

sudo systemctl disable --now a5-demo.service

只有确认服务是本次创建、且无需保留时，才删除对应 unit 文件并执行 systemctl daemon-reload；演示目录可先归档，不必立即删除。

回滚后重新检查三个站点，而不只是发生故障的站点。Nginx 共享同一个主进程，一处语法错误可能阻止所有新配置加载；一次成功重载也不等于每个站点的业务逻辑都已恢复。