日本VPS搭建WordPress教程

一、开始之前：WordPress 到底吃多少资源

在决定买哪台机器之前，先把 WordPress 的真实资源开销摸清楚。网上流传的「WordPress 很吃资源」是一句被过度简化的话——准确的说法是：默认安装、默认插件、默认主题的 WordPress，在 1 GB 内存机器上会稳定地触发 OOM；在 2 GB 内存机器上能跑，但插件一多就会开始抖动；到 4 GB 内存，问题基本消失。

先说清楚构成。 一个 WordPress 站点的常驻内存主要由四块组成：

- PHP-FPM 进程池本身。 每个 worker 进程空闲时占用 30 到 50 MB 内存，实际处理请求时峰值会到 80 到 150 MB。这是最容易被忽略的一块——很多人以为 WordPress 占内存是数据库的锅，其实 PHP 进程池才是大头。

- MySQL/MariaDB。 空载大约 120 到 180 MB，加上 InnoDB buffer pool（按内存的 50% 到 70% 配）后，稳定占用通常在 400 到 700 MB。

- WordPress 自身。 PHP 进程加载 WordPress 核心与已激活插件的代码，每个请求的额外内存增量大约 2 MB 到 8 MB，取决于插件数量与主题复杂度。

- OPcache。 这块是节省内存的关键，配置得当能减少约 30% 的 PHP 内存占用。

把这四块加起来，就得到了本文的选型结论：

站点规模	PHP-FPM 进程数	内存需求	硬盘需求	现实结论
个人博客，10 篇文章以内	4	1 GB 会 OOM，2 GB 够用	20 GB 起步	静态化是最优解，否则上 2 GB
内容站，50 到 200 篇文章	10	2 GB 勉强，4 GB 舒服	40 到 80 GB	4 GB 是当前实际起点
会员站，带 WooCommerce	20	4 GB 起步，8 GB 舒服	80 GB 以上	必须独立数据库
站群 / 多站点	每站独立进程池	每站 2 GB 起	需求另算	隔离优先于合并

zenlayer 官网机型与实时报价

再给一个「够不够用」的量化标准。 WordPress 的内存消耗和内容量弱相关，和插件数量强相关。一篇文章带来的只是数据库里多几行记录，内存增量接近零；但一个插件可能带来 5 到 20 MB 常驻内存。所以「我有一万篇文章所以要升级」的判断是错的，「我装了四十个插件所以要升级」才是对的。

硬件这一层的判断在渠道库里可以直接算。 真实价格数据显示：

机型	折合月价	内存	硬盘	月流量	每 GB 内存	每 TB 流量
RosCloud-01	19.99 美元	1 GB	20 GB	1024 GB	19.99 美元	19.99 美元
RosCloud-03	39.99 美元	4 GB	80 GB	3072 GB	10.0 美元	13.33 美元
RosCloud-04	49.99 美元	8 GB	160 GB	4096 GB	6.25 美元	12.498 美元
RosCloud-05	59.99 美元	16 GB	240 GB	5120 GB	3.75 美元	11.998 美元
LAX-STARTER	16.67 美元	2 GB	40 GB	5000 GB	8.33 美元	3.413 美元
LAX-MICRO	33.33 美元	4 GB	80 GB	10000 GB	8.33 美元	3.413 美元
LAX-MEDIUM	66.67 美元	8 GB	160 GB	20000 GB	8.33 美元	3.413 美元
云途 HK.DS.M	350 美元	32 GB	480 GB	10000 GB	10.94 美元	35.84 美元
云途 HK.DS.P	750 美元	64 GB	1024 GB	40000 GB	11.72 美元	19.2 美元

从这张表能读出两个直接可用的结论。

结论一：每 GB 内存的单价随规格放大而下降，这是「买大不买小」的量化依据。 RosCloud 从 1 GB 的 19.99 美元/GB 降到 16 GB 的 3.75 美元/GB，降幅 81%。但升配的理由必须是「用得上」，不是「更划算」——按单位成本升配，用不上的部分就是纯浪费。

