欧洲VPS建站教程

一、欧洲VPS建站第一步应该先确定什么

很多人建欧洲站的第一反应是「先买台机器」，这是顺序错了。 正确顺序是先确定三件事：访客在哪、站点要跑什么、要不要备案。 这三件事定了，机器才好选。

第一件：访客在哪，这决定了机房和线路。 欧洲VPS的机房分布很散，从西班牙、荷兰、德国到英国都有。如果你的访客是西欧本地用户，机器放在法兰克福或阿姆斯特丹和放在英国差别不大； 但如果你的访客是南欧（比如意大利、西班牙）用户，德国的机房到他们那里的路由可能要多绕一跳。 更重要的是：如果你的访客主要在国内，欧洲VPS的地理距离决定了你的首字节时间基本不可能低于 150ms，这是物理限制。 这一点必须在买之前接受，别指望配置再高能解决 18000 公里的光速问题。

第二件：站点要跑什么，这决定了配置。 静态站点和 WordPress 的资源需求差着一个量级：

站点类型	最低配置	建议配置	说明
纯静态站（HTML 加 CSS 加 JS）	1GB 内存 20GB 硬盘	1GB 内存 20GB 硬盘	不需要 PHP 和数据库
WordPress 加 MySQL	2GB 内存 40GB 硬盘	2GB 内存 60GB 硬盘	数据库是内存大户
WooCommerce 电商	2GB 内存 60GB 硬盘	4GB 内存 80GB 硬盘	数据库和 PHP-FPM 都要加
Magento 或 PrestaShop	4GB 内存 80GB 硬盘	8GB 内存 160GB 硬盘	建站过程本身就要吃资源
小型 API 服务	1GB 内存 20GB 硬盘	2GB 内存 40GB 硬盘	看并发不看页面大小

查看 itldc 当前月价与库存

第三件：要不要备案。 如果服务器在中国境外，通常不需要 ICP 备案。 但这不等于没有合规要求——面向欧盟用户的站点要留意 GDPR 相关的 Cookie 声明和隐私政策， 面向国内用户的站点虽然服务器在境外，也可能涉及其他要求。这一条建议单独咨询法务，不要照搬别人的做法。

另外要提前确认支付方式。 很多欧洲VPS商家支持信用卡、PayPal，部分还接受加密货币和支付宝，但并不统一。 国内用户用支付宝或微信付款前，先确认商家支持，否则可能付款失败再退款，耽误时间。

这三个问题定了之后，机型选择就变成一道算术题： 加上第七节的单位成本表和第八节的验收阈值，你在 10 分钟内就能定下机器型号和配置。

二、欧洲VPS应该选哪种线路和机房

欧洲VPS的线路选择比配置选择更重要。 同样的机器，线路不对，配置翻倍也救不回来。

欧洲机房大致分三类，各有各的适用场景。

第一类是国际骨干直连的通用机房。 这类机房走的是常规国际带宽，成本低、覆盖广。代表是 racknerd 这种在全球有 20 个数据中心布局的商家，它提供 KVM VPS、AI VPS、专用服务器和主机托管。 特点是带宽价格便宜、流量额度大，但到中国的线路是普通国际线路，晚高峰时段延迟会有波动。 如果你的站点主要服务欧洲本地用户、或者做的是后台系统而不是面向公众的网站，这类完全够用。

第二类是本地优化线路。 这类面向特定市场的用户做优化，比如 dmit 这类商家专门做中国方向的连接，通过与中国三大运营商的专用互联和 CN2 GIA 这类高级传输服务，解决国内访问延迟高、抖动大、丢包严重的问题。 如果你的站点访客在国内，这类线路的价值远大于升级 CPU。

第三类是带防御能力的机房。 这类针对的是会被攻击的场景，比如 spartanhost 这类主打 DDoS 防护的商家，同时提供 Minecraft 主机、网页主机和 VPS。如果你做的是游戏服、社区站、或者任何容易被人针对的服务，防御是硬需求—— 一条被打瘫的线路，再好的配置也没用。

机房位置的选择，记住一条原则就够了：离访客近。 具体到常见的几个：

