香港VPS建站教程

一、动手前先把需求和预算问清楚

香港VPS建站的第一步不是点购买按钮，而是把访问者在哪里、页面里有什么、后台要跑多少任务这三件事写成一句话。绝大多数建站失败都源于这一步偷懒——先买了一台配置看起来不错的机器，装好环境才发现目标访客主要在东南亚，而自己为了省事买了带宽只有 1Mbps 的入门套餐；或者装了 4GB 内存的机器，跑了两个 PHP 站点加一个爬虫，内存直接吃满。

延伸对照：数脉科技 的公开机型与线路说明，可结合本节的判断标准自行核对。

配置档位其实只有三档，选哪一档取决于流量形态而不是公司规模。静态展示站、企业官网、活动落地页属于第一档，页面全部命中 CDN 缓存，源站只承接缓存未命中的请求，1 核 1GB 到 2 核 2GB 足够；WordPress、商城、小型会员系统这类动态站属于第二档，页面每次都要跑 PHP 与数据库查询，2 核 4GB 是常用起点；再往上到论坛、商城后端、带队列的 SaaS 才需要第三档，通常从 4 核 8GB 起步并考虑水平扩展。

带宽这一项要单独算，别和 CPU 混在一起看。建站初期流量小的时候，很多商家会直接给 1Mbps 到 10Mbps 的固定带宽，看着数字不大，但对静态站其实够用：一个 200KB 的首页页面，10Mbps 带宽理论上一秒能传 62 个并发首屏，超过这个量才会排队。真正的分水岭是图片和视频：一个首页引用 30 张图、总计 3MB，在 1Mbps 带宽下首屏要 24 秒才能加载完，用户直接关页面。

站点类型	建议 CPU / 内存	带宽思路	主要瓶颈
静态展示、企业官网	1 核 1–2GB	10Mbps 起，图片走 CDN	带宽与图片体积
WordPress、商城	2 核 4GB	20–50Mbps，月流量 1–2TB	PHP 进程数与数据库
论坛、SaaS 后端	4 核 8GB 起	50Mbps 以上，按量核对	数据库与队列积压
带视频/大文件分发	2 核 4GB 即可	不建议自建，走对象存储	出口带宽单价

上表里的配置是按经验估算的通用区间，具体机器的价格、内存、流量数以各商家官网当日报价为准。云途等提供结构化套餐数据的商家，其香港节点公开机型中，入门款为 32GB 内存、480GB 硬盘、1000Mbps 端口、每月 10000GB 流量，标价 350 元人民币每月；更高一档为 64GB 内存、1024GB 硬盘、2000Mbps 端口、每月 40000GB 流量，标价 750 元人民币每月。这些属于带宽与流量都充裕的独享型配置，适合中大型业务；个人建站通常不必按这个量级付费。

预算之外还有三个常被忽略的变量。第一个是续费价，多数商家用首年折扣价吸引开户，第二年恢复原价，这一年的差价要在预算里提前体现，否则容易在第二年因为账单超预期而被迫降配。第二个是超售比例，同样 4 核 8GB 的机器，宿主机上分给的用户数不同，晚高峰的实际可用性能差距可能达到一倍以上，这个只能靠实测确认，没有参数能提前告诉你。第三个是退款政策，年付通常比月付便宜三到五成，但部分商家年付不支持按比例退款，一旦机器不合适只能等到第二年，所以第一次建站建议先月付跑一个月，确认性能和线路符合预期后再转年付。

域名和建站的关系容易被忽略。域名要先买下来才能做解析，而域名是否需要实名、是否被搜索引擎收录、是否要开启 HTTPS 自动签发，这些准备工作最好在建机器之前同步推进。另外，站点如果要做搜索引擎优化，服务器端的响应时间、TTFB、页面结构都会影响抓取频率，香港节点对内地搜索引擎的抓取机相对友好，这是地理上的天然优势。

二、系统和面板怎么选，Debian、Ubuntu还是宝塔

建站系统选型的分歧点集中在「你打算怎么维护它」。Debian 12 与 Ubuntu 24.04 的差别没有宣传里那么大，两者都用 apt 管理软件包，都能用 Nginx 加 PHP-FPM 加 MariaDB 这套经典组合。真正的区别是 Debian 更保守、内核和核心库版本更新节奏慢，适合长期跑着不动的生产机；Ubuntu 的软件源更新更快，PHP 和 Node 相关的新版本基本都能第一时间拿到，适合需要尝鲜或者跑新兴框架的项目。Alpine 基于 musl libc，镜像小、启动快，但 PHP 官方镜像在 Alpine 上的行为偶有差异，国内商家提供的预装面板支持也少，除非你清楚自己在做什么，否则不建议作为第一台生产机。

