日本VPS配置怎么选

一、别看套餐表，先看你机器在干什么

日本VPS配置怎么选这个问题，大部分人是从套餐表开始的——从最低档看到最高档，挑一个「应该够用」的档位。这个顺序恰好反了。套餐表告诉你商家给了什么，而你需要知道的是自己要用什么。

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

更反常识的事实是：多数人买到的配置都偏大，而这个偏大不是因为业务复杂，是因为套餐表的档位设计。商家通常只提供三到五档，档位之间的跨度很大，中间没有过渡选项。一个只需要 1 G 内存的业务，只能在 512 M（不够用）和 2 G（多花一倍钱）之间选。这种情况下，最优解往往不是「挑一档」，而是换一家档位设计更细的商家。

另外，配置表上的数字是「理论可用量」，不是「能跑多少业务」的换算结果。同样 2 G 内存，跑 Nginx 加 PHP-FPM 和跑 Node.js 加 Redis 加 Postgres，实际承载的业务量能差好几倍，因为不同运行时的内存开销结构完全不同。

所以正确的顺序是：先量出业务当前的实际占用，再加安全余量，然后去套餐表里找最接近的那一档。如果最接近的那一档仍然差得很多，那说明这家商家的档位不适合你的业务规模，应该换一家而不是硬套。

# 1) 内存：看峰值占用和可用余量，不要看平均值
free -m
grep -E 'MemTotal|MemAvailable|Cached|Buffers|SwapTotal' /proc/meminfo

# 2) 找出最占内存的进程，这决定了你的下限
ps aux --sort=-%mem | head -12

# 3) CPU：负载值要跟核数一起看，1.0 表示每核满载
nproc && uptime && vmstat 1 5

# 4) 磁盘：实际用了多少，以及 IO 等待占比
df -h | grep -vE 'tmpfs|udev'
iostat -x 1 3 | tail -15

第四条命令里的 wa 字段（IO 等待占比）特别值得看。如果 wa 长期超过 20%，说明你的瓶颈在磁盘而不在 CPU 和内存，这种情况下加 CPU 加内存都没有意义，该做的是换磁盘类型或者减少随机写。

还有一个容易被忽略的量是「并发数」。配置表上的核数内存都不反映并发能力，一个 2 核 4 G 的机器跑 Nginx + PHP-FPM 也就撑起几十个并发连接，这跟机器本身无关，是 PHP-FPM 的进程数配置决定的。很多人误以为买了大内存就能提高并发，实际上并发数要靠调 worker 数量和引入缓存来提升，两者完全是不同的路径。

# 1) 看当前能建立的连接数上限（ulimit 与内核参数共同决定）
ulimit -n
cat /proc/sys/net/core/somaxconn
cat /proc/sys/net/ipv4/ip_local_port_range