机房位置	适合的访客区域	时区	优势
法兰克福（德国）	中欧、德语区	CET	覆盖德奥瑞三国，欧洲骨干枢纽
阿姆斯特丹（荷兰）	西欧、英国	CET	带宽价格低，机房密度高
伦敦（英国）	英国、爱尔兰	GMT	英国本地用户延迟最低
巴黎（法国）	法语区、西欧	CET	覆盖法国比利时
华盛顿（美国）	北美东岸	EST	服务北美用户的低延迟选项
洛杉矶（美国）	北美西岸、中东	PST	覆盖美洲西海岸

查看 iwebfusion 当前月价与库存

这里有一个必须提醒的坑：机房位置选对了，跨大洲仍然会有延迟。 从法兰克福到纽约的物理延迟大约是 80 到 90 毫秒，加上路由，这个数字只会往上走不会往下走。 所以「把机器放欧洲」这个决定本身，就意味着你放弃了面向北美用户的低延迟。 这是一个取舍，不是可以两全的事情。

关于流量套餐的选择，看第一节那张表里的「月流量」列就够了。 欧洲主流 VPS 的流量额度普遍比较宽松，itldc 这类在 20 个全球地点提供 NVMe VDS 和 HD VDS 的商家、profitserver 这类主打 20 多个地点和无限流量的商家，流量通常不是瓶颈。真正要盯的是「超額流量的处理方式」——有的直接限速到很低，有的按量补费。 上线后用 vnstat 之类工具记录实际流量，两周后你就知道该选什么档位了。

三、买多大的配置才不浪费也不够用

这一节给具体数字，避免你凭感觉买。

先看内存。 建站场景里，内存消耗的大头是 PHP-FPM 和数据库。经验值是：一个跑了 5 到 10 个 WordPress 站点的 PHP-FPM 池，稳定占用在 300 到 500MB；MySQL 或 MariaDB 跑几个普通站点，稳定占用在 200 到 400MB；加上系统和 SSH，大约 100 到 150MB。所以：

- 1GB 内存：只够跑静态站，或者一个非常轻的 WordPress 单站，而且要装交换分区。

- 2GB 内存：这是建站的甜点档位。 一个 WordPress 加一个 MySQL 实例，稳得很。

- 4GB 内存：适合电商站或者多个站共用一台。

- 8GB 及以上：大型电商、建站过程本身需要大量资源的情况。

再看磁盘。 一个干净的 WordPress 加上数据库，初始占用在 1 到 2GB。真正吃磁盘的是三样东西：上传的图片、数据库的 binlog、以及日志。 按每个站每月新增 2GB 上传文件估算，一年就是 24GB。磁盘建议至少留三倍余量——因为磁盘写满会直接导致数据库无法写入，而且清磁盘往往要停服务。

最后看 CPU。 建站场景的 CPU 消耗主要来自三个瞬间：装 WordPress 插件、跑数据库导入导出、生成页面缓存。日常访问的 CPU 占用很低。 所以2 核是够的，1 核也能跑但插件安装会慢。

把这些折算成钱。 商品库里可以引用的真实价格来自 sixtynet 的 LAX 系列（年付 200 美元起，折合月价 16.67 美元，2 核 2GB 40GB 硬盘 2000Mbps 带宽 5000GB 流量）和云途的 HK.DS.M（月付 350 元，32GB 内存 480GB 硬盘 1000Mbps 带宽 10000GB 流量）。注意这两台都不是欧洲机房，这里用它们只是演示单位成本算法，具体欧洲机型的价格请以官网当日报价为准。

按第二节到第三节的结论给一个配置建议表：

站点规模	内存	硬盘	CPU	带宽	说明
个人博客或作品集	1GB	20GB	1 核	100Mbps 起	静态生成或极简 WordPress
企业官网或小型博客	2GB	40GB	2 核	100Mbps 起	性价比最高的一档
外贸独立站	2GB	60GB	2 核	100Mbps 起	需给图片预留空间
WooCommerce 电商	4GB	80GB	2 核	200Mbps 起	数据库为主
多个站点共用	4GB	160GB	4 核	200Mbps 起	每多一站加 512MB 内存