结论二：流量单价在跨节点时差异巨大，这直接影响「日本节点该买多少流量」。 美西 LAX 系列三个档位的每 TB 流量统一是 3.413 美元（年付 200 / 400 / 800 美元折合月价 16.67 / 33.33 / 66.67 美元），香港云途是 19.2 到 35.84 美元。日本的流量单价在本渠道库里没有独立机型数据可引用，实际以官网当日报价为准；但香港这个 5 到 10 倍的价差可以作为参照，判断日本节点大概率落在美西与香港之间。

这一节的落点是：WordPress 站的起步配置是 2 GB 内存 / 40 GB 硬盘 / 1 TB 流量；认真做内容运营的站，4 GB / 80 GB / 2 TB 是更稳妥的起点。

二、服务器配置和机房怎么定

配置定下来之后，第二步是定机房。这一步的判断依据是访客分布，而不是「哪个节点听起来高级」。

日本节点在地理位置上的特点是：离国内近，比美西近一个数量级，同时比香港多一个数量级的物理容量。 渠道库里 justg 的公开简介就明确写着「JUSTG cloud VPS in Tokyo, Seoul and Moscow from $19.99/mo with native IPv4」——东京、首尔、莫斯科三个节点，最低价 19.99 美元/月，与渠道库里 RosCloud-01 的 19.99 美元/月完全一致。这个数字值得记下来：它是渠道库里公开可查的日本/东亚节点入门价的参照。

三种典型的机房选择，各自的判断依据如下：

面向国内访客的站：优先日本或香港。 国内到日本的物理距离决定了首字节时间的下限区间，通常在 30 到 90 毫秒之间；国内到美西则在 150 到 300 毫秒。这个差距不是配置能弥补的，是光程决定的。

面向东北亚（韩国、日本、港澳台）访客的站：日本是天然的选择。 渠道库里的 vpckr 公开简介写着「Premium Korean Cloud Infrastructure — Ultra-low latency VPS, AI Agent Servers, Korea Native IP」，把「超低延迟」和「韩国原生 IP」作为核心卖点，这从侧面说明在东北亚区域，机房位置和 IP 属性是分开定价的两件事。

面向海外访客的站：日本不是最优解。 从北美到日本，往返 RTT 通常在 250 毫秒以上，而美西可以做到 30 到 60 毫秒。此时的正确做法是选美西，或者做双节点部署。

接下来是配置。 按本文第一节的资源模型，配置选择规则很直接：

- 2 GB 内存 / 2 核 / 40 GB 硬盘：个人博客、企业官网、不装电商的展示站。这是起步档。

- 4 GB 内存 / 4 核 / 80 GB 硬盘：内容站、会员站、装 WooCommerce 的最低要求。这是推荐档。

- 8 GB 内存 / 4 到 8 核 / 160 GB 硬盘：带论坛、评论系统、较多插件的中型站。这是舒适档。

带宽和流量的配置有个容易踩的坑：带宽和流量是两笔不同的账。 渠道库里的香港机型带宽标称 1000 到 2000 Mbps、月流量 10000 到 40000 GB；美西 LAX 系列带宽标称 2000 到 10000 Mbps、月流量 5000 到 40000 GB。带宽决定「单个用户能下多快」，流量决定「所有用户加起来能下多少」。 一个图片站可能带宽只用到 50 Mbps 就够，但一个下载站 1 TB 流量几天就烧完了。

按访客量反推流量，公式是这样的：

月流量 ≈ 日均 PV × 页面平均大小（含所有资源）× 30

举个实际的例子：一个页面平均 2.5 MB（含 CSS、JS、图片），日均 3000 PV，那么月流量约等于 3000 × 2.5 MB × 30 = 225 GB。留 50% 余量，约 340 GB。 选套餐时，往上取一档。