# 2) 看 PHP-FPM 实际起了多少 worker，决定 PHP 侧并发上限
grep -E '^\s*pm\.|^\s*pm.max_children' /etc/php/*/fpm/pool.d/www.conf 2>/dev/null

# 3) 看当前的 TCP 连接状态分布
ss -s
ss -tan state established | wc -l

# 4) 看 PHP 进程的内存占用，判断 worker 数量是否合理
ps -eo pid,rss,cmd | grep php-fpm | awk '{printf "%s %.1fMB\n", $1, $2/1024}'

第四条命令的判读方法：每个 php-fpm worker 稳定占用 30 M 到 50 M，机器有 2 G 内存且要留 800 M 给系统和其他进程，那 worker 数上限大概在 25 到 35 之间。配太多 worker 会让每个都分到很少内存、进而触发 OOM；配太少则请求排队，表现为响应慢但 CPU 不高。

二、CPU 到底要几核：看的是负载不是配置

CPU 核数的选择遵循一个反直觉的原则：在大多数 Web 业务里，核数的边际收益下降得非常快，而内存的边际收益下降得慢得多。换句话说，与其买 4 核 2 G，不如买 2 核 4 G。

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

原因在于 Web 服务的负载特征。Nginx 和 PHP-FPM 的大部分时间在等 I/O——等网络包、等数据库查询、等磁盘读。只有在 CPU 密集型场景（图片处理、视频转码、大量加解密、编译、爬虫解析）时，CPU 才会成为真正的瓶颈。

判断你的业务是否 CPU 密集，最直接的方法是看负载值与核数的关系。uptime 里的第三个数字是最近 1 分钟负载，4.0 在 4 核机器上意味着刚好跑满，在 2 核机器上意味着严重超载。经验判断是：负载值长期稳定在核数的 0.6 到 0.8 之间是比较健康的区间；长期贴着核数走说明该升配了；长期低于 0.3 则说明 CPU 有大量闲置。

还有一个容易忽略的因素是宿主机层面的 CPU 共享。商家在一台物理机上跑十台虚拟机，每台分到几核 vCPU，这些 vCPU 之间是共享同一个物理核池的。超售比高的商家，你独占 4 核可能实际只相当于别人的 2 核。这就是为什么「同配置换一家商家反而更快」的情况非常普遍。

# 1) 看进程级的 CPU 占用，区分是哪个服务在吃 CPU
top -b -n 1 | head -15
# 按 CPU 排序：top -b -n 1 -o %CPU | head -15

# 2) 看上下文切换和中断次数，切换量太高说明调度压力大
vmstat 1 5
# 关注 cs（非自愿上下文切换）和 in（中断）两列

# 3) 确认这台机器的 CPU 频率与型号，判断是不是被降频的
lscpu | grep -E 'Model name|CPU MHz|CPU max|Thread|Core|Socket'
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 2>/dev/null

# 4) 压测 CPU 算力，和套餐表给的核数对照
# nproc 给的是可见核数，跑一次就知道真实算力
sysbench cpu --threads=2 --time=20 run 2>/dev/null | grep -E 'events per second'

第三条命令特别有用。有些商家在宿主机超售严重时会动态调整频率，表面给你 4 核，实际持续频率可能只有标称的一半。从 /sys 里读实时频率能看出端倪。

三、内存怎么定：加上缓存和峰值余量

内存是最容易算、也最容易算错的配置。算错的原因是大家把「应用占用」当成了「需要买的内存」，忘了操作系统本身、忘了文件缓存、忘了峰值。

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

真实占用由四部分组成。第一是应用本身的常驻内存，一个跑着 Nginx、PHP-FPM 和 MySQL 的典型 WordPress 站点，应用常驻大概在 700 M 到 1.2 G 之间。第二是操作系统内核与后台进程，通常在 150 M 到 300 M。第三是文件缓存，这部分是可回收的，但在突发时需要空间来承接，不给它就会立刻转化为更慢的磁盘读。第四是峰值余量，业务高峰、慢查询堆积、定时任务同时启动时，内存占用会明显高于日常。

按这四部分算，一个典型的中小 WordPress 站点，2 G 内存是合理起点，4 G 是宽裕配置，1 G 属于紧张但能跑（必须配 swap 且不能有高并发）。

缓存这一项值得专门说。Linux 会把空闲内存拿来做文件缓存，读到文件时如果不在缓存就写进去。看起来内存被吃光了，其实是好事——缓存命中意味着磁盘读被跳过。反过来，如果你 free -h 看到 available 只有 200 M 但系统仍然响应正常，那说明缓存机制在正常发挥作用。真正该看的指标是 available，不是 free。

关于 swap 的常见误区也需要澄清。1 G 内存的机器配 swap 并不会让它变慢到不可用，2 G 内存的机器加了 swap 也不会因为「有 swap 所以性能差」而有明显损失。swap 的真实作用是防止突发 OOM 导致服务直接崩溃，它是保险而不是性能手段。但如果你把 swap 建在系统盘上且磁盘是 SATA 机械盘，那一旦触发 swap，性能会塌方到无法使用的程度。

# 1) 关键指标：available 才是真实余量，free 和 buff/cache 会被随时回收
free -m

# 2) 看内存交换活动，si/so 长期非零说明内存真的不够
vmstat 1 5
# si = 从磁盘换入，so = 换出到磁盘，这两个值持续非零是危险信号

# 3) 看有没有发生过 OOM，这个日志能直接告诉你是不是内存不够
grep -i 'out of memory\|oom-killer\|Killed process' /var/log/kern.log /var/log/syslog 2>/dev/null | tail -10
dmesg 2>/dev/null | grep -i 'killed process' | tail -5

# 4) 建 swap 并调整 swappiness（SSD 场景推荐 10-20）
fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
echo 'vm.swappiness=10' >> /etc/sysctl.conf
swapon --show

# 5) 加上 swap 后重启一次，确认 fstab 里已持久化
grep swap /etc/fstab

第三条命令是最有价值的诊断。很多「网站半夜自己挂了」的案例，最后查出来就是 OOM Killer 杀掉了 PHP-FPM，而原因只是某个定时脚本一次性加载了几十万条记录。

四、磁盘类型：NVMe 和 SATA 的差距比你想的大

磁盘是配置表上最容易被一笔带过、却最能影响体验的一项。很多人看到「50 GB SSD」就满足了，不去问是什么接口、什么协议、有没有做 RAID。

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

SATA SSD 和 NVMe 的差距主要在随机写入和小文件操作上。顺序读写场景（比如下载一个文件、传一个大 zip）两者差距不算夸张。但数据库这类负载全是随机小 IO，差距会被放大到十倍以上。MySQL 在事务提交时需要多次随机写日志，InnoDB 的 redo log 写入是典型的随机小 IO，在这个场景下 NVMe 的优势非常明显。

更关键的是 IOPS 限制。很多商家宣称「SSD 存储」但实际是共享的 SATA 阵列，且设置了每 VPS 的 IOPS 限制。典型数值是 500 或 1000 IOPS。这意味着即使你买的是 SSD，你的数据库每秒也只能做一千次随机操作。用 fio 可以实测。

日本机房在存储上的差异尤其值得注意。日本是全球互联网和数据中心密度最高的地区之一，机房资源紧张，很多中小商家拿不到优质的企业级 SSD，甚至用消费级 SSD 做 RAID 0 拼容量。这与欧美部分机房用企业级 U.2 固态的情况形成对比。

# 1) 确认硬盘类型和接口，nvme 和 /dev/sda 的区别就在这里
lsblk -d -o NAME,SIZE,ROTA,MODEL
# ROTA=0 是固态，1 是机械
cat /sys/block/nvme0n1/queue/rotational 2>/dev/null

# 2) 实测随机写性能，这是数据库场景真正关心的指标
# fio 若未安装：apt install -y fio
fio --name=randwrite --ioengine=libaio --direct=1 --rw=randwrite \
    --bs=4k --iodepth=32 --size=512M --runtime=20 \
    --filename=/tmp/fiotest --group_reporting

# 3) 看 IOPS 限制，用 fio 的 iodepth=1 小块测试能暴露限速
fio --name=seqwrite --ioengine=libaio --direct=1 --rw=write \
    --bs=4k --iodepth=1 --size=128M --runtime=10 \
    --filename=/tmp/fiotest2 --group_reporting

# 4) 用 iostat 观察实际 IOPS 和延迟
iostat -x 1 3
# 关注 iowait(%) 和 await(ms) 两列

第三条命令的判读方法有两个要点。第一，IOPS 数字要跟商家承诺的限制对照——如果商家说限 1000 IOPS 而你实测稳定在 1000 出头，那就是限制生效了。第二，看延迟分布，如果 IOPS 没到上限但 await 已经很高，说明问题在宿主机层面而不是限制值，这时候升配磁盘也未必有用。

还有一件事需要单独确认：磁盘是不是独立分配的。有些商家用 Ceph 或其他分布式存储池，VPS 看到的「一块盘」实际上是很多物理盘的切片。这种架构的随机写性能反而可能不如传统 RAID，但一致性更好、扩容更灵活。还有些商家允许把存储单独升级到更快的池子，这需要在下单前问清楚能不能后续单独调整。

# 1) 看磁盘的队列深度和调度算法，机械盘和 SSD 的最优值不同
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/nr_requests

# 2) 看磁盘的 Trim 支持情况，SSD 上开着能长期维持性能
cat /sys/block/nvme0n1/queue/discard_granularity 2>/dev/null
lsblk -d -o NAME,DISC-GRAN,DISC-MAX

# 3) 查文件系统类型，ext4 与 xfs 在大文件写入上表现不同
df -T | grep -vE 'tmpfs|udev'
# 4) 检查是否有未回收的删除空间，这会拖慢 SSD
du -sh /var/log 2>/dev/null
journalctl --disk-usage 2>/dev/null

第四条命令的判读方法：如果日志目录占用超过几个 G 且机器运行时间长，很可能是日志没有轮转。这类空间不仅浪费，还在持续产生随机写，进一步拖慢磁盘。清空日志并配置 logrotate 往往是性价比最高的一次优化。

五、带宽与流量：端口和额度是两笔账

日本VPS配置的带宽部分，要分成端口带宽和月流量额度两个独立的口径来看，这两笔账各管各的。端口带宽决定瞬时速度上限，月流量额度决定你一个月能传多少数据。商家常常在产品页只把其中一个写得很显眼。

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

端口带宽对多数业务来说是够用的门槛而不是体验差异。一个 100 Mbps 的端口，对一个日均几千 PV 的内容站来说，即便所有静态资源都从源站直出也绑绑有余。真正决定体验的是延迟、丢包和晚高峰的稳定性。

月流量额度才是真正需要算清的。计算方式是：月总流量 = 页面请求数 × 单次传输量 + 后台传输 + 邮件与其他杂项。一个日均 5000 PV、平均传输 1 MB 的站点，月流量大约 150 GB。这个数字如果套餐只给 100 GB，就会在月中被限速或停机。

# 1) 用 nginx 访问日志统计真实的每小时请求分布
awk '{print $4}' /var/log/nginx/你的站点.access.log | cut -d: -f1 | sort | uniq -c | sort -k2

# 2) 统计每个请求的平均响应体大小
awk '{sum+=$10; n++} END {printf "平均响应 %.1f KB, 样本 %d\n", sum/n/1024, n}' \
  /var/log/nginx/你的站点.access.log

# 3) 用 vnstat 统计真实月流量，比推算准
apt install -y vnstat && vnstat --oneline b && vnstat --oneline m

# 4) 找出最耗流量的 URL，定位该优化还是该加量
awk '{split($7,a,"?"); print a[1], $10}' /var/log/nginx/你的站点.access.log \
  | sort -k2 -rn | head -15

第四条命令特别有用。跑完之后经常会发现流量被一两个大文件吃掉了——一个没压缩的原始图、一个没做缓存的第三方脚本。加上长期缓存头或换成 WebP 格式，流量能砍掉三成以上，这比直接升级套餐便宜得多。

六、IP 与线路类型：配置表不写但影响很大

配置表上不写、但对业务影响极大的一项是 IP 和线路类型。日本机房提供的 IP 资源分几类：原生 IP（本地注册商分配）、广播 IP、租赁 IP，三者在流媒体解锁、部分平台的账号风控上有明显差别。

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

原生 IP 在实际使用中的差异体现在几个具体场景：某些流媒体平台按 IP 归属地判定可播放内容，广播 IP 往往被识别为机房段而无法观看；某些电商和支付平台对 IP 信誉做风控，长期被滥用过的 IP 段会影响下单成功率；部分需要「本地 IP 证明」的注册流程，广播 IP 无法通过验证。原生 IP 的获取成本通常更高，需要在下单前明确问清。

线路类型同样不在标准配置表里。日本机房常见的线路有普通国际 BGP、面向中国方向优化的 IEPL/IPLC、CN2 GIA 这类精品线路。它们的区别在于回中国内地方向走的路由是否绕路。

# 1) 查本机公网 IP 和归属地
curl -s ipinfo.io/json | head -20
curl -s https://api.ip.sb/geoip

# 2) 查 IP 的自治系统号，判断是原生还是广播的常见线索
whois $(curl -s ifconfig.me) 2>/dev/null | grep -iE 'orgname|org-name|descr|country|netname' | head -10

# 3) 从多个方向测延迟与丢包，判断线路质量
# 需要在目标地区也跑一份，这里给的是基础命令
ping -c 20 你的目标IP
mtr -r -c 20 你的目标IP

# 4) 看去程和回程是否绕路
mtr -r -c 20 你的目标IP | head -15
traceroute -n 你的目标IP | head -12

第二条命令的判读方法：如果 whois 里的 orgname 与当地主流运营商一致，多半是原生 IP；如果指向某个广播服务商的名字，说明是广播 IP。这一步在下单前应该主动问商家确认，不要等到用了半年才发现账号莫名被风控。

IP 之外还有一项必须核对的指标是「是否被列入滥用名单」。同一个 IP 段里如果已经有大量租户被判定为垃圾邮件源或薅羊毛账号，你的业务也会受影响。具体可以查几个公开的信誉数据库，或者更直接的做法是买之前让商家提供一段测试 IP，自己用邮件和主流平台的注册流程实测一遍。

# 1) 从不同地区节点验证 IP 归属地是否一致
# 用公共的多地测速接口，一次拿到多个地区的判断
curl -s http://ip-api.com/json/$(curl -s ifconfig.me)?lang=zh-CN

# 2) 检查反向解析是否配好，很多服务要求 PTR 记录可用
dig -x $(curl -s ifconfig.me) +short
host $(curl -s ifconfig.me) 2>/dev/null

# 3) 确认 25 端口和 DNS 服务在正常工作
# 25 端口不通意味着你无法自建邮件服务器发信
nc -zv $(curl -s ifconfig.me) 25 -w "%{http_code}\n" 2>&1 | tail -2
dig @$(curl -s ifconfig.me) example.com +short

# 4) 查一下这个 IP 段的历史信誉记录
curl -s "https://api.blocklist.de/api.php?ip=$(curl -s ifconfig.me)"

第二条命令的判读方法：能返回一条 PTR 记录说明商家做了反向解析，这对邮件送达率有帮助；如果返回空，说明是默认配置，自建邮件基本不指望。

线路延迟的测试要放在真实时段做。机房到中国内地的路由质量在晚高峰和不同时段差别很大，建议分别在工作日上午和晚上八点到十点各测一轮，把两次结果都记下来。如果两个时段差距很大，说明这条线路是共享且拥塞的，独享线路则通常更稳定。

七、扩展路径：买之前问清能不能升

日本VPS配置怎么选，还有一个隐藏维度是「未来怎么扩」。很多套餐在购买页写得很清楚，但升配政策往往要问客服才知道，而这一条直接决定了你两三年后的自由度。

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

三个必须问清的问题。第一是能否升配不换 IP，升配后原来的 IP 会不会变。第二是升配的价格怎么算，是按差价补还是按新价重新买。第三是降配是否允许，如果允许的话是否随时可以降回来。

第三个问题听起来奇怪，但很多人不敢问，觉得「降配」听起来像要退钱。实际上很多商家支持随时降配，只是降下来之后可能没有赠送流量或者带宽，落到某个档位以下可能不受支持。问清楚这一条，等于给自己留了退路。

还有一个重要的实务细节：升配通常需要重装系统或者迁移，这意味着你的 IP 可能变、数据可能需要重新部署。如果你的业务对 IP 稳定性敏感（比如已经备案的域名指向、已经绑定的支付回调白名单），升配就不是一件简单的操作。

# 1) 记录当前机器的关键信息，作为未来对照基线
cat > /root/server_baseline.txt <<'EOF'
IP: $(curl -s ifconfig.me)
Hostname: $(hostname)
OS: $(cat /etc/os-release | grep PRETTY_NAME | cut -d= -f2)
Kernel: $(uname -r)
CPU cores: $(nproc)
Mem MB: $(free -m | awk '/Mem:/{print $2}')
Disk: $(lsblk -d -o NAME,SIZE,ROTA,MODEL | tail -n +2)
EOF
cat /root/server_baseline.txt

# 2) 下单前把这些参数抄下来，跟商家确认升配后的预期值
# 3) 升配后跑同样的命令对比，确认是否只有 CPU 内存变了

八、五种最常见的配置浪费

配置浪费比配置不足更普遍，因为它不报错。上面五类占了日常遇到的绝大多数。

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

第一种是为「以后可能会用到」买内存。业务还没起来就先按未来三倍的量配机器，结果业务没起来，机器先闲置了。正确的做法是按当前需求买，保留可升配的路径，等真需要时再升。

第二种是买大带宽配小流量，或者反过来。端口带宽给到 1 Gbps 但月流量只给 100 GB，导致带宽永远跑不满；或者流量给到 5 TB 但端口只有 100 Mbps，传一个 1 GB 的文件要一分多钟。这两个数字必须匹配着看。

第三种是内存被 swap 占着还硬扛。业务明明需要 4 G 却硬塞在 2 G 机器上，机器上 constantly 在做磁盘换页，表现出来是「明明配置一样但比别的机器慢」。这种情况应该升配，而不是优化代码——优化代码的收益远不如加内存。

第四种是磁盘买大了却不分区利用。买了 100 G 只用了 20 G，但数据库文件放在系统盘上而数据盘空着，这等于把最容易产生随机写的部分放在性能可能最差的存储上。

第五种是多个服务抢同一个核。很多人在一台 1 核机器上同时跑 Nginx、PHP-FPM、MySQL、Redis、监控 agent、定时任务，虽然每个都不重，加起来就把核数吃满了。

# 1) 一眼看出内存缺口：swap 有使用量就说明内存不够
free -m

# 2) 一眼看出 CPU 是否被打满：看负载 vs 核数
echo "cores=$(nproc) load=$(cut -d' ' -f1-3 /proc/loadavg)"

# 3) 找出占资源的 TOP 进程，判断是不是有可以关掉的
ps -eo pid,pcpu,pmem,rss,comm --sort=-pcpu | head -12
ps -eo pid,pcpu,pmem,rss,comm --sort=-pmem | head -12

# 4) 检查磁盘 I/O 等待占比，高于 20% 说明瓶颈在盘不在 CPU
iostat -x 1 3 | awk '/Average/ {print "wa="$10" await="$13}'

# 5) 找出可以精简的后台服务
systemctl list-units --type=service --state=running --no-pager \
  | grep -vE 'dbus|systemd|ssh|cron|getty|udev|polkit|rsyslog' | wc -l

第五条的输出如果超过十个，就值得花点时间逐个确认是不是必需。很多监控和统计类 agent 是默认安装的，自己却从来不用，关掉之后能省出可观的资源。

还有一种浪费属于「结构性的」：把内存型服务和磁盘型服务放在同一台机器上。数据库吃内存、Redis 吃内存、日志分析吃 CPU 和磁盘，它们挤在一起时互相争抢，任何一个吃紧都会拖累全部。与其在一台机器上把每样都配够，不如考虑把不同性质的服务拆开，这样单台的配置门槛反而更低，总成本可能还更省。

# 1) 看 cron 任务清单，找出可以合并或下线的定时任务
crontab -l 2>/dev/null
for f in /etc/cron.d/*; do echo "== $f"; cat "$f"; done 2>/dev/null

# 2) 看日志切割是否配置，避免日志无限增长吃磁盘
ls -l /etc/logrotate.d/ 2>/dev/null
grep -rn 'rotate' /etc/logrotate.d/ 2>/dev/null | head -10

# 3) 找出常年不动的目录，通常是历史遗留，可以清理或归档
du -sh /* 2>/dev/null | sort -h | tail -10

# 4) 找出没在用的包，能卸掉就卸掉，省磁盘也省内存
dpkg -l 2>/dev/null | awk '$1=="ii"{print $2}' | wc -l
apt autoremove --dry-run 2>/dev/null | tail -5

第三条命令的判读方法：如果某个目录占了很大空间但最近三个月没有任何文件被修改，它大概率是可以归档或删除的历史数据。但删除前务必确认它不是被某个服务引用——用 lsof +D /路径 查一下有没有进程正在占用，比直接删安全得多。

九、按场景选配置的对照表

把前面的推导落到具体场景上，就是下面这张对照表。表里的配置是起点区间，具体还要用你自己机器的实测数据校准，不同商家的档位设置差异也很大。

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

业务场景	CPU	内存	磁盘	端口 / 月流量	关键理由
个人博客 / 静态站	1 核	1–2 G	20–40 G SATA	10–50 Mbps / 200–500 G	静态为主，瓶颈在带宽不在配置
WordPress 企业站	2 核	2–4 G	60 G 以上 NVMe	50–100 Mbps / 500 G–1 T	数据库随机写多，磁盘类型比内存更重要
电商 / 独立站	2–4 核	4–8 G	100 G 以上 NVMe	100 Mbps 起 / 1–3 T	图片多、并发高，但要靠 CDN 削峰
API / 后端服务	2 核	2–4 G	40–60 G NVMe	50–200 Mbps / 200–500 G	看的是并发连接数与单流延迟
数据库 / 缓存节点	4 核	8–16 G	NVMe，单独规划	100 Mbps / 500 G	内存与 IOPS 直接决定 QPS
视频转码 / 存储	4 核以上	8 G 以上	大容量，按需扩展	1 Gbps 起 / 5–20 T	CPU 密集且带宽长期跑满
代理 / 隧道节点	2 核	1–2 G	20–40 G	100 Mbps–1 Gbps / 按量	流量消耗大，线路质量优先
CI / 构建机	4 核	4–8 G	100 G 以上 SSD	100 Mbps / 1 T	编译是 CPU 与磁盘双密集

这张表的用法是：先在「业务场景」列找到最接近你的一行，得到配置的起点，再回到第一到第四节的命令去量你当前的实际占用。如果实测值明显低于起点，说明你可以降一档省钱；如果实测值高于起点，就该升配而不是硬扛。

最后提醒一点关于配置表本身：同一档位在不同商家之间的实际含义差别很大，同样写「2 核 4 G 50 G NVMe」的套餐，可能一个限 1000 IOPS 一个不限，可能一个共享带宽一个独享，可能一个送 1 T 流量一个只送 200 G。所以跨商家比价时不能只比那几个数字，必须把第六节和第七节讲的 IP 类型、线路、IOPS 限制、流量额度、升配政策一起列出来横向对比。

另一个实务建议是先买小再买大。绝大多数业务在前三个月会用掉最终配置的一半左右，剩下的增长才是真正的刚需。先用入门档跑起来，积累一两个月的真实曲线，再决定升配，能避免一次性买过头。

十、常见问题

日本VPS配置怎么选，最少需要什么配置？ 没有绝对下限，取决于业务类型。以最常见的个人博客为例，1 核 1 G 内存配 20 G 磁盘可以跑起来，但必须加 swap 且不能有高并发；2 核 2 G 是更稳妥的起点。判断方法不是看业务类型猜，而是量：跑一遍 free -m 看 available、uptime 看负载对核数、iostat -x 看 wa 值，三个数字共同决定你的真实下限。只跑 Nginx 和静态页的站点和跑 WordPress 加 MySQL 的站点，配置差三倍很正常。

2 核 4 G 和 4 核 2 G 选哪个？ 绝大多数 Web 业务选前者。Web 服务大量时间在等 I/O 而非算，内存不足会触发 swap 造成磁盘读写抖动，体感上比 CPU 略慢糟糕得多。例外是纯计算型负载——视频转码、批量编译、大量加解密——这类任务 CPU 密集而内存占用低，此时 4 核 2 G 更合适。最稳的判断方法是看 vmstat 1 5 里的 si 和 so 两列，如果它们长期非零，说明内存是瓶颈；如果 wa 很低而 us 很高，说明 CPU 才是瓶颈。

SSD 和 NVMe 真的差那么多吗？ 对数据库和高并发写入的场景，差距非常明显。SATA SSD 在 4K 随机写上通常只有几千 IOPS，NVMe 能到几万甚至十几万，两者相差一个数量级。但对顺序读为主的场景（比如跑下载站、传大文件），差距会小很多。商家写「SSD」时要确认是 NVMe 还是 SATA、是独享还是共享阵列、有没有每 VPS 的 IOPS 限制。用 fio 实测一次最直接，如果 IOPS 稳定在 1000 左右，那就是被限速了。

买之前需要问商家哪些问题？ 至少问五项：是否原生 IP、续费价是否与首购价一致、超流量后是限速还是停机以及超额单价、是否支持升配不换 IP、磁盘是否 NVMe 以及有无 IOPS 限制。这些答案都建议以文字形式留在工单或邮件里，口头承诺在出问题时很难作为依据。选商家时可以对照日本相关服务商的公开机型与线路说明页自行核对。

配置升级之后性能一定更快吗？ 不一定。升配提升的是资源上限，但实际表现还受宿主机超售、CPU 频率、磁盘 IOPS 限制、宿主机邻居负载的影响。同一家商家换一台新机器，配置数字一样但性能可能差百分之几十，这是很常见的现象。所以升配后要实测对比，用 sysbench cpu、fio、ab 三项各跑一次，和旧机数据放在一起看。如果新机更慢，问题在商家而不是你的配置。

怎么知道自己现在的配置是不是买多了？ 连续观察一到两周的数据再下结论，不要只看某一时刻。判断配置是否偏大的三个信号：available 内存长期超过总量的一半（说明内存有大量闲置）、swap 从未被使用过、iowait 长期低于 5%。三个信号同时出现，就说明当前配置对你是过剩的，可以考虑降档省钱。但要注意一点：如果是新上线、流量还在爬坡的站点，现在数据不代表未来三个月，所以降档前要看趋势而不是绝对值。