查 racknerd 在售套餐与库存

一条经验：先买低一档，跑起来看监控，再决定升不升。 内存升配在多数平台上是热操作，几分钟生效，比一次性买高一档然后长期闲置更划算。

四、装什么系统和环境

系统选择很简单，环境选择有点讲究。

系统层面：选发行版 LTS 版本。 Ubuntu Server 的 LTS 版本（比如 22.04 或 24.04）或者 Debian 的稳定版。理由是 LTS 有五年的安全更新，而非常 LTS 版本只有几个月。 建站服务器对外暴露在公网上，安全更新的周期长度直接影响你的维护成本。

不要选带桌面环境的系统。 图形界面会吃掉几百 MB 内存，而且服务器不需要。选择 minimal 或 server 安装模式。

环境层面的选择，取决于你打算怎么管理：

方式	适合谁	优点	缺点
Docker 加 Docker Compose	会写配置、想保持环境一致	环境可复制，迁移方便	需要学 compose 文件
宝塔等图形面板	不熟悉命令行	装软件、改配置直观	占内存，安全面大
裸装（手动装 Nginx 加 PHP 加数据库）	想完全掌控	资源占用最低，无额外攻击面	每一步都要自己维护

查 spinservers 在售套餐与库存

本文按最省事又不失控的路线走：Docker 加 Compose。 理由是环境可以写进文件里，机器坏了重建只需几分钟，而且容器化之后 PHP 版本的切换、扩展的增删都不需要动系统。

装 Docker 的命令：

# 官方仓库安装脚本，Debian 与 Ubuntu 通用
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# 验证装好了，并确认 Compose 插件可用
sudo docker --version
sudo docker compose version

# 让当前用户不用 sudo 就能用 docker
sudo usermod -aG docker $USER
newgrp docker

注意最后一个步骤：退出 SSH 重连一次才生效，这是最常见的「明明装了却提示权限不足」的原因。

如果不想用 Docker，裸装的路径是这几条：

# 更新系统（Debian/Ubuntu）
sudo apt update && sudo apt upgrade -y

# 装 Nginx 和 PHP 及常用扩展
sudo apt install -y nginx php-fpm php-mysql php-mbstring php-xml php-curl unzip

# 装数据库
sudo apt install -y mariadb-server

# 设置时区（服务器时区是 UTC，排查日志时间对不上时很烦）
sudo timedatectl set-timezone Europe/Berlin

# 设置 hostname
sudo hostnamectl set-hostname your-site

时区这一条一定要做。 默认是 UTC，日志里的时间和你看手机的时间差 8 小时，排查问题时你会怀疑是日志写错了。

五、Nginx 和 PHP 怎么配

这一节给一份可以直接改的 Nginx 配置。 全文假设站点跑在 /var/www/html，PHP 版本用 8.2（Debian 12 自带）。

先建站点目录和配置文件：

# 站点根目录
sudo mkdir -p /var/www/html/your-site/public
sudo chown -R www-data:www-data /var/www/html/your-site

# 配置文件
sudo nano /etc/nginx/sites-available/your-site

Nginx 站点配置的核心内容：

server {
    listen 80;
    listen [::]:80;
    server_name your-domain.com www.your-domain.com;

    # 站点根目录指向 public，这是安全最佳实践
    root /var/www/html/your-site/public;
    index index.php index.html;

    # 限制上传大小，按需调整
    client_max_body_size 64M;

    # 静态资源直接由 Nginx 返回，不进 PHP
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # 静态资源缓存
    location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # PHP 只在真正需要执行时才交给 PHP-FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_read_timeout 300;
    }

    # 禁止访问隐藏文件
    location ~ /\. {
        deny all;
    }
}

这份配置里有四个决定能不能上线成功的地方：

第一，root 指向 public 目录。 WordPress 的代码在上一级目录，只有 public 目录能被 Web 访问。这样即使插件有漏洞，攻击者也拿不到 wp-config.php。 这个习惯要一开始就有，后面改很麻烦。

第二，静态资源走 location 单独匹配，不进 PHP。 每一张图片都过一遍 PHP 解释器，这是很多低配机器慢的主因。