如果算出来超过套餐流量的 70%，就必须加 CDN 或者升配。 原因是：VPS 的流量额度用尽后通常会被限速或按额外单价计费（渠道库里云途系列有独立的超额流量重置价字段，HK.DS.M 是 200 美元、DS.ES 系列是 500 美元），这类费用往往比一开始买大一点的规格更贵。

查 justg 在售套餐与库存

最后一条配置建议：优先选 SSD 或 NVMe。 渠道库里 LAX 系列的 disk_type 字段明确标注「NVMe SSD」，云途 HK.DS.M、HK.DS.P、DS.ES 系列标注「SSD」，而 HK.DS.S 标注的是「SAS HDD」。数据库随机写和依赖安装是 WordPress 部署里最耗 IO 的两个环节，在机械盘上会慢出一个量级。 这也解释了为什么 HK.DS.S 虽然每 GB 内存只要 6.25 美元（是云途系列里最低的），但如果你要做 WordPress 站点，6000 GB 的 SAS HDD 并不是优势，而是妥协。

三、PHP 版本和扩展怎么选

PHP 版本是 WordPress 部署里最容易出兼容问题、也最容易被新手跳过的一环。

当前的主流选择是 PHP 8.1 和 8.3。 选择规则有三条：

规则一：新站一律用 8.3，老站优先留在 8.1。 PHP 8.2 引入了一些弃用变更，8.3 增加了类型相关的性能改进。但如果你的站点里有插件还在调用 8.2 弃用的函数，升上去会直接报致命错误。 所以：新站 8.3，老站升之前先在本地或预发环境跑一遍插件兼容性检查。

规则二：不要用 8.4 装生产站。 8.4 相对新，WordPress 核心和主流插件的兼容验证还不充分。生产环境出问题的排查成本远高于省下的那点性能差异。

规则三：PHP 8.0 及以下已经不适合新站。 8.0 已停止安全维护，遇到安全问题时不会再有补丁。

WordPress 需要的扩展清单，以及每一个的作用：

扩展	作用	是否必需	缺失后的表现
mysqli 或 pdo_mysql	连接数据库	必需	安装向导无法连接数据库
mbstring	多字节字符串处理	必需	中文标题、摘要截断异常
curl	发起 HTTP 请求	强烈建议	无法调用外部 API、更新检查失败
gd 或 imagick	图片处理	建议	缩略图生成失败
exif	读取 EXIF	建议	图片方向信息丢失
intl	国际化	建议	日期格式与翻译不完整
opcache	字节码缓存	强烈建议	性能下降 30% 左右
zip	解压	建议	插件与主题安装失败
sodium 或 openssl	加密	建议	某些插件报常量未定义

查看 zgovps 当前月价与库存

装完扩展后的验证命令：

php -m
php -v
php -r 'echo PHP_VERSION, PHP_EOL;'

PHP-FPM 的进程数怎么算。 这是决定「网站能不能扛住并发」的核心参数。经验公式是：

PHP-FPM 进程数 ≈ (可用内存 ÷ 单进程峰值内存) × 70%

代入实际场景：如果机器有 4 GB 内存，MySQL 占 1 GB，系统和其他占 0.5 GB，可用给 PHP 的是 2.5 GB；单进程峰值按 100 MB 算，2.5 GB ÷ 100 MB = 25，× 70% ≈ 17 个进程。 所以 4 GB 机器配 10 到 15 个 worker 是安全区间。

改完这些参数后，一定要重启 PHP-FPM 并观察实际内存。 如果 free -m 显示内存迅速逼近上限，说明进程数给多了。判断标准是：内存谷值（空闲时的最低使用量）应低于总内存的 15%。 这也是本文第四节给出的验收阈值之一。

四、安装前必须先做的四件事