延伸对照：joysol 的公开机型与线路说明，可结合本节的判断标准自行核对。

面板的价值在于省时间，代价是增加一层不可控。宝塔这类可视化面板把 Nginx、PHP、数据库、FTP、计划任务、证书申请全塞进一个 Web 界面里，第一次建站的人能在十分钟内把环境装好，这是它最大的贡献。但面板自身也是一个需要打补丁、需要登录保护的 Web 应用，而且它会重写 Nginx 配置文件——你手写的 include 规则、限流规则、缓存规则很可能在面板升级或重载时被覆盖。折中做法是：用面板完成初始安装和证书申请，之后所有站点配置都改成手工维护，面板只用来做进程可视化和备份任务。

无论选哪种系统，装完第一件事都应该是把系统更新到最新并装上基础工具，很多面板的初始环境会带着几周前的漏洞。

# Debian / Ubuntu 通用：更新系统并装基础工具
apt update && apt full-upgrade -y
apt install -y curl wget vim git unzip nginx mariadb-server php-fpm php-cli \
    php-mysql php-mbstring php-curl php-xml php-zip chrony

# 设置时区与时间同步，时间不对会让日志和证书校验全乱
timedatectl set-timezone Asia/Shanghai
timedatectl set-ntp true
timedatectl status

# 确认内核与发行版版本，排查问题时要用
uname -a && cat /etc/os-release | head -3

需要提醒的是，PHP 版本直接决定 WordPress 与各类 CMS 的兼容边界。Debian 12 默认带 PHP 8.2，Ubuntu 24.04 默认带 PHP 8.3，两者都能跑主流 CMS 的当前稳定版。装完 PHP 后先确认扩展是否齐全，扩展缺失是最常见的「明明装好了却 502」根因。

# 查看已加载的 PHP 扩展，重点确认 pdo_mysql、mbstring、curl、gd、xml、zip 都在
php -m | sort

# 确认 PHP-FPM 服务名，实际版本号以列表为准
systemctl list-units 'php*-fpm.service' --no-pager
systemctl enable --now nginx mariadb php8.2-fpm

三、第一次SSH登录，先把安全加固做掉

从这一步开始，香港VPS建站就正式进入「暴露在公网上」的状态。默认密码 + 22 端口 + root 直连的组合，在自动化扫描面前几乎等于公开。正确顺序是：先用密码登录一次，把密钥装上并验证能免密登录，确认密钥可用之后再关掉密码登录、关掉 root 直连、改掉端口——顺序反了会把自己关在门外。

延伸对照：恒创科技 的公开机型与线路说明，可结合本节的判断标准自行核对。

密钥登录的建立方式很直接：本地生成一对 ED25519 密钥，把公钥写进服务器的 authorized_keys，然后把私钥妥善保管。私钥一旦泄露，等同于把整台机器交出去，不要放进代码仓库或者聊天工具里来回传。

# 本地生成密钥对，-C 用来标注用途和机器名，便于日后区分
ssh-keygen -t ed25519 -a 100 -C "hk-vps-2026" -f ~/.ssh/hk_vps

# 把公钥推上去（首次仍需输入密码）
ssh-copy-id -i ~/.ssh/hk_vps.pub root@你的服务器IP

# 验证免密登录能通，通了再往下做
ssh -i ~/.ssh/hk_vps root@你的服务器IP 'echo LOGIN_OK'

# 确认服务器主机指纹，避免被中间人替换
ssh-keyscan -p 22 你的服务器IP >> ~/.ssh/known_hosts

改端口本身不提升安全性，但能挡掉大量自动化扫描日志里的暴力尝试，属于成本极低收益明显的一步。真正挡自动化的是密钥登录加防火墙白名单。禁用 root 直连时记得先建好一个普通账号并把它的公钥也写进 authorized_keys，否则会失去登录入口。

# 建普通运维账号并给 sudo 权限
adduser deploy && usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh && chmod 700 /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/ && chmod 600 /home/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

# 生成 SSH 配置片段：改端口 + 禁密码 + 只认特定密钥
cat >> ~/.ssh/config <<'EOF'
Host hk-vps
    HostName 你的服务器IP
    Port 20222
    User deploy
    IdentityFile ~/.ssh/hk_vps
    ServerAliveInterval 60
EOF

# 服务器端修改 sshd 配置前先备份，并保留一个已建立的会话不要关
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?Port.*/Port 20222/' /etc/ssh/sshd_config
sed -i 's/^#\?PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config

# 语法校验通过后再重载，重启会断连
sshd -t && systemctl reload ssh

# 防火墙只放行需要的端口，SSH 端口按你实际改的写
apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 20222/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status numbered