第三，PHP 的 fastcgi_read_timeout 设成 300。 默认值往往是 60 秒，而 WordPress 的后台更新、插件安装、大批量导入都可能超过 60 秒。 表现出来的报错是 502 或 504，很多人查半天找不到原因，其实只是超时。

第四，禁止访问隐藏文件。 .git 目录、.env 文件被访问到等于把源码和密钥交出去。

启用配置并检查语法：

# 软链到启用目录
sudo ln -s /etc/nginx/sites-available/your-site /etc/nginx/sites-enabled/

# 检查语法，写错了这步会报出来
sudo nginx -t

# 重载
sudo systemctl reload nginx

nginx -t 这一步别省。 语法错误会让重载失败，结果是你的站点直接 502。养成改完必先 -t 的习惯。

最后是 PHP 的配置。 建站场景最关键的两个参数：

sudo nano /etc/php/8.2/fpm/conf.d/99-site.ini

; 内存限制：WordPress 插件多的时候 128M 会不够
memory_limit = 256M

; 上传文件大小要和 Nginx 的 client_max_body_size 对齐
upload_max_filesize = 64M
post_max_size = 64M

; 脚本执行时间
max_execution_time = 300

查 cloudcone 在售套餐与库存

这里有个必须记住的坑：upload_max_filesize 和 Nginx 的 client_max_body_size 必须一致或更大。 如果 Nginx 限制 64M 而 PHP 限制 2M，用户上传大文件时会看到一个非常费解的报错——实际是 PHP 拒绝了，而 Nginx 的报错在前面就返回了。

六、数据库怎么配和怎么备份

数据库是建站过程中最容易出岔子的一环。 它既是内存消耗的大户，也是数据最容易丢的地方。

先做安全配置。 默认配置下数据库监听 127.0.0.1 是安全的，但 root 用户用 unix_socket 认证更稳妥。 建站常用的几行配置：

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

[mysqld]
bind-address = 127.0.0.1
max_connections = 100
innodb_buffer_pool_size = 256M
innodb_log_file_size = 64M
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
slow_query_log = 1
long_query_time = 2

innodb_buffer_pool_size 这一项对建站场景特别重要。 它是 MySQL 专门给 InnoDB 表做缓存的内存，默认往往只有 128MB，在 2GB 内存的机器上偏小。 调大它能显著减少磁盘 IO。

然后建库建用户，不要用 root 跑站点。

sudo mysql -u root

-- 建库，字符集要 utf8mb4 否则 emoji 和部分生僻字会存不进去
CREATE DATABASE your_site CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- 建独立用户，限定只能从本机连
CREATE USER 'site_user'@'localhost' IDENTIFIED BY '换成强密码';
GRANT ALL PRIVILEGES ON your_site.* TO 'site_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

这里最容易出事的点是把密码里的特殊字符写进 WordPress 配置文件。 数据库密码里的引号、反斜杠、百分号在 wp-config.php 里需要转义，写错的表现是「数据库连接错误」但错误信息里看不出所以然。 最省事的做法是密码只用字母、数字和几个安全符号，避开引号和反斜杠。

备份是这一节的重点。 WordPress 建站至少要有三条备份线：

备份对象	方式	频率	保留期
数据库	mysqldump 导出并压缩	每天一次	保留 7 份日备加 4 份周备
站点文件	rsync 增量同步到异地	每天一次	保留 14 份
配置文件	打包 wp-config.php 和 Nginx 配置	每次改动后	保留 10 份

digitalocean 官网机型与实时报价

备份命令：

#!/bin/bash
# 每天 03:17 导出数据库
mysqldump -u site_user -p'密码' --single-transaction --quick your_site \
  | gzip > /backup/db-$(date +%F).sql.gz

# 校验文件是否完整（能完整解包且读到结尾即为正常）
gunzip -t /backup/db-$(date +%F).sql.gz && echo "backup ok"

# 同步文件到异地
rsync -az --delete --exclude 'wp-content/cache' \
  /var/www/html/your-site/ backup@backup-server:/backup/your-site/