在点安装向导之前，有四件事必须先做完。这四件事的价值不在于「步骤正确」，而在于它们能挡掉八成以上的线上故障。

第一件：更新系统并装好基础依赖。

apt update && apt upgrade -y
apt install -y nginx mariadb-server php-fpm php-cli php-mysql php-mbstring php-curl php-gd php-zip php-intl

第二件：配置 PHP 内存和 OPcache。 修改 /etc/php/8.3/fpm/php.ini：

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 60

OPcache 配置（写在 php.ini 或独立的 opcache.ini 里）：

opcache.enable = 1
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.revalidate_freq = 2
opcache.save_comments = 1

为什么 OPcache 值得专门配？ 它把 PHP 源码编译成字节码缓存在共享内存里，避免每个请求重复编译。实测效果是内存占用降低约 30%、CPU 使用率下降明显。 对 2 GB 这类紧张配置的机器，这一条能直接决定站点能不能扛住。

第三件：改掉默认配置里三个必须改的地方。

- MySQL 的 bind-address：从 127.0.0.1 改成 0.0.0.0，但同时用防火墙把 3306 只放行给本机，否则数据库会暴露在公网上。

- WordPress 的默认管理员用户名：安装时不要用 admin，改成邮箱或自定义名。

- SSH 密钥登录：关掉密码登录，用 PermitRootLogin no 和 PasswordAuthentication no。

第四件：建一个简单的健康检查脚本。 这一步经常被跳过，但它在故障时的价值最大：

cat > /usr/local/bin/healthcheck.sh << 'EOF'
#!/bin/bash
MEM=$(free -m | awk '/Mem:/ {print $3}')
TOTAL=$(free -m | awk '/Mem:/ {print $2}')
DISK=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%')
LOAD=$(cat /proc/loadavg | awk '{print $1}')
echo "mem_used=${MEM}MB mem_total=${TOTAL}MB mem_pct=$((MEM*100/TOTAL)) disk_pct=${DISK} load=${LOAD}"
EOF
chmod +x /usr/local/bin/healthcheck.sh

跑一次你就能得到本文第四节所有验收阈值需要的数据源。 建议加进 crontab，每 5 分钟采集一次：

查看 景文互联 当前月价与库存

*/5 * * * * /usr/local/bin/healthcheck.sh >> /var/log/healthcheck.log 2>&1

五、插件和主题怎么控制

插件是 WordPress 内存和性能问题的第一来源。这一节给出可执行的控制办法。

第一条硬规则：把插件数量控制在 20 个以内。 这不是玄学，是有依据的：每个激活插件会加载自己的 PHP 文件、注册自己的钩子、可能自己开一个 cron 任务和一张数据表。20 个插件是一个经验上的安全线，超过之后排查性能问题会变得非常困难。

第二条：把功能从插件改成 WordPress 核心能力。 这是最省资源的一步：

常见需求	插件做法	更省资源的做法
站点地图	SEO 插件生成	核心自带 wp-sitemap.xml
文章缓存	缓存插件	Nginx 层做缓存
定时备份	备份插件	系统的 crontab 脚本
表单提交	表单插件	用 REST API 或第三方表单服务
图片优化	图片压缩插件	服务端预压缩 + WebP

查看 backwaves 当前月价与库存

第三条：只在确实需要的功能上用插件，并且用完就停用。 很多插件装上之后就没再用过，但它们一直在加载代码。用 wp plugin list --status=active 列一遍，把三个月没点开的插件停用或删除。

第四条：主题选择只看三件事。 主题的差别主要在于打包了多少东西：

- 是否用 wp_head() 输出多余资源。 很多老主题会加载十几种字体和图标字体，一个页面几十个请求。

- 是否内置了页面构建器。 Elementor、WPBakery 这类构建器会让单页 HTML 膨胀到几百 KB，同时编辑一份内容会存多份副本到 postmeta 表。