改完 SSH 端口后，务必在另一个终端保持旧会话不断开，用新端口开第二个会话验证能登进去，确认无误再关掉旧会话。这是最常见的翻车方式——配置写错或防火墙没放行新端口，结果把自己的登录入口关死了，只能走商家控制台的 VNC 或重置密码功能找回。

还要加一道针对暴力破解的保险：fail2ban 监控认证失败日志，超过阈值就封禁来源 IP。默认阈值 5 次比较合适，封禁时间 1 小时。要注意云厂商的封禁策略各家不同，有的商家会主动封禁触发阈值的来源 IP，一旦触发可能需要工单解封，所以阈值不要设得太激进，5 到 8 次是一个相对安全的区间。

# 安装 fail2ban 并配置 SSH 防护
apt install -y fail2ban
cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
backend = systemd
port = 20222
EOF
systemctl enable --now fail2ban
fail2ban-client status sshd

最后一件容易被忽略的事是排查端口暴露面。服务器上除了 80、443 和 SSH 端口，其他监听端口都可能是隐患，尤其是数据库端口。数据库应当只监听本地回环地址，或者至少只允许来自应用服务器网段的连接。

# 列出所有正在监听的端口与对应进程
ss -lntup

# 确认数据库没有监听在 0.0.0.0 上
ss -lntp | grep -E 'mysql|mariadb|3306'

# 若确实监听了公网地址，改配置绑定 127.0.0.1
grep -rn 'bind-address' /etc/mysql/ /etc/mysql/mariadb.conf.d/

四、LNMP 环境怎么装，版本和进程数怎么定

Nginx、PHP-FPM、数据库这三件套装完只是起点，真正决定站点稳不稳的是三个参数：PHP-FPM 的最大子进程数、数据库的缓冲池大小、以及 Nginx 的连接数上限。这三个参数如果不按机器内存算，常见的结局是并发一上来就 502，或者内存被吃满触发 OOM 把整台机器干掉。

延伸对照：野草云 的公开机型与线路说明，可结合本节的判断标准自行核对。

PHP-FPM 子进程数的算法很直白：每个子进程常驻内存按 40MB 估算（装了若干扩展的常见 CMS 站点通常在 40MB 到 80MB 之间，这是估算区间，需按自己站点用 ps 实测校正），留给 PHP 的内存上限取物理内存的 60%，再留出 20% 余量应对并发峰值。2GB 内存的机器，留给 PHP 约 1200MB，扣掉余量后按 60MB 每进程算，pm.max_children 取 16 到 20 比较稳。4GB 内存的机器则可以放到 32 到 40。设太高的直接后果是内存耗尽触发 OOM Killer，MySQL 会被系统杀掉，表现为「网站莫名其妙自己恢复了一次」。

Nginx 的 worker_processes auto 会按 CPU 核心数自动设置，配合 worker_connections 决定单机能维持多少并发连接。每个连接在服务端大约占几 KB 内存，1024 核连接数对应大约 50 到 100 个并发请求。

# 备份并写入 PHP-FPM 池配置，路径和版本号以实际安装为准
cp /etc/php/8.2/fpm/pool.d/www.conf /etc/php/8.2/fpm/pool.d/www.conf.bak
cat > /etc/php/8.2/fpm/pool.d/www.conf <<'EOF'
[www]
user = www-data
group = www-data
listen = /run/php/php8.2-fpm.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500
request_terminate_timeout = 60
EOF

# 写入 Nginx 站点配置：HTTPS 由 certbot 后置补充
mkdir -p /var/www/example && chown -R www-data:www-data /var/www/example
cat > /etc/nginx/sites-available/example.conf <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example;
    index index.php index.html;
    client_max_body_size 32m;
    access_log /var/log/nginx/example.access.log;
    error_log  /var/log/nginx/example.error.log;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_read_timeout 60;
    }

    location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg|woff2)$ {
        expires 7d;
        access_log off;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}
EOF

# 启用站点并校验配置，nginx -t 不过就不要 reload
ln -sf /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

站点目录权限是最容易翻车的一环。文件属主必须是运行 PHP 的用户 www-data，目录权限 755、文件权限 644，站点目录上级不能是 777。权限给太宽不会让站点更快，只会让任何拿到上传接口的人都能改你的代码。

装完之后一定要把「访问新站」这件事跑通再往下走。建一个最小测试页，确认 PHP 能解析、数据库能连接、伪静态规则生效，这三件事任何一件不通，后面装 CMS 之后排错会非常痛苦。伪静态是 WordPress、ThinkPHP、Laravel 这类程序的运行前提，配置里少写那段 try_files，首页能开但内页全是 404。