# 清理超过 7 天的旧备份
find /backup -name 'db-*.sql.gz' -mtime +7 -delete

--single-transaction 这个参数在 InnoDB 上能让备份不锁表。 不加这个参数，备份期间写操作会被阻塞，表现是网站在凌晨三点开始变慢甚至超时。 这是很多「用完就卡」的根源。

再强调一次：备份的价值等于你能恢复出来的时间。 每一季度做一次真实的恢复演练——把备份拉到另一台机器上，把站点跑起来，能打开首页和后台，才算这季度没白过。

还有一件容易被忽略的事：备份要存在不同的机器上。 备份文件和源文件放在同一台机器上，磁盘坏掉的时候两者一起消失，等于没有备份。 异地存放有三种做法，成本递增：第一种是传到另一家 VPS 的对象存储或网盘，成本最低；第二种是用 rsync 同步到另一台你自己的 VPS；第三种是自己搭一套带冗余的备份存储，最贵但最可控。对建站场景，第一种通常就够用——备份文件是加密存储的静态数据，对线路延迟不敏感，只需要一个稳定的地方放着。

备份文件本身也要加密。 备份里往往包含用户数据、订单信息、数据库导出，明文放在另一台机器上等于把风险复制了一份。 加密的现成工具：

# 用 age 加密备份文件（需要先安装 age）
age -r age1yourpublickey -o db-backup.sql.gz.age db-backup.sql.gz

# 解密
age -d -i ~/keys/yourkey.txt db-backup.sql.gz.age > db-backup.sql.gz

最后是备份的验证频率。 建议每月抽一次备份做恢复测试，而不是每次都测——全量恢复耗时较长，月度验证在可靠性和时间成本之间比较平衡。 验证的结果要记录：恢复花了多久、遇到的报错是什么、需要哪些文档才能完成恢复。 这些记录在真正需要恢复的那个星期，能省掉你两三个小时的摸索。

七、域名解析和 HTTPS 证书

这一节是从「机器能访问」到「用户能访问」的关键一步。

域名解析本身很简单，但有两个坑。

坑一：DNS 生效时间。 修改解析记录后，全球解析生效需要时间，通常几分钟到几十分钟，个别解析器会更久。在本地 hosts 文件里加一条记录可以绕过这个问题做测试：

# 测试用，把域名指向服务器真实 IP
echo "你的服务器IP your-domain.com" | sudo tee -a /etc/hosts

改完记得删掉这行，否则以后换 IP 会一直解析到旧地址。

坑二：Cloudflare 这类 CDN 的代理模式会改变源站看到的 IP。 如果你在 Nginx 里用 allow 加 deny 做 IP 白名单，开启代理后所有请求都会来自 CDN 的 IP，白名单会失效。 解决办法是用 CDN 提供的真实访客 IP 请求头。

HTTPS 证书用 Let's Encrypt 免费签发。 Certbot 是最常用的工具：

# 装 Certbot 和 Nginx 插件
sudo apt install -y certbot python3-certbot-nginx

# 签发证书（会自动改 Nginx 配置并设置续期）
sudo certbot --nginx -d your-domain.com -d www.your-domain.com

# 测试自动续期是否正常
sudo certbot renew --dry-run

--dry-run 这一步一定要做。 Certbot 默认用 systemd timer 每天检查一次续期，但如果防火墙挡住了 80 端口、或者 DNS 没配好，续期会静默失败，然后某天你的站突然全站 HTTPS 报错。 --dry-run 能提前暴露这个问题。

关于证书自动续期后的生效，Nginx 需要 reload 才加载新证书：

# 测试续期后自动 reload 的钩子
sudo certbot renew --deploy-hook "systemctl reload nginx" --dry-run

还有一个免费方案值得知道：DNS-01 验证。 它不需要 80 端口开放，直接在 DNS 服务商那边验证，适合用了 CDN 或者服务器在防火墙后面的情况。 Certbot 支持通过插件实现，但需要各自服务商的 API 凭据。

查 hostwinds 在售套餐与库存

续期和有效期这一块，第八节的验收表里有一条「证书剩余天数大于 30 天」，记得配一个监控。 证书过期是最典型的「无声故障」——没有流量异常，只是某天开始全站报错。

