一、先问一句：你的日 PV 到底是多少
在任何一个站长群里，只要有人问"我该用哪家的云服务器"，下面必然一堆推荐。但没人问最关键的那个问题：你的日访问量是多少，峰值并发是多少？因为答案完全取决于这个数字，一台 1 核 1G 的小机器能扛住几百 PV，也能在突发流量下瞬间挂掉。
这篇不是云厂商测评，而是给个人站长一个"按负载选配置"的判断表。核心逻辑很简单：先量清楚负载，再按瓶颈选资源。不懂这一点，买 8 核 16G 也是浪费，买 1 核 512M 也会天天 502。
二、先算清你真实的并发数
很多人把 PV 当并发，这是最大的误解。日 PV 一万，高峰集中在晚上两小时，那平均每秒不到 1.5 个请求，峰值可能到 10 个并发。但一个页面上有 30 个资源，如果每个资源都回到同一台服务器，那真实并发要乘 30。这就是为什么"日 PV 一万"的站，一台 1 核机器也会卡。
正确的估算方式是看 Nginx 日志里的每秒请求数（RPS），而不是 PV：
# 按分钟统计请求数，找出峰值分钟
awk '{print substr($4, 2, 16)}' /var/log/nginx/access.log \
| sort | uniq -c | sort -rn | head -10把峰值分钟的请求数除以 60，就是峰值 RPS。这个数字才是选配置的第一手依据。一个静态为主的小站，峰值 RPS 5~10，1 核 1G 足够；峰值 RPS 50 以上，或者跑动态 PHP，那就要 2 核以上。
还有一个更重要但常被忽略的指标：并发连接数。可以在 Nginx 的状态页或者 ss -s 里看到当前连接数。如果连接数长期在几百，而 CPU 使用率不高，说明瓶颈在 IO 或者后端等待，而不是 CPU。
三、按瓶颈类型选配置
服务器的瓶颈只有四种：CPU、内存、磁盘 IO、带宽。选配置的本质是判断你的站点主要卡在哪个。
CPU 瓶颈的典型表现是 top 里 %us 很高，PHP 或者数据库进程占满。这时候选高主频的 CPU 比选多核更划算，因为 PHP 的请求处理是单线程的，2 核 3.5GHz 比 4 核 2.0GHz 更合适。
内存瓶颈的典型表现是 swap 被使用、OOM killer 杀掉进程。数据库吃内存，PHP-FPM 的每个 worker 也吃内存（通常 30~80MB）。如果 pm.max_children 设成 50，乘上 60MB 就是 3G 内存，很多人配了 2G 机器却填了这个数字，结果是必然的。
磁盘 IO 瓶颈的典型表现是 iostat 里 %util 接近 100，或者是 iowait 很高。云服务器的普通云盘 IOPS 有限，这是最容易被忽略的一项。如果你的站有大量小文件读写（比如图片、缓存文件），一定要选 SSD 云盘或者本地盘，别用最便宜的那种。
带宽瓶颈的典型表现是 iftop 里出流量顶到上限，所有请求一起变慢。这是云服务器最常见的隐性成本：1M 带宽的理论上限是 128KB/s，一个 2MB 的页面，单用户打开就要 16 秒。这是很多人买了便宜机器却打不开的根本原因。
四、带宽比 CPU 更值得花钱
对绝大多数个人站，最先撞上的墙不是 CPU，是带宽。1M 带宽的机器，一个月大约能跑 300G 流量（满速跑），如果一个页面平均 1MB，只够 30 万次访问，而这还是理论值。
所以选配置的顺序建议是：先保证带宽够用，再考虑 CPU 和内存。具体做法是：如果预算只能加一项，加带宽；如果带宽已经够但 CPU 打满，再加核；如果有数据库，加内存。
另一个省带宽的办法是上 CDN。把静态资源（图片、CSS、JS、字体）放到 CDN，源站只承担 HTML 和动态请求，带宽压力能降 70% 以上。一个 1M 带宽的机器加上免费 CDN，能撑住比 5M 裸机更大的流量。对个人站长，这是性价比最高的一步。
要注意的是 CDN 也有坑：免费的 CDN 节点少、回源慢，如果你的用户集中在某个地区，免费的反而更慢。选 CDN 要看节点覆盖和回源策略，而不是只看价格。
五、具体配置推荐
按日均 RPS 给一个粗略的对照表，这个表是经验值，不是精确值：
RPS 1~5，纯静态或轻量博客：1 核 1G，带宽 2~3M，系统盘 SSD 40G。这个配置够跑一个静态站或者几百 PV 的 Typecho。
RPS 5~30，动态 PHP 站点：2 核 2G，带宽 3~5M，PHP-FPM 的 max_children 设 10~20，MySQL 的 innodb_buffer_pool_size 设 512M 左右。
RPS 30~100，有一定流量 + 数据库：4 核 4G，带宽 5~10M，数据库单独分池，或者至少把 buffer pool 提到 1G。
RPS 100 以上：这时候单机已经不是最优解，应该考虑静态资源全上 CDN、数据库独立、应用层做缓存（Redis），而不是一味加大机器。
这个表的核心是：加配置的收益会递减，而架构优化的收益是阶跃的。从 2 核到 4 核可能只快 30%，但把静态资源挪到 CDN，可能直接快 3 倍。
六、三笔容易被忽略的隐性成本
第一笔是备案与线路。如果你的用户主要在国内，没有备案的服务器会被拦，或者只能走境外线路，延迟高。境外线路的机器便宜，但访问体验差，这个账要算进去。同样一台配置，国内机房和境外机房的价格可能差三倍，但前者能直连，后者可能要多绕一个太平洋，用户感受完全不同。
第二笔是备份与快照。云厂商的快照是要收费的，一个 100G 的盘，每天的增量快照费用可能比机器本身还贵。选配置的时候要问清楚快照策略，或者自己用 rsync 做异地备份。对个人站，一套自己写的每日 rsync 加月度归档，成本几乎为零，可控性还更高。
第三笔是流量超额。很多云厂商的带宽是按峰值计费的，超出套餐的部分单价很高。一个突发的爬虫或者被分享到热门社区，可能导致一天几千块的账单。要有告警和限流机制，不要裸奔。最便宜的做法是在云厂商控制台里设一个账单告警，超过阈值发短信，这一项通常免费。
还有一笔更隐性的成本：迁移成本。选了一台机器，用了一年想换，结果发现系统是编译安装的、数据在本地盘、域名解析在别处，迁移要停站半天。选配置的时候顺手把环境做成可迁移的（配置用包管理装、数据用 mysqldump、附件独立目录），比省那点钱更值。
七、买之前先做一次压测
最靠谱的判断方式不是看参数表，而是自己压一次。用 wrk 或者 ab 对你的站点做一次阶梯压测，看 QPS 什么时候开始掉、响应时间什么时候拐弯：
wrk -t2 -c50 -d30s --latency 'https://example.com/'看 Latency 的 90% 和 99% 分位，以及 Non-2xx or 3xx 的数量。如果 99% 延迟在 500ms 以内，说明还有余量；如果 99% 超过 2 秒，那这台机器已经在瓶颈上了。
压测要注意：不要在高峰期做，也不要用单 IP 猛压，否则可能被机房当成攻击封掉。测试前先确认机房是否允许压测，很多云厂商是禁止的。如果压测被拦，退一步的办法是把自己的日志里的历史峰值拿出来看，那同样能用。
压测之外，还有两个更贴近真实场景的判断方法。第一是看慢日志的分布，如果 $request_time 的中位数是 0.05 秒，而 95 分位是 1.5 秒，说明少数请求被拖慢，这是资源竞争的典型信号，加核比加内存有效。第二是看同一时刻的负载相关性，如果 CPU 和网络同时打满，那优先加带宽；如果 CPU 满而网络空闲，优先加核。
八、小结：先量化，再买
选云服务器的真相是：大多数人买错不是因为不懂参数，而是因为没有量过自己的负载。先算出峰值 RPS、量出带宽峰值、看清 CPU 与 IO 的瓶颈，再按瓶颈加资源，这是唯一可靠的路径。记住一个顺序：带宽 > 内存 > CPU > 磁盘，因为带宽是硬上限，而 CPU 和磁盘在多数个人站里都不是第一瓶颈。
最后一句老实话：如果一个站真的到了需要纠结选型的量级，说明它已经有收入了，那时候请个人帮你看看架构，比自己在参数表上纠结一星期划算得多。
在那之前，不要迷信"高配"，先把静态资源挪上 CDN，把 PHP-FPM 的 max_children 调到合适，把数据库的 buffer pool 配到位。这三件事做完，一台 2 核 2G 的机器能跑出很多人 8 核机器都跑不出的稳定性。