# 最小连通性测试：确认 PHP 解释器、数据库、伪静态三条链路都通
cat > /var/www/example/test.php <<'EOF'
<?php
echo "PHP OK: " . PHP_VERSION . "<br>";
$conn = @new mysqli('127.0.0.1', 'example_app', '密码', 'example');
echo $conn->connect_error ? "DB FAIL: " . $conn->connect_error . "<br>" : "DB OK<br>";
echo "URI rewrite: " . (isset($_SERVER['REQUEST_URI']) ? 'present' : 'missing') . "<br>";
EOF
curl -s http://127.0.0.1/test.php -H 'Host: example.com'

# 伪静态验证：请求一个不存在的路径，应被重写到 index.php 而不是直接 404
curl -s -o /dev/null -w "rewrite_test=%{http_code}\n" \
  http://127.0.0.1/some/deep/path -H 'Host: example.com'

五、域名解析和HTTPS证书怎么配才不出错

域名解析这一步的顺序经常被搞反。正确的做法是：先在域名服务商处把记录的 TTL 调到 300 秒，再把 A 记录指向香港服务器的公网 IP，等解析生效后再申请证书，最后把 TTL 调回 3600 或更长。TTL 调低是为了在需要切服务器时能把生效时间从几小时压到几分钟；证书要在解析生效后再申请，否则 certbot 的 HTTP 校验会因为访问不到新 IP 而失败。

延伸对照：digitalvirt 的公开机型与线路说明，可结合本节的判断标准自行核对。

证书签发有两条路线：HTTP-01 校验和 DNS-01 校验。前者要求 80 端口能正常访问到服务器，对新手最友好；后者需要在 DNS 服务商处加一条 TXT 记录，适合前面挂了 CDN 或者使用了泛域名证书的场景。这两条路线拿到的证书可信度一样，都是浏览器信任的公共 CA 签发，安全性上没有差别。

# 安装 certbot 与 nginx 插件
apt install -y certbot python3-certbot-nginx

# 申请证书，务必把主域名和 www 都写上
certbot --nginx -d example.com -d www.example.com --agree-tos -m you@example.com

# 签发成功后检查续期定时器是否就位
systemctl list-timers | grep certbot
systemctl enable --now certbot.timer

# 干跑一次续期，确认不会因为配置问题失败
certbot renew --dry-run

# 从外部验证证书链是否完整、域名是否匹配
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# 验证 HTTP 是否强制跳转 HTTPS
curl -sI http://example.com | head -5
curl -sI https://example.com | head -5

国内访问香港服务器还有一个绕不开的问题：域名解析本身没问题，但如果访客的 DNS 解析被污染，浏览器会拿到一个错误的 IP。解决办法是让业务方在业务侧配置域名到 IP 的静态映射，或引导访客使用支持加密 DNS 的浏览器和客户端。这一层不在服务器配置范围内，但会明显影响「网站打开很慢」这类反馈，排查时别忘了问一句访客用的什么网络。

还有一件在部署环节就要做完的事：源站信息泄露。很多站点在报错时会直接把 Nginx 版本、PHP 版本、数据库连接错误打印在页面上，这等于告诉扫描器你的具体版本号，方便对方直接匹配已知漏洞。生产环境必须关掉这些信息，Nginx 的 server_tokens off、PHP 的 display_errors Off、Nginx 站点配置里加 fastcgi_hide_header X-Powered-By，这三行是标准动作。

# Nginx 隐藏版本号
sed -i 's/^#\?server_tokens.*/server_tokens off;/' /etc/nginx/nginx.conf
grep -n 'server_tokens' /etc/nginx/nginx.conf

# PHP 关闭错误显示，只写日志
sed -i 's/^display_errors.*/display_errors = Off/' /etc/php/8.2/fpm/php.ini
sed -i 's/^log_errors.*/log_errors = On/' /etc/php/8.2/fpm/php.ini
grep -nE 'display_errors|log_errors' /etc/php/8.2/fpm/php.ini

# Nginx 侧屏蔽 PHP 版本响应头
sed -i '/fastcgi_pass unix:\/run\/php/a\        fastcgi_hide_header X-Powered-By;' \
  /etc/nginx/sites-available/example.conf
nginx -t && systemctl reload nginx

# 验证响应头里不再有版本信息
curl -sI https://example.com/ | grep -iE 'server|x-powered-by'

另外是数据库本身的安全。MariaDB 默认监听 127.0.0.1 是对的，但如果你用面板，它可能会把数据库端口直接暴露到公网，并创建一个允许 root 从任意地址连接的管理账号，这在很多海外机房 IP 段是能被扫到的。正确做法是给应用单独建一个数据库账号，只授予该站点所需的库权限，root 账号只允许本地 socket 登录。

-- 为应用创建独立账号并只授权指定库，密码请用强随机串
CREATE DATABASE IF NOT EXISTS example CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'example_app'@'localhost' IDENTIFIED BY '换成强随机密码';
GRANT SELECT, INSERT, UPDATE, DELETE ON example.* TO 'example_app'@'localhost';
FLUSH PRIVILEGES;