- 主题更新后的 PHP 报错。 一个主题引入的 PHP 8.x 兼容问题会让整个前台白屏。

第五条：用下面的命令找出真正在吃资源的插件。 逐个停用插件并观察内存，是唯一可靠的方法：

wp plugin list --status=active --format=table
wp plugin deactivate 插件名
wp cache flush

装插件时优先选「已在 WordPress.org 仓库上架、近期有更新」的。 这不是说要大厂插件，而是说仓库里的插件有版本历史、有公开的问题追踪，出问题时能查到解决办法。

六、缓存和数据库怎么优化

WordPress 是动态站点，同一个页面每次请求都要跑 PHP、查数据库、拼 HTML。缓存是提升性能最有效、也最省资源的一招——因为命中缓存时，PHP 和数据库根本不参与，内存占用和 CPU 占用同时降到接近零。

缓存分两层。

第一层是页面缓存（对象缓存的上游）。 把整个渲染好的 HTML 存起来，下次直接返回。做法有两种：

用 Nginx 的 fastcgi 缓存（推荐，省内存）：

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=wp_cache:50m max_size=500m inactive=60m use_temp_path=off;

在站点的 server 块里：

location / {
    try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_cache wp_cache;
    fastcgi_cache_valid 200 60m;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";
    fastcgi_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    fastcgi_cache_lock on;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

fastcgi_cache_lock on 这一行很重要：它防止缓存过期瞬间大量请求同时打到 PHP 造成「缓存击穿」。

第二层是对象缓存（Redis / Memcached）。 WordPress 的对象缓存默认是非持久的（每次请求都清空），所以用 Redis 之后，同一个请求内的重复数据库查询能被合并。但对大部分小站来说，第一层页面缓存就足够了，Redis 是第二优先级。 判断标准：如果你已经做了页面缓存，TTFB 稳定在 300 毫秒以内，就不需要 Redis；如果频繁出现「同一秒内多个请求各自去查库」的迹象，再上。

数据库这一层，四个参数最关键：

# /etc/mysql/mariadb.conf.d/50-server.cnf
innodb_buffer_pool_size = 1G       # 4GB 内存机器设 1G，2GB 机器设 512M
innodb_log_file_size = 256M
max_connections = 50
table_open_cache = 400

为什么 buffer pool 一定要设对？ InnoDB 会把热点数据页缓存在 buffer pool 里，这个值设得太小，查询就频繁走磁盘 IO，性能会出现数量级的下降。经验值是内存的 50% 到 70%。4 GB 机器给 PHP 留 1.5 GB、给系统留 0.5 GB，剩下 2 GB 里给 MySQL 1 GB 是合理的。

另外三个立即见效的动作：

- 定期清理自动修订和瞬时草稿。 WordPress 每次保存文章都会留一个修订版本，一篇写了半年的文章可能有几十个副本：

wp post delete $(wp post list --post_type=revision --format=ids) --force

把这个放进每周的 cron。

- 给 wp_posts 表加索引。 主题和插件常见的性能杀手是对 wp_postmeta 做无索引查询。

- 禁用 WordPress 的心跳（Heartbeat）请求。 后台编辑器每 15 秒发一次 AJAX 请求，即使没人在编辑时也会发。在 functions.php 或 mu-plugin 里：

查 digitalvirt 在售套餐与库存

add_filter('heartbeat_send', '__return_false');

七、WordPress 常见报错和排查

这一节按「报错现象 → 原因 → 解决」组织，把新手最常撞到的六个问题一次讲清。

报错一：安装向导报「数据库连接错误」或「Error establishing a database connection」。

- 原因：MySQL 没启动、密码错、数据库名不存在、或者 bind-address 还是 127.0.0.1 而 WordPress 在另一台机器上。

- 排查顺序：systemctl status mariadb 看服务状态 → mysql -u root -p 手动连一下 → 核对 wp-config.php 里的 DB_HOST、DB_NAME、DB_USER、DB_PASSWORD → 如果是容器环境，检查 MySQL 是否和 PHP 在同一个网络命名空间。

- 最常见的原因其实是数据库用户没有授权到那个库。 授权语句：

GRANT ALL PRIVILEGES ON wp_database.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;

报错二：前台 502 Bad Gateway。

- 原因：PHP-FPM 没起来，或 Nginx 的 fastcgi_pass 指向的 socket 路径不对。

- 排查：systemctl status php8.3-fpm → ls -l /run/php/ 看实际的 socket 文件名 → 核对 fastcgi_pass unix:/run/php/php8.3-fpm.sock; 里的版本号和路径。

- 另一个被忽略的原因：PHP-FPM 进程数给太多，耗尽内存后被 OOM Killer 杀掉。 这时 dmesg | grep -i oom 会看到记录。

报错三：后台白屏 / 500，前台正常。

- 原因：通常是后台加载的某个插件或主题函数报错。

- 排查：把 wp-config.php 里的 WP_DEBUG 改成 true，WP_DEBUG_LOG 改成 true，然后看 wp-content/debug.log。把 WP_DEBUG_DISPLAY 设成 false，避免错误信息暴露给访客。

- 快速定位是哪个插件：

wp plugin deactivate --all
wp plugin activate 插件名  # 逐个激活，找到报错的

报错四：上传图片失败，提示「HTTP 错误」或上传尺寸超限。

- 原因：upload_max_filesize 和 post_max_size 太小，或者 Nginx 的 client_max_body_size 太小。

- 解决：三个地方要一起改。PHP 的 php.ini 里 upload_max_filesize = 64M、post_max_size = 64M；Nginx 站点配置里 client_max_body_size 64m;。改完 PHP 配置要重启 php-fpm，改完 Nginx 要 reload。

报错五：磁盘写满，WordPress 提示「无法创建目录」。

- 原因：df -h 和 du -sh 不一致，通常是被删除但仍被进程持有的文件占着（lsof | grep deleted），或者日志没轮转。

- 排查：

df -h /
du -sh /var/lib/mysql/* /var/www/* /var/log/* | sort -h | tail -20
lsof +L1 | head -20
journalctl --disk-usage

- 长期方案：给 /var/log 和 /var/lib/mysql 配 logrotate，MySQL 开启 binlog 过期自动清理。

报错六：网站变慢，但 CPU 和内存都没跑满。

- 原因：几乎总是数据库慢查询，或者磁盘 IO 等待。

- 排查：SHOW FULL PROCESSLIST; 看有没有长查询 → SHOW SLOWLOG 或开启慢查询日志 → iostat -x 1 看 %util 和 await。

查看 恒创科技 当前月价与库存

- 判读标准：磁盘 await 超过 10 毫秒就说明 IO 是瓶颈。 这也是本文验收阈值之一。

八、上线后怎么判断这个站是否健康

站上线了不代表结束。你需要一组能持续观察的数字，而不是「打开看看觉得挺快」。

四个核心指标，各有明确的达标线：

指标一：首字节时间（TTFB）小于 300 毫秒。 从外部测：

curl -o /dev/null -s -w "ttfb: %{time_starttransfer}\n" https://你的域名/

连测 10 次取中位数。日本机房面向国内访客，优质线路通常在 30 到 90 毫秒；普通国际线路在 150 到 300 毫秒。超过 300 毫秒说明线路不达标，这不是配置问题。

指标二：内存谷值低于 15%。 连续 24 小时每 5 分钟采集一次 free -m 的 used 值，取最小值：

*/5 * * * * /usr/local/bin/healthcheck.sh >> /var/log/healthcheck.log 2>&1

谷值超过 15% 说明宿主机上有其他租户占着内存，你的机器随时可能被挤压。 这个数字比「当前用了多少」更有诊断价值——谷值高说明机器本来就紧。

指标三：数据库查询中位数小于 50 毫秒。 直接在 MySQL 里看：

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

然后用 mysqldumpslow 或 pt-query-digest 分析。单条查询超过 1 秒的列表，就是你要优化的清单。 对于未命中页面缓存的请求，数据库查询超过 50 毫秒就说明索引或 buffer pool 有问题。

指标四：磁盘平均等待时间小于 10 毫秒。 用 iostat -x 1 看 await 列。这个数字超标时，网站会「感觉慢」但 CPU 和内存都正常——因为所有请求都在排队等磁盘。

再给三个进阶观察项：

- PHP-FPM 队列长度。 ss -lntp | grep php 看 backlog，如果经常堆积，说明进程数不够，需要调 pm.max_children。

- 数据库连接数。 SHOW STATUS LIKE 'Threads_connected'; 长期贴近 max_connections 就是隐患。

- Nginx 状态码分布。 5xx 比例超过 0.1% 就应该查日志了：

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

最后一个必须做的动作：把四个阈值写进告警。 健康检查脚本已经在采数据了，只需要加一个判断：

mem_pct=$((MEM*100/TOTAL))
if [ "$mem_pct" -gt 85 ] || [ "$DISK" -gt 90 ]; then
    echo "ALERT mem=${mem_pct}% disk=${DISK}%" | mail -s "VPS告警" [email protected]
fi

查看 hostkvm 当前月价与库存

监控的作用是在用户投诉之前发现问题，而不是在投诉之后解释原因。

九、四种不该选日本 VPS 的场景

这一节回答「什么时候买日本 VPS 是错的」。四条依据全部来自公开事实——机房位置、线路类型、计费方式、IP 资源供给，不涉及对任何商家的评价。

场景一：访客主要在北美或欧洲，且业务对延迟敏感。

- 原因：日本到北美的物理距离决定了往返 RTT 通常在 250 毫秒以上，美西可以做到 30 到 60 毫秒。这是光程的下限，任何配置都改不了。

- 替代方案：选美西机房。渠道库里有明确的城市标识机型：LAX-STARTER（年付 200 美元折合月价 16.67 美元，2 核 2 GB、40 GB、2000 Mbps、5000 GB）、LAX-MICRO（年付 400 美元折合月价 33.33 美元，4 核 4 GB、80 GB、4000 Mbps、10000 GB）、LAX-MEDIUM（年付 800 美元折合月价 66.67 美元，8 核 8 GB、160 GB、10000 Mbps、20000 GB）。美西 LAX 系列三档的每 TB 流量统一是 3.413 美元、每 GB 内存统一是 8.33 美元，单价结构非常干净。

场景二：月流量超过 5 TB，且页面以图片和视频为主。

- 原因：流量单价被放大。渠道库真实数据：美西 LAX 系列每 TB 流量 3.413 美元，香港云途是 19.2 到 35.84 美元。5 TB 流量在美西，按每 TB 3.413 美元乘 5 只需 17.07 美元；在香港，按每 TB 19.2 美元乘 5 是 96，按每 TB 35.84 美元乘 5，是一百八十美元上下。日本作为中间地带，价差同样存在，且这类流量需要大带宽端口支撑，很多入门机型根本没有大端口。

- 替代方案：静态资源（图片、视频、安装包）放到对象存储 + CDN，源站只保留动态接口。或者选美西大流量机型：LAX-Storage-500G（年付 400 美元折合月价 33.33 美元，4 核 4 GB、500 GB 硬盘、10000 Mbps 带宽、10000 GB 月流量，每 GB 硬盘仅 0.067 美元）、LAX-LARGE（年付 1600 美元折合月价 133.33 美元，16 GB 内存、320 GB 硬盘、10000 Mbps、40000 GB 月流量）。

场景三：站点需要住宅 IP 或原生 IP，且需要较多 IP 数量。

- 原因：IP 属性和 IP 数量在稀缺节点上都要溢价。渠道库里能明确区分 Residential 产品线的只有美西那一组：Residential-STARTER（年付 260 美元）、Residential-MICRO（460 美元）、Residential-MEDIUM（860 美元）、Residential-LARGE（1660 美元）。日本节点在渠道库中没有公开的 IP 属性标注。

- 替代方案：去美西选 Residential 系列，并逐条核验 ASN 归属与 IP 段性质。如果业务并不真的需要住宅属性，就不要为它付钱——这六百到一千美元的差额买的是可验证的属性，不是形容词。

场景四：项目是临时的，或者随时可能停。

- 原因：日本节点的入门价不便宜。渠道库公开的东京节点起价是 19.99 美元/月（justg 公开简介写明 Tokyo、Seoul、Moscow 三节点 from $19.99/mo），用三个月就退出，实际月成本是总价除以 3。

查 vollcloud 在售套餐与库存

- 替代方案：选最低档按月付跑通全流程，验证上线后再转年付；或者对纯临时需求选按量计费的云服务器。

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

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

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

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

十、结论：四类人怎么配、按什么标准验收

直接给答案，不写「视情况而定」。

第一类：个人博客或小型展示站，访客在国内。

- 配置：2 核 2 GB 内存、40 GB 硬盘、1 TB 流量起步。如果你确定只写博客不装电商，建议直接静态化（用 Hugo、Hexo 生成静态文件），这样 1 GB 内存都绰绰有余，流量单价还更可控。

- 验收线：首字节小于 300 毫秒、内存谷值低于 15%、页面缓存命中率高于 80%。

第二类：认真做内容运营的站，或者带会员登录的站。

- 配置：4 核 4 GB 内存、80 GB 硬盘、2 TB 流量。PHP-FPM 进程数配 10 到 15，MySQL buffer pool 给 1 GB。

- 验收线：首字节小于 300 毫秒（缓存命中时）、数据库查询中位数小于 50 毫秒、内存谷值低于 15%、磁盘 await 小于 10 毫秒。

第三类：带电商（独立站或 WooCommerce）的站。

- 配置：8 GB 内存起步、160 GB 硬盘、4 TB 流量。数据库独立到单独实例或至少独立容器，订单库不能和缓存抢 buffer pool。

- 验收线：结算流程全链路首字节小于 500 毫秒、数据库连接数不长期超过 50、内存谷值低于 15%。

第四类：纯流量型业务（图片站、下载站）。

- 配置：不要在单台小机器上堆，用「静态资源走对象存储 + CDN，源站只跑动态」的结构。真要自建源站，选大带宽、大硬盘的机型：LAX-Storage-500G 每 GB 硬盘 0.067 美元、LAX-Storage-1TB（年付 700 美元折合月价 58.33 美元，8 核 8 GB、1000 GB 硬盘、10000 Mbps、15000 GB 月流量，每 GB 硬盘 0.058 美元）是这个结构下的合理选择。

所有四类人的同一条操作建议：第一周内把四个阈值全部测一遍。 首字节大于 300 毫秒、内存谷值大于 15%、数据库中位查询大于 50 毫秒、磁盘 await 大于 10 毫秒——这四条里有任何一条不达标，先定位原因（多数是线路、插件或 SQL），而不是直接升配。 升配能解决资源不足，解决不了配置错误和线路问题。

最后提醒一个反复出现的坑：年付折扣很大，但只有确定用满一年才成立。 以 LAX-STARTER 为例，年付 200 美元折合月价 16.67 美元；只用 3 个月退出，实际月成本约 66.67 美元，是折合价的四倍。正确顺序永远是：先按月付跑满一个月 → 四个阈值全部达标 → 再转年付锁定折扣。

4vps 官网机型与实时报价

价格与配置均来自渠道库快照（2026-11-14 09:07），实际报价与库存以商家官网当日显示为准。