八、上线前的验收标准和常见报错

这一节给你一份可以逐条打勾的验收清单，以及遇到报错时的排查路径。

上线前必须全部通过的七项验收：

验收项	操作	合格标准
首页可访问	外部网络访问域名	返回 200，页面完整渲染
HTTPS 正常	浏览器访问	锁形图标正常，无证书警告
HTTP 自动跳转 HTTPS	访问 http 域名	301 跳转到 https
PHP 可执行	放一个 phpinfo 测试页	正常输出后立刻删除
数据库连接	看站点后台是否报错	无数据库错误提示
首字节时间	连续请求 20 次取中位数	小于 300ms
1MB 下载耗时	连续下载 20 次取中位数	小于 2s
内存占用	连续 24 小时记录谷值	不高于 15%
备份任务	手动跑一次备份脚本	备份文件生成且能完整解包

查看 interserver 当前月价与库存

下面按「报错现象」组织排查路径，这比按「组件」组织更好用。

现象一：访问站点返回 502 Bad Gateway。 这是 Nginx 起来了但后端没起来。 按顺序查：

# 看 PHP-FPM 是否在跑
sudo systemctl status php8.2-fpm

# 看 Nginx 错误日志最后 50 行，这里会写明是连接被拒绝还是超时
sudo tail -50 /var/log/nginx/error.log

如果日志里是 connect() failed (111: Connection refused) while connecting to upstream，说明 PHP-FPM 没运行或者 socket 路径写错了。 检查 Nginx 配置里的 fastcgi_pass 路径和 PHP-FPM 实际生成的 socket 路径是否一致：

# 看实际的 socket 文件在哪
sudo ls -l /run/php/

现象二：访问站点返回 404，但文件明明在。 八成是 root 路径写错，或者 WordPress 的站点根目录设置和实际目录对不上。 确认两点：Nginx 配置里的 root 路径，以及 WordPress 设置里「WordPress 地址」和「站点地址」是否与实际域名一致。 WordPress 里如果填的是 IP 后来换了域名，这两个值不改会导致 404 或者无限跳转。

现象三：页面能打开，但样式全乱。 这是静态资源 404。 通常是 root 指向了错误层级——如果 WordPress 装在 /var/www/html/your-site 而不是它的 public 子目录，Nginx 找不到 wp-content 目录下的 CSS 和 JS。 验证方法：

# 直接访问一个样式文件，看是否 200
curl -I https://your-domain.com/wp-content/themes/你的主题/style.css

现象四：上传图片提示 413 Request Entity Too Large。 这是 Nginx 限制，不是 PHP 限制。 改 client_max_body_size，然后 sudo nginx -t && sudo systemctl reload nginx。注意只改 PHP 的 upload_max_filesize 不管用，Nginx 会先拦下来。

现象五：安装 WordPress 时提示「数据库连接错误」。 按可能性排序： 密码里有特殊字符导致转义错误、数据库名或用户名拼错、用户没有该库的权限、或者 MySQL 服务根本没启动。最后一条最容易被忽略，因为报错信息完全一样。逐项验证：

# 服务在不在
sudo systemctl status mariadb

# 用配置里的账号密码手工连一次，能连上说明配置没问题
mysql -u site_user -p'密码' your_site -e "SELECT 1;"

现象六：502 或 504 出现在后台更新插件时。 这是超时，不是错误。 第三节提到的 fastcgi_read_timeout 300 就是为这个准备的。改完 reload 即可。

现象七：站点偶发变慢，几分钟后恢复。 大概率是某个 cron 任务或者自动更新在跑。 查：

# 看定时任务
sudo crontab -l
sudo ls -la /etc/cron.d/

# 看慢查询日志（需提前开启 slow_query_log）
sudo tail -50 /var/log/mysql/mysql-slow.log

排查完记得清理临时文件。 PHP 测试页、备份脚本里的明文密码、调试用的日志文件，这些东西留在服务器上就是隐患。