-- 检查所有账号的来源地址与权限，找出不该存在的远程 root
SELECT user, host, plugin FROM mysql.user;

六、站点上线后怎么调优，缓存和压缩别漏

站点跑起来之后，性能问题通常集中在三处：静态资源没压缩、PHP 没有开启 OPcache、数据库没有按机器内存配置。这三项都是配置层面的改动，不需要改业务代码，做完通常能让首屏时间下降一个量级。

延伸对照：hostkvm 的公开机型与线路说明，可结合本节的判断标准自行核对。

Gzip 压缩对 HTML 和 CSS、JS 的效果最明显，文本类资源压缩率普遍在 60% 到 80%，图片和已经压缩过的视频文件不要开。OPcache 把 PHP 脚本的编译结果缓存在共享内存里，省掉每次请求的重新编译，是 PHP 站点性价比最高的一项优化，通常能让响应时间下降三成左右。数据库侧主要是 innodb_buffer_pool_size，它决定 InnoDB 能把多少数据页缓存到内存，默认值在很多 VPS 上偏小，需要按内存手动调。

# Nginx 开启 gzip，在 http 块内添加
cat > /etc/nginx/conf.d/gzip.conf <<'EOF'
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml application/json application/javascript
           application/xml application/xml+rss text/javascript image/svg+xml;
EOF
nginx -t && systemctl reload nginx

# PHP 开启 OPcache，8.2 默认已装扩展，直接改配置
cat > /etc/php/8.2/mods-available/opcache.ini <<'EOF'
[opcache]
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
EOF
systemctl restart php8.2-fpm

# 数据库缓冲池按物理内存 50%~60% 设置，服务器机房型 VPS 通常内存较小
# 修改前先确认当前值与机器实际内存
grep -E 'innodb_buffer_pool_size|innodb_log_file_size|max_connections' \
  /etc/mysql/mariadb.conf.d/50-server.cnf
free -m | head -2

-- 在 MariaDB / MySQL 里确认关键运行状态
SELECT @@innodb_buffer_pool_size / 1024 / 1024 AS buffer_pool_mb,
       @@max_connections,
       @@slow_query_log,
       @@long_query_time;

-- 看当前活跃连接与正在跑的慢查询
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\G

改完之后要复测，不要凭感觉。压测可以用 ab 或 wrk 打自己的站点，但要注意别把刚上线的站点打成 502——压测目标最好指向另一个环境，或者在低峰期做。

前端资源也值得单独优化一轮。对外链的 CSS、JS、字体加 Cache-Control 长缓存并给文件名带上内容哈希，对 HTML 设短缓存或不缓存，这样更新静态资源后用户不会拿到旧版本。这是做搜索引擎优化时很实际的一环：页面首屏时间直接影响抓取预算的使用效率。

# 给静态资源加长缓存，HTML 不缓存
cat > /etc/nginx/conf.d/static-cache.conf <<'EOF'
location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg|woff2|ttf)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;
}
location = /index.html {
    add_header Cache-Control "no-cache, no-store, must-revalidate";
}
EOF
nginx -t && systemctl reload nginx

# 看首屏体积构成，找出真正拖慢速度的资源
curl -s https://example.com/ -o /tmp/page.html
grep -oE '<(img|script|link)[^>]*>' /tmp/page.html | head -20

# 用 wrk 做 30 秒 100 并发的基线测试，记录 RPS 与 P99 延迟
apt install -y wrk
wrk -t4 -c100 -d30s --latency https://example.com/

# 看 Nginx 在压测期间有没有出现 worker 崩溃或 upstream 超时
grep -E 'upstream|timeout|prematurely' /var/log/nginx/example.error.log | tail -20

七、数据库怎么配，为什么一并发就502

502 Bad Gateway 在建站阶段几乎只有一个原因：Nginx 把请求转给了 PHP-FPM，但 PHP-FPM 没接住。常见触发原因有三个，按出现频率排序：PHP-FPM 进程池被占满导致新请求排队直到超时；PHP-FPM 根本没启动或者 socket 路径与 Nginx 配置不一致；站点目录权限不对导致 PHP 无法读取文件而直接退出。

延伸对照：isvoro 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一种最隐蔽，因为它在低并发时完全正常，只有并发上来才出现，而且日志里往往只是「upstream timed out」这类模糊信息。判断方法是直接看进程池状态：配置了 pm.status_path 之后可以访问状态页看到空闲进程数，如果空闲进程长期为 0，说明池子确实不够用。

# 确认 PHP-FPM 运行状态与最近错误
systemctl status php8.2-fpm --no-pager
journalctl -u php8.2-fpm -n 50 --no-pager