还有一个排查顺序上的建议：先看错误日志，再改配置。 很多人一遇到 502 就去改 Nginx 配置，或者一遇到 500 就去改 PHP 配置，但真正的原因往往在日志里写着一行字。 养成这个顺序能省掉大量无效操作：

# 一条命令看完所有关键日志的最后 30 行
sudo tail -30 /var/log/nginx/error.log /var/log/php8.2-fpm.log /var/log/syslog

关于 500 错误的额外说明。 500 是 PHP 执行时致命错误导致的，Nginx 只知道「后端返回了 500」，不知道具体原因。 排查要往 PHP 这边走：

# PHP-FPM 的错误日志
sudo tail -50 /var/log/php8.2-fpm.log

# WordPress 调试模式（临时开启，查完务必关掉）
sudo nano /var/www/html/your-site/wp-config.php

// 临时打开调试，排查完一定要改回 false
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG_DISPLAY 设为 false 是关键。 开着调试模式时 PHP 的报错会直接输出到网页上，访客能看到你的绝对路径、数据库错误细节、甚至 PHP 版本。 排查时用日志文件（WP_DEBUG_LOG），不要用屏幕显示。

最后是日志轮转。 建站服务器的磁盘被日志写满是最常见的运维事故之一，而且它的表现很突然——某天早上你的站点突然打不开了，报错是磁盘空间不足。Nginx 和 PHP 的日志默认都有轮转配置，但如果你自己写了调试脚本或者在站点目录里放了日志文件，这些不会自动轮转。 一定要检查：

# 看磁盘和日志目录占用
df -h
sudo du -sh /var/log/* 2>/dev/null | sort -h | tail -10

# 确认 logrotate 配置在
ls -la /etc/logrotate.d/

九、建站过程中最常见的五个坑

这一节不讲技术，讲那些「按教程做也会错」的地方。

第一个坑：把服务器密码写在命令行里。 mysql -u root -p密码 这种写法会把密码留在服务器的 shell 历史记录里，history 就能看到，而且会出现在进程列表里，任何用户都能通过 /proc 看到。 正确做法是用配置文件：

# 在用户家目录建一个仅自己可读的配置文件
cat > ~/.my.cnf << 'EOF'
[client]
user=site_user
password=你的密码
host=127.0.0.1
EOF
chmod 600 ~/.my.cnf

# 之后直接连，不用带密码
mysql your_site

第二个坑：站点目录权限给成 777。 这是最常见的、也是后果最严重的错误。 777 意味着任何进程都能改你的站点文件，如果站点有上传功能或者任何文件写入口，等于把改站权限公开。 正确做法：

# 目录 755，文件 644，归属 www-data
sudo find /var/www/html/your-site -type d -exec chmod 755 {} \;
sudo find /var/www/html/your-site -type f -exec chmod 644 {} \;
sudo chown -R www-data:www-data /var/www/html/your-site

第三个坑：不做备份就开始改配置。 改 Nginx 配置、改数据库、改 WordPress 核心文件之前，先各做一份快照。 修改 Nginx 前：

# 先备份配置，再改，改完立刻检查语法
sudo cp /etc/nginx/sites-available/your-site /etc/nginx/sites-available/your-site.bak

第四个坑：一次装一堆插件。 插件装多了会同时拖慢三样东西：PHP 内存占用、页面加载时间、以及安全面。 一个 WordPress 站点建议控制在 15 个插件以内，并且每装一个都观察一下后台的响应速度。 如果某个插件让内存占用明显上升，大概率就是它。

第五个坑：服务器是建站工具，不是永久方案。 很多人在一台机器上装了网站、数据库、邮件服务、监控、VPN、节点等等，最后这台机器同时承担了五六个角色。 后果是任何一个角色出问题都会互相影响，而且出问题时你分不清是谁的锅。

建站的标准做法是：一个角色一台机器，或者至少按角色把服务隔离。 至少在搭建阶段就把它们分开，等以后要扩容的时候，你不用做「在跑着的生产环境上做大调整」这种高风险操作。

最后一个小坑值得单独说：时区和文件权限之外，别忘了给服务器设一个强密码并禁用密码登录。

# 生成密钥对，在自己的电脑上执行
ssh-keygen -t ed25519

# 把公钥传到服务器（把 user@ip 换成实际值）
ssh-copy-id user@your-server-ip

# 然后在服务器上关闭密码登录
sudo nano /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no

# 改完重载 SSH（别退出当前会话，先开新窗口测试能不能登录）
sudo systemctl reload sshd

zenlayer 官网机型与实时报价

「改完先开新窗口测试」这一步别跳过。 如果配置写错导致 SSH 起不来，而你已经退出了当前会话，那你就彻底失去这台机器的访问权了，只能找商家重装。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 itldc 当前机型与价格
做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 iwebfusion 当前机型与价格
主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 racknerd 当前机型与价格
跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 spinservers 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、欧洲建站怎么选商家、怎么走完最后一步

最后一节把商家选择和上线流程收尾。

选商家时看五个可核对的点，不要看广告语。

第一，看数据中心位置和数量。 公开信息可核对：racknerd 公开介绍是全球 20 个数据中心，含 KVM VPS、AI VPS、专用服务器、网页主机和主机托管；itldc 公开介绍是在 20 个全球地点提供 NVMe VDS、HD VDS 和专用服务器；profitserver 公开介绍是超过 20 个地点的 VPS、无限流量、几步点击即可部署。 这些是可验证的事实，比「全球线路、极速访问」这种描述有用得多。

第二，看虚拟化技术和硬件。 KVM 加上 NVMe SSD 是建站体验的分水岭。 KVM 相比 OpenVZ 这类容器型虚拟化，有独立的内核和完整的 root 环境，可以改内核参数、装内核模块；NVMe 相比 SATA 在随机读写上有数量级的差距，这直接影响数据库的响应速度。 liteserver 公开介绍就是以 NVMe SSD 硬件的 VPS 为特色。

第三，看流量与带宽的套餐结构。 注意区分「带宽大但流量小」和「带宽流量都大」这两种完全不同的类型。 前者适合短时大文件传输和备份回源，后者适合持续的网页服务。建站属于后者。

第四，看是否支持按月付。 这一点对新站极其重要——你还没验证这个站点能不能做起来，就不该被年付锁死。 同时要确认退款政策：新开的前几天能不能退、什么条件下退。

第五，看支付方式和支持渠道。 确认支持你习惯的付款方式和沟通语言，并确认有工单系统而不是只有邮件。

再说走完最后一步。 上线的顺序应该是这个顺序，每一步都验证了再进行下一步：

步骤	操作	验证方式
1	解析域名到服务器	ping 通，hosts 里加记录测试
2	部署 Nginx 和 PHP	本机 curl 返回 200
3	安装数据库并建库建用户	用站点账号手工连一次成功
4	上传 WordPress 并配置	访问安装向导能走完
5	配置站点内容	后台能正常登录和编辑
6	签发证书并强制跳转	浏览器无警告，http 能跳转
7	删除测试文件和默认页面	访问 /phpinfo.php 返回 404
8	配置自动备份	手动跑一次，确认文件生成
9	配置监控和告警	触发一次测试告警能收到
10	关闭密码登录并做外部扫描	新窗口能登录，端口无多余暴露

查 justg 在售套餐与库存

第七步「删除测试文件和默认页面」经常被跳过，但这一步很重要。 默认的 Nginx 欢迎页会泄露你的服务器用的是 Nginx；phpinfo.php 页面会暴露你的 PHP 版本、已安装扩展、服务器路径和所有环境变量。 删除命令：

# 删测试页和默认页
sudo rm -f /var/www/html/your-site/public/phpinfo.php
sudo rm -f /usr/share/nginx/html/index.html

最后一步的上线后 24 小时是黄金观察期。 盯着这几个数： CPU 占用（有没有持续高位）、内存使用（有没有单向上涨）、访问日志（有没有异常来源 IP 或异常高频请求）、以及邮件是否正常发出。很多建站问题不是上线时暴露的，而是上线后第一天的某个时段才暴露。

把第八节那张验收表打印出来，逐条打勾签字。 这比任何教程都管用——因为它把「建好了」这个模糊的感觉，变成了十个可以确认的事实。

飞翔声明：飞翔网登载此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。