# 确认 socket 文件真实存在，且 Nginx 配置里的路径完全一致
ls -l /run/php/
grep -rn 'fastcgi_pass' /etc/nginx/sites-enabled/

# 确认站点文件权限与属主
namei -l /var/www/example/index.php
chown -R www-data:www-data /var/www/example
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;

# 统计 PHP-FPM 实际内存占用，用它反推 max_children 该设多少
ps -eo pid,rss,cmd | grep 'php-fpm: pool' | awk '{printf "%d MB  %s\n", $2/1024, $3}'

权限这一项值得再展开，因为它是新手最常踩的坑，而且症状往往具有迷惑性。常见的情况是：文件权限是对的，但目录的「其他用户」权限位被去掉了，导致 www-data 无法进入该目录；或者目录权限 755 但文件是 644，而 PHP 需要写入某个目录（上传目录、缓存目录、WordPress 的 uploads 目录），写入失败被静默吞掉，表现为「上传图片提示成功但文件不在」。判断方法是用 namei -l 逐级查看路径上每一层的权限位和属主，任何一层断链都会导致失败。

还有一种隐蔽情况是 PHP 的 open_basedir 或 disable_functions 被面板改过。这类限制通常不影响首页显示，但会让后台保存、上传、伪静态重写这些功能悄悄失效，排查时要看 PHP 的错误日志，而不是盯着浏览器。

# 在站点目录下创建一个探针文件，验证 PHP 能否真正执行并访问资源
cat > /var/www/example/health.php <<'EOF'
<?php
header('Content-Type: application/json; charset=utf-8');
echo json_encode([
  'php'    => PHP_VERSION,
  'memory' => ini_get('memory_limit'),
  'upload' => ini_get('upload_max_filesize'),
  'post'   => ini_get('post_max_size'),
  'docroot'=> $_SERVER['DOCUMENT_ROOT'] ?? 'n/a',
  'writable'=> is_writable(__DIR__) ? 'yes' : 'no',
  'disable'=> ini_get('disable_functions'),
], JSON_UNESCAPED_UNICODE);
EOF
chown www-data:www-data /var/www/example/health.php

# 本机请求探针，确认 PHP 链路通
curl -s http://127.0.0.1/health.php -H 'Host: example.com'

# 检查 PHP 错误日志里的真实报错
tail -50 /var/log/php/error.log 2>/dev/null || tail -50 /var/log/nginx/example.error.log

# 打开 PHP-FPM 状态页，之后可以直接看池子水位
cat >> /etc/php/8.2/fpm/pool.d/www.conf <<'EOF'
pm.status_path = /fpm-status
ping.path = /fpm-ping
ping.response = pong
EOF
systemctl restart php8.2-fpm
# Nginx 侧放行状态页，注意只允许本机访问
cat > /etc/nginx/conf.d/fpm-status.conf <<'EOF'
location /fpm-status {
    allow 127.0.0.1; allow ::1; deny all;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
EOF
nginx -t && systemctl reload nginx

504 Gateway Timeout 是另一个概念，它表示 PHP 接收了请求但处理超时。原因通常是单条 SQL 查询太慢，或者代码里有个死循环在等外部资源。定位手段是打开慢查询日志，把超过 2 秒的查询记录下来，再配合 PHP-FPM 的 request_slowlog_timeout 抓出卡住的请求。

# 开启慢查询日志并设置长查询阈值
cat >> /etc/mysql/mariadb.conf.d/50-server.cnf <<'EOF'
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
EOF
systemctl restart mariadb

# PHP-FPM 慢请求日志
cat >> /etc/php/8.2/fpm/pool.d/www.conf <<'EOF'
request_slowlog_timeout = 5
slowlog = /var/log/php/slow.log
EOF
mkdir -p /var/log/php && chown www-data:www-data /var/log/php
systemctl restart php8.2-fpm

# 看慢查询里最耗时的语句
mysqldumpslow -s t -t 20 /var/log/mysql/slow.log

八、备份、监控和日志怎么安排才不后悔

网站上线不等于工作结束，站点数据丢失的绝大多数原因不是黑客，而是「以为备份了」。一份合格备份必须同时满足四条：备份数据不在生产机上、备份位置和生产机不在同一个物理机房、备份是增量的可以快速恢复、并且至少真实恢复过一次。这四条缺一条，备份就只是心理安慰。

延伸对照：tmhhost 的公开机型与线路说明，可结合本节的判断标准自行核对。

数据库用 mysqldump 做每日全量备份是最低成本的方案，配合文件目录的增量备份（rsync 或 restic）就能覆盖大部分站点。关键在于把备份推送到异地——香港服务器往内地推或者往对象存储推是常见做法，但注意别把备份也放在同一台机器的同一块盘上。

# 数据库每日备份脚本，放进 /usr/local/bin/db_backup.sh
cat > /usr/local/bin/db_backup.sh <<'EOF'
#!/bin/bash
set -e
BACKUP_DIR=/data/backup
STAMP=$(date +%F)
mkdir -p $BACKUP_DIR
mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
  -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases | gzip > $BACKUP_DIR/db_$STAMP.sql.gz
# 保留最近 14 天
find $BACKUP_DIR -name 'db_*.sql.gz' -mtime +14 -delete
EOF
chmod +x /usr/local/bin/db_backup.sh

# 文件增量同步到异地，密钥和目标地址按实际填写
cat > /usr/local/bin/file_backup.sh <<'EOF'
#!/bin/bash
set -e
rsync -a --delete --exclude='cache/' --exclude='*.log' \
  /var/www/example/ deploy@backup-host:/data/www/example/
EOF
chmod +x /usr/local/bin/file_backup.sh

# 挂进计划任务，每天 03:17 和 03:47 各一次
cat > /etc/cron.d/site_backup <<'EOF'
17 3 * * * root /usr/local/bin/db_backup.sh >> /var/log/site_backup.log 2>&1
47 3 * * * root /usr/local/bin/file_backup.sh >> /var/log/site_backup.log 2>&1
EOF

监控只要盯住五个指标：CPU、内存、磁盘使用率、磁盘 IO、网站可用性。前三个用系统自带工具就能看，第四个用 iostat，第五个用外部拨测或 Uptime Kuma 这类轻量自建工具。告警渠道建议至少配两条独立路径，比如邮件加一个即时通讯机器人，避免告警发到已经挂掉的邮件服务器上。

# 磁盘使用率与 inode 使用率，两个都要看
df -h && df -i

# 内存与交换分区
free -h && swapon --show

# 磁盘 IO 等待，连续采样看是否堆积
iostat -xz 1 5

# 站点拨测：本机执行，记录响应时间和 HTTP 码
curl -s -o /dev/null -w "code=%{http_code} time=%{time_total}\n" https://example.com/

# 日志轮转，避免日志把磁盘写满
cat > /etc/logrotate.d/site <<'EOF'
/var/log/nginx/*.log /var/log/php/*.log /var/log/mysql/slow.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        [ -f /run/nginx.pid ] && kill -USR1 `cat /run/nginx.pid`
    endscript
}
EOF
logrotate -d /etc/logrotate.d/site

九、常见报错速查表，遇到问题先对号入座

建站阶段的报错大多有固定模式。与其在搜索引擎里反复试关键词，不如先看错误码和错误日志，把问题归到有限的几类里。下面这张表把最常见的一批现象、真实原因和对应处理方式列在一起，排查时从现象反查原因效率最高。

延伸对照：vollcloud 的公开机型与线路说明，可结合本节的判断标准自行核对。

现象	真实原因	定位命令	处理方式
502 Bad Gateway	PHP-FPM 未启动或 socket 路径不一致	systemctl status php8.2-fpm、grep fastcgi_pass /etc/nginx/sites-enabled/	启动服务、统一 socket 路径
502 且并发时才出现	PHP-FPM 进程池耗尽	`ps -eo pid,rss,cmd \	grep 'fpm: pool'`	调 pm.max_children 或升配
504 Gateway Timeout	PHP 处理超时，常见于慢 SQL	mysqldumpslow -s t -t 20 /var/log/mysql/slow.log	开慢查询日志并优化索引
403 Forbidden	目录权限或上级目录不可穿越	namei -l /var/www/example/index.php	目录 755、文件 644、属主 www-data
404 但文件存在	try_files 规则或重写规则缺失	grep -rn try_files /etc/nginx/sites-enabled/	补 try_files 与伪静态规则
413 Entity Too Large	上传体积超过限制	grep client_max_body_size /etc/nginx/nginx.conf	调大 client_max_body_size
证书错误 / 浏览器警告	证书域名不匹配或链不完整	openssl s_client -connect 域名:443 -servername 域名	重新签发含 www 的证书
页面样式全丢	静态资源 404 或路径写错	curl -sI https://example.com/style.css	修正站点 URL 与资源路径
502 且日志报 no live upstreams	Nginx 上游配置语法错误	nginx -t	按报错行修正配置后 reload

排查顺序建议固定下来：先确认服务是否在跑，再确认端口是否在监听，再确认配置语法是否通过，最后才看应用层。这样能排除掉八成的问题，因为服务没起、端口不通、配置报错这三类根本不用碰业务代码。

# 一条链检查：服务状态 → 监听端口 → 配置语法 → 本机访问
systemctl is-active nginx php8.2-fpm mariadb
ss -lntp | grep -E ':80|:443|php'
nginx -t
curl -s -o /dev/null -w "local=%{http_code}\n" -H "Host: example.com" http://127.0.0.1/

# 本机通、外部不通，说明问题在防火墙或云商安全组，不在 Nginx
ufw status verbose
iptables -L -n | head -20

# 外部访问不通时，从另一台机器验证连通性与路径
curl -sI --connect-timeout 10 https://example.com
# 分段探测：先 ICMP 再 TCP，能区分是路由不通还是端口被封
ping -c 4 你的服务器IP
traceroute -T -p 443 你的服务器IP

十、上线验收清单与常见问题

上线前用下面这份清单逐项核对，任何一项不通过都不要对外发链接。清单里的每一条都对应前面章节的某一步，核对本身就是一次完整的复盘。这份清单也适合每次改动系统后重新走一遍，改动越小越要核对，因为小改动引发的大故障是最常见的。

cat << 'EOF'
[ ] 系统已更新到最新补丁，无待处理的安全更新
[ ] SSH 已禁用密码登录与 root 直连，改用密钥 + 普通账号
[ ] 防火墙只放行 80、443 和实际使用的 SSH 端口
[ ] PHP 扩展齐全（pdo_mysql / mbstring / curl / gd / xml / zip）
[ ] PHP-FPM max_children 按内存实测算过，不是照抄默认值
[ ] 站点目录属主为 www-data，权限 755/644，无 777
[ ] Nginx 配置 nginx -t 通过，日志轮转已配置
[ ] HTTPS 证书已签发且包含主域名与 www，续期定时器已启用
[ ] HTTP 已 301 跳转到 HTTPS
[ ] 数据库已开启慢查询日志，慢查询有优化处理记录
[ ] 每日数据库备份 + 文件异地同步已跑通并验证过恢复
[ ] 监控告警覆盖 CPU / 内存 / 磁盘 / 站点可用性，且已测试告警能收到
[ ] 外部拨测从国内网络能正常访问，首屏时间已记录
[ ] 域名备案状态已确认（香港节点无需备案，但要确认是否满足业务方要求）
EOF

香港VPS建站的完整流程包含哪些步骤？ 核心是七步：需求与配置定位、系统选型与基础环境安装、SSH 密钥登录与安全加固、Nginx 加 PHP-FPM 加数据库的 LNMP 部署、域名解析与 HTTPS 证书签发、性能与数据库调优、备份监控与上线验收。每一步都有明确的产出物，验收清单就是把这些产出物固化成可勾选的条目。

第一次建站该选面板还是选纯命令行？ 新手且站点只有一两个、以后不打算接手维护，用面板省时间；打算长期维护或者需要多个站点共用一套环境，用命令行加一份部署脚本。折中做法是用面板完成初始安装与证书申请，之后切到手工维护配置，面板只保留进程管理和备份任务。

香港服务器建站需要备案吗？ 香港节点不走大陆的 ICP 备案流程，上线即用，这是它相对内地服务器最直接的优势。但业务方若有合规要求，比如面向大陆用户提供经营性服务并有牌照要求，仍需自行确认，不要用「香港免备案」代替合规审查。

买机器之前要不要先买域名？ 建议先买域名再买机器，因为域名解析要指向服务器的公网 IP，而 IP 在机器开通后才确定。域名可以在活动价时买，机器可以按月付先验证配置，验证通过再转年付。

香港VPS建站选哪个线路？ 面向内地访客的普通企业站选 BGP 多线或 CN2 GIA 一类回程优化线路即可；面向东南亚访客选香港本地 BGP 就够；如果要做流媒体解锁或对 IP 信誉敏感的业务，要单独确认 IP 类型，不能只看带宽。

配置多少内存够用？ 静态站 1GB 到 2GB，WordPress 类动态站 4GB 是常见起点。判断方法不是看参数，而是建站后用 free -h 和 ps -eo pid,rss,cmd --sort=-rss | head 观察实际占用，再按峰值留 30% 到 50% 余量。

为什么改了配置不生效？ 三种常见原因：改的是模板文件而不是实际加载的配置（面板尤其容易这样）；改完没有重启对应服务；配置文件有语法错误导致服务根本没起来，用 nginx -t 和 systemctl status 一查便知。

服务器能访问外网但网站打不开，怎么排查？ 端口和 DNS 是两个方向。先在服务器本机用 curl -H 'Host: 域名' http://127.0.0.1/ 验证 Web 服务本身是否正常，本机通而外部不通，就去查防火墙、云商安全组和路由；本机也不通，那就是站点配置或应用的问题。

上线后需要做哪些安全加固？ 必做项包括密钥登录、关闭 root 直连、关闭密码登录、防火墙默认拒绝入站、及时打补丁、数据库不对公网暴露、后台管理路径改得不那么明显、定期轮换密钥。前六项半小时内能做完，最后两项要靠制度。