韩国VPS打开慢怎么优化

一、先分清：打开慢到底慢在哪一段

韩国VPS打开慢，绝大多数人的第一反应是「换个配置更高的机器」。这个反应有一半是对的，但另一半纯属浪费钱——因为从用户按下回车到页面完全显示出来，中间被拆成了三段完全不同的耗时，每一段的成因和解法都不一样。

第一段是首字节时间（TTFB，Time To First Byte）：从请求发出到服务器返回第一个字节。这段时间花在网络往返、TCP 握手、TLS 握手、排队等待 Web 服务器 fork 出 worker、PHP 解释器启动、数据库查询。这是最容易被误判的一段——很多人看到「打开慢」就以为是带宽不够，但带宽只影响第二段。

第二段是传输时间：服务器把 HTML、CSS、JS、图片的字节流给出去。这段由带宽上限和页面总大小共同决定。100Mbps 的口传一个 2MB 的页面，在理论满速下只需要 0.16 秒；如果你实测花了 5 秒，那问题一定不在带宽，而在链路拥塞、服务器上行被邻居抢占，或者页面上有什么东西在拖住下载。

第三段是渲染时间：浏览器拿到数据后解析 HTML、拉取其余静态资源、执行 JavaScript、布局、绘制。这一段跟你的 VPS 一点关系都没有，它取决于前端代码质量和访客的设备与网络。很多「VPS 打开慢」的工单真相是：手机 4G 打开一个加载了 3MB 未压缩 JS 的主题，服务器 20ms 就返回了 HTML，但访客等了 8 秒。

所以第一步永远是：分段测量，不要凭感觉。

# 1) 分别测 DNS 解析、TCP 连接、TLS 握手、首字节、总耗时
curl -o /dev/null -s -w "DNS: %{time_namelookup}s  TCP: %{time_connect}s  TLS: %{time_appconnect}s  TTFB: %{time_starttransfer}s  TOTAL: %{time_total}s  SIZE: %{size_download}B\n" https://你的站点/

# 2) 连续 10 次取中位数，别用单次结果下结论
for i in $(seq 1 10); do
  curl -o /dev/null -s -w "%{time_starttransfer} %{time_total} %{size_download}\n" https://你的站点/
done | sort -n | awk '{a[NR]=$0} END {print "中位 TTFB/TOTAL/SIZE:", a[int(NR/2)+1]}'

# 3) 看首屏到底请求了多少个资源、总多大
curl -s https://你的站点/ | wc -c

查 justg 在售套餐与库存

这三个命令跑完，你手里就有了一张分段账单。如果 TTFB 已经超过 300ms，那么后面两段的优化收益都极其有限，必须先解决服务端。如果 TTFB 在 50ms 以内而 TOTAL 很大，那问题在前端资源，加服务器配置一点用都没有。

二、验收阈值：优化前后到底该达到什么数

没有阈值的优化等于没优化。「感觉快了一点」不能作为验收依据，因为人的主观感受会被缓存、页面类型、当时的网络状态带偏。这套文章给的是一组可以直接拿去用的硬阈值，跑完就知道自己合格没有。

指标	合格阈值	优秀阈值	怎么测
首字节 TTFB（动态页）	< 300ms	< 100ms	`curl -w "%{time_starttransfer}"`
首字节 TTFB（静态页）	< 100ms	< 50ms	同上
1MB 静态资源下载	< 2s	< 800ms	`curl -o /dev/null` 测大图
首页总资源数	< 30 个	< 15 个	DevTools Network 面板
首页传输总量（未压缩）	< 800KB	< 400KB	`curl -s ... \	wc -c`
内存使用谷值	< 15% 物理内存	< 8%	`free -m` 看 buff/cache 之外的 used
磁盘占用率	< 70%	< 50%	`df -h`
数据库单次查询	< 50ms	< 20ms	`SHOW PROFILE` 或 `EXPLAIN`
数据库连接数	< 内存/256MB	< 内存/512MB	`SHOW STATUS LIKE "Threads_connected"`
慢查询数量	每小时 < 10 条	0 条	`SHOW GLOBAL STATUS LIKE "Slow_queries"`

vpckr 官网机型与实时报价

内存这一项需要说清楚。Linux 报告的 used 里，一部分内核用来做文件缓存，机器看着「快满了」其实还很健康。真正的判断标准是在业务低峰时（通常是凌晨）看 available 那一列。如果 available 长期低于物理内存的 15%，说明一旦遇到突发流量就没有余量，swap 会开始抖动，表现为「平时没问题，一波高峰就卡死」。

还有一项必须单独列出来：Swap 分区的大小与优先级。Swap 不是用来当内存用的，它是给突发内存不足兜底的保险丝。给 2GB 内存的机器配 2GB Swap 是合理的；有人配 16GB Swap，结果是把本该立刻报错的内存不足，变成了一场漫长的磁盘写入风暴——请求进来，进程排队等 swap 换页，CPU 显示不忙，但请求全部超时。

# 调整 swap 优先级：默认 60，设置成 10 表示优先使用物理内存
sudo swapon --show
sudo sysctl vm.swappiness=10
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf

# 查看当前是否在换页（si=换入，so=换出，两列持续非 0 说明 swap 正在工作）
vmstat 1 60

vm.swappiness=10 是一个常用设置：它让内核优先用物理内存，只在确实需要时才动 swap。默认值 60 偏激进，会让内核更早地开始换页，对 VPS 这种既要跑应用又要留余量的场景不合适。

# 内存健康度：重点看 available，不要看 used
free -m

# 更准的：算 committed 压力
cat /proc/pressure/memory

# 磁盘
df -h

# 观察 60 秒内的实时占用（vmstat 的 r 是就绪队列，b 是阻塞队列）
vmstat 1 60

vmstat 那个输出里，r 列持续大于 CPU 核数说明 CPU 排队，b 列持续大于 0 说明有进程在等 IO。这两个数字能直接告诉你「慢」是算力不够还是磁盘不够。

三、算账：优化到底值多少钱，还是换机器更划算

这是最多人跳过的一步。他们把优化当成免费的体力活，但压缩、缓存、加内存都是有成本的。这里用我们商品库里能查到的真实价格，把账算出来。

先看单位成本。商品库里几档机型的折月价与单位成本如下（数据来自渠道库快照，价格随商家调整而变化，此处只用于横向比较性价比）：

机型	折月价	内存	磁盘	流量	美元/GB内存	美元/GB盘	美元/TB流量
RosCloud-01	19.99	1G	20G	1024GB	19.99	0.999	19.99
RosCloud-02	29.99	2G	40G	2048GB	14.99	0.750	14.995
RosCloud-03	39.99	4G	80G	3072GB	10.00	0.500	13.33
RosCloud-04	49.99	8G	160G	4096GB	6.25	0.312	12.498
RosCloud-05	59.99	16G	240G	5120GB	3.75	0.250	11.998
RosCloud-06	69.99	24G	320G	6144GB	2.92	0.219	11.665

查看 zji 当前月价与库存

这张表给出三个可以直接用的结论。

结论一：内存的单价随配置翻倍而快速摊薄。 从 RosCloud-01 到 RosCloud-06，内存从 1GB 涨到 24GB（24 倍），折月价只从 19.99 涨到 69.99（3.5 倍），每 GB 内存的成本从 19.99 美元降到 2.92 美元，降幅 85%。也就是说，如果你已经确定要跑 PHP + 数据库 + 反向代理这一套，往上跳一档省下的钱远不止账面差价——因为你还得省下重启和迁移的时间。

结论二：磁盘的单价下降最陡，是被严重低估的成本项。 每 GB 盘从 0.999 美元降到 0.219 美元，降了 78%。很多人在优化时只盯着 CPU 和内存，忘了磁盘 IO 才是 WordPress 后台慢的主因：数据库的随机读写、swap 抖动、图片处理全靠盘。盘从 20GB 升到 320GB 而月价只多 50 美元，这个交换比很划算。

结论三：流量的单价下降最平缓。 每 TB 流量从 19.99 美元降到 11.665 美元，只降了 42%。这说明靠升级套餐来「省流量费」效率很差，流量成本主要靠架构解决——上 CDN、做缓存、压缩静态资源，而不是升配。

现在把这三条账套到「优化 vs 升配」的决策上：

情形 A：TTFB 高、内存够、磁盘小。 典型的低配机器跑 WordPress。此时升内存没用（内存谷值才 10%），但升盘有用。假设你要装 Docker、多个 PHP 版本、数据库和日志，20GB 盘很快见底，而升级到 160GB 盘的那档只多花 30 美元，折合每 GB 0.312 美元。此时优化收益（加 swap 之外换盘）约等于升级成本，直接升配更省事。

情形 B：TTFB 低、总时长大。 页面总大小是主因。这时升配的边际收益接近零，因为瓶颈在浏览器和链路，不在服务器。唯一有效的路是压缩 + 缓存 + CDN，成本是零到每月几元（对象存储回源费）。

情形 C：内存谷值超过 40%，且有 swap 活动。 这是唯一一个「必须升配」的情形。swap 一旦开始工作，磁盘随机 IO 会把延迟放大几十倍，TTFB 从 50ms 跳到 800ms 以上，而任何缓存优化都救不了——缓存进程本身需要内存。这种情况下，先确认 PHP 的 worker 数是不是配错了（见第七节），如果能通过参数把内存压下来，升配可以延后；如果压不下来，内存档位的单价摊薄意味着升配是划算的。

# 确认是不是 swap 在拖后腿
swapon --show
# vmstat 1 60 里 si/so 两列持续非 0 就是 swap 在读写
vmstat 1 60 | awk 'NR>2 && ($7>0 || $8>0) {print "swap 活动:", $0}'

一个必须说清楚的现实：以上是横向比较不同配置性价比的框架。韩国节点的机型目前没有结构化套餐数据可查，韩国相关的商家（justg、vpckr、zji、恒创科技、vollcloud 等）都有首尔节点，但具体配置与报价以官网当日报价为准。你需要做的，是把自己的需求折算成「我要 4GB 内存、80GB 盘、3000GB 流量」，然后拿这个数字去这些商家的官网比，而不是在这里抄一个别人的价格。

四、收益排序：先做那 5% 的事

优化的正确顺序，是按收益 ÷ 成本排，不是按技术难度排。下面是按这个比值排好的队列，前四项通常能吃掉 80% 的打开时间，而且都不花钱或花很少的钱。

第 1 名：给静态资源加缓存头。 成本为零，收益常常在 50% 以上。对 Nginx 来说就是加一段 expires 指令，让 CSS、JS、图片、字体在浏览器里存上 7 到 30 天。访客第二次打开时，这些资源根本不经过你的服务器。

# 在 server 块里加，静态资源长缓存
location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2?|ttf|eot)$ {
    expires 30d;
    add_header Cache-Control "public, max-age=2592000, immutable";
    access_log off;
}

immutable 这个指令值得单独说：它告诉浏览器「这个资源的内容变了文件名也会变，你尽管永久缓存」。配合后续的内容哈希文件名（app.a1b2c3.js），改版时用户不会拿到旧的 JS 文件。

第 2 名：开启 Gzip 或 Brotli 压缩。 成本为零。HTML 和 JSON 压缩率通常能到 70% 以上，CSS 和 JS 在 50% 到 70%。一个 500KB 的页面，压缩后 150KB，传输时间直接掉到三分之一。

gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 512;
gzip_types text/plain text/css text/xml application/json application/javascript application/xml+rss image/svg+xml;

# 更激进的可以装 brotli 模块，压缩率再高 10% 到 15%

gzip_comp_level 5 是性价比最高的档位。从 5 调到 9，压缩率只多榨出 3% 到 5%，但 CPU 消耗翻倍。对绝大多数站点，5 是甜点；如果是纯文本为主的博客且 CPU 有余量，可以试试 6。

还有一个容易被忽略的细节：压缩只对文本生效，对已经压缩过的格式是负优化。PNG、JPEG、WebP、MP4、ZIP 这些格式本身内部就是压缩格式，再套一层 gzip 几乎不缩小体积，反而白白消耗 CPU 并让 Content-Length 变成未知，导致某些客户端无法预判大小。所以 gzip_types 里绝对不要加 image/*、video/* 和 application/zip。

# 验证压缩是否真的生效：对比有/无 Accept-Encoding 的下载大小
curl -s -o /dev/null -w "未压缩: %{size_download}B\n" https://你的站点/style.css
curl -s -H "Accept-Encoding: gzip" -o /dev/null -w "压缩后: %{size_download}B\n" https://你的站点/style.css

两个数字一比就知道收益。一个 180KB 的 CSS 通常能压到 55KB 左右，传输时间直接省掉三分之二。

第 3 名：给 PHP 加 Opcache。 成本为零，效果立竿见影。PHP 每次请求都要重新解析编译一遍 PHP 文件，没有 Opcache 时一个 3000 行的 WordPress 主题每次请求都要编译 3000 行，这是纯浪费。开启 Opcache 后，同一份代码只编译一次，之后走内存缓存。

# Debian/Ubuntu
apt install php8.2-opcache
# 或直接在 php.ini 里
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

opcache.memory_consumption 设为 128MB 是 2GB 内存机器的合理起点；max_accelerated_files 至少要覆盖你所有站点文件的总数，用 find /var/www -name "*.php" | wc -l 数一下。

第 4 名：数据库加索引 + 清理长期事务。 这是 WordPress 慢查询的头号原因。首页最常见的慢查询是「按时间取最近 N 篇文章并关联分类和作者」这类 JOIN，如果 wp_posts.post_date 没有索引，或者有大量未关闭的事务持有行锁，查询就会变慢。

-- 找出最耗时的 10 条查询（MySQL 8）
SELECT query_time, lock_time, rows_examined, rows_sent, LEFT(info, 120) AS q
FROM performance_schema.events_statements_summary_by_digest
ORDER BY query_time DESC LIMIT 10;

-- 慢查询计数
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW VARIABLES LIKE 'long_query_time';

rows_examined 和 rows_sent 的比值如果超过 100，说明索引不对——扫了一万行只返回一行。

第 5 名：把静态资源搬到对象存储 + CDN。 成本是每月几元到几十元，但能让你的 VPS 只负责动态请求。注意回源策略：HTML 页面必须不缓存或只缓存极短时间（比如 60 秒），静态资源缓存 30 天以上。HTML 缓存久了，读者会看到旧文章。

第 6 名：升级配置。 收益排在最后，因为它解决不了 90% 的「慢」。

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

第 7 名：换机房或换商家。 排在最后不是因为它没用，而是因为它成本最高（迁移、重新备案或重新解析 DNS、可能损失数据），而且在没做完前面六项之前你无法判断到底是不是线路问题。

五、CDN 策略：什么时候用、用哪种回源

CDN 不是万能药，但用对地方收益极大。核心要理解的是回源这个概念：访客没有命中 CDN 边缘节点的缓存时，请求会被转发回你的源站，这叫回源。

关键判断：你的源站 IP 是不是暴露的？ 如果源站 IP 泄露了，攻击者可以直接打源站，绕过 CDN 全部防护。所以正确做法是：上 CDN 后立刻把源站 IP 加进防火墙白名单，只允许 CDN 的回源 IP 段进来。

# 装 ufw 后，只放行 CDN 回源段和其他必要端口
ufw default deny incoming
ufw allow 22/tcp
ufw allow 443/tcp
ufw allow from 你的CDN回源IP段 to any
ufw enable

三种缓存规则怎么配：

资源类型	缓存时间	原因
HTML 动态页	0 秒或 60 秒	内容随时会变，缓存久了读者看到旧文章
CSS/JS/字体	30 天 + immutable	内容哈希命名，改版即换名
图片/视频	30 天到 1 年	内容不变，缓存越久越好
API 接口	60 秒到 5 分钟	按业务时效性定

查看 hostkvm 当前月价与库存

什么时候不该上 CDN： 站点是纯 API 后端、没有公开网页、或者你的访问者几乎全部在国内而 CDN 节点覆盖不到——这种情况加 CDN 只会多一跳，延迟变长而不是变短。韩国节点的优势恰恰在于对东北亚（韩国、日本、东北亚方向的访问）延迟低，如果你的用户在东亚，CDN 的价值主要是静态资源卸载和抗波动，不是加速首字节。

回源带宽成本的隐含影响：CDN 缓存命中率低的时候，所有流量都会穿透回源，等于你的流量额度被白白消耗掉一半以上。监控 CDN 面板的回源流量占比，这个数字超过 30% 就说明缓存规则配错了。

还有一个必须提前确认的细节：你的站点有没有登录态和个性化内容。如果有「登录后显示用户名」「购物车数量」这类按用户变化的内容，整页缓存会把 A 用户的页面返回给 B 用户，这不仅是体验问题，还可能造成信息泄露。解决办法有两种：把个性化内容改成前端异步请求（页面 HTML 缓存，用户信息走接口），或者在 CDN 规则里对带 Cookie 的请求直接绕过缓存。

# 用 Nginx 在源站侧做一层保险：带 Cookie 的请求不返回 CDN 缓存副本
set $skip_cache 0;
if ($http_cookie ~* "wp-.*|PHPSESSID|sessionid") { set $skip_cache 1; }
add_header X-Cache-Status $skip_cache always;

在源站加这层判断的意义在于：即使 CDN 规则配错，源站也不会把个性化内容打成公共缓存。双保险的代价只有几行配置，收益是避免一次可能很严重的事故。

六、数据库调优：把 2 秒的查询变成 20ms

打开慢的站点里，超过一半的 TTFB 是花在数据库上。PHP 的 max_execution_time 默认 30 秒，慢查询不会报错，只会让你干等——这是最坏的情况，因为它把问题藏起来了。

第一步：先找到慢在哪。

# 打开慢查询日志
mysql -u root -p -e "SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';"

# 看日志里的前 20 条
tail -n 200 /var/log/mysql/slow.log | less

第二步：改配置。 MySQL 或 MariaDB 的关键参数，针对 2GB 到 4GB 内存的机器：

[mysqld]
innodb_buffer_pool_size = 1G      # 内存的 50% 到 60%
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2 # 非金融场景可用 2，牺牲少量持久性换 IO 性能
max_connections = 100             # 2GB 内存机器不要超过 100
tmp_table_size = 64M
max_allowed_packet = 16M
slow_query_log = ON
long_query_time = 0.5

innodb_buffer_pool_size 是 InnoDB 的内存池，它决定了数据库能把多少索引和数据页缓存在内存里。这个值如果太小，查询就要去读磁盘，随机 IO 会把延迟拉高一个数量级。经验值是物理内存的 50% 到 60%。

第三步：给慢查询加索引。 找到 EXPLAIN 输出里 type 是 ALL（全表扫描）的查询，那就是缺索引。

-- WordPress 后台首页最常见的问题查询
EXPLAIN SELECT SQL_NO_CACHE p.ID, p.post_title, p.post_date, t.name
FROM wp_posts p
INNER JOIN wp_term_relationships tr ON p.ID = tr.object_id
INNER JOIN wp_term_taxonomy tt ON tr.term_taxonomy_id = tt.term_taxonomy_id
INNER JOIN wp_terms t ON tt.term_id = t.term_id
WHERE p.post_status = 'publish' AND p.post_type = 'post'
AND tt.taxonomy = 'category' AND t.name = '未分类'
ORDER BY p.post_date DESC LIMIT 10;

-- 根据 EXPLAIN 结果补索引
ALTER TABLE wp_posts ADD INDEX idx_post_type_status_date (post_type, post_status, post_date);
ALTER TABLE wp_term_relationships ADD INDEX idx_object_id (object_id);

第四步：关掉 WordPress 的定时任务和修订历史。 这两个是 WordPress 慢查询的经典来源。

# 在 wp-config.php 里加，禁用不需要的功能
define('DISABLE_WP_CRON', true);
define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 120);
define('EMPTY_TRASH_DAYS', 7);

DISABLE_WP_CRON 尤其值得开——WordPress 的伪 cron 是访客访问时才触发的，一个访问量低的站可能几小时都不跑一次任务，而一旦触发就是一大堆数据库写入，正好撞在流量高峰上。正确做法是关掉它，改用系统 crontab 定时跑：

# 加到 root 的 crontab
*/15 * * * * cd /var/www/html && wp cron event run --due-now --quiet

第五步：加一层 Redis 或 Memcached 存对象缓存。 这一步能直接消掉大部分重复查询。WordPress 有现成的对象缓存插件（Redis Object Cache），配置好后，未命中数据库的请求直接读内存。

# 检查 Redis 是否真的在用
redis-cli ping
redis-cli info memory | grep used_memory_human
# 看命中率
redis-cli info stats | grep keyspace_hits

查 vollcloud 在售套餐与库存

命中率低于 80% 说明缓存键设计有问题（键太多或 TTL 太短），可以先别急着加更多缓存层。

七、Web 服务器与 PHP 进程：并发参数配错了就是慢

很多人只监控 CPU 和内存，忽略了「服务进程数」这个维度。PHP-FPM 的 worker 数量如果配置不合理，表现出来就是「单个人访问很快，多个人访问就变慢」。

原因在于：PHP-FPM 默认用 pm = dynamic 模式，启动少量 worker，按需扩到 pm.max_children，达到上限后新请求排队等待（Nginx 会返回 502 或超时）。如果 max_children 配得太小，队列在高峰时排几十个请求，每个请求 50ms，排在最后的用户就要等好几秒。

算一下怎么配。 经验公式是：

pm.max_children ≈ (物理内存 × 70%) ÷ (单个 PHP worker 常驻内存)

单个 worker 内存怎么测？看 PHP-FPM 的状态页，或用 ps 直接量：

# 找出 PHP-FPM 进程的平均 RSS
ps -o rss= -C php-fpm | awk '{s+=$1; n++} END {printf "worker 平均 RSS: %.0f MB, 共 %d 个\n", s/n/1024, n}'

# 2GB 内存机器：可用内存 2048×0.7 = 1433MB
# 若单个 worker 占 80MB → max_children = 1433/80 ≈ 17，取 15 留余量

也可以直接开状态页看实时数据：

location /php-fpm-status {
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    allow 127.0.0.1;
    deny all;
}

; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 15
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500

pm.max_requests = 500 那一行别忽略：它规定 worker 处理完 500 个请求后自动重启，用来回收 PHP 内存泄漏累积的内存。设成 0（不限制）的话，跑到第几天机器就会因为内存泄漏而越来越慢，这是典型的「服务器跑久了就卡」的隐形原因。

Nginx 侧同样有坑。 默认 worker_processes auto 没问题，但 worker_connections 默认 1024 在高并发下会先耗尽。还有 keepalive_timeout 默认 75 秒，空闲连接长时间挂着不放会白占文件描述符。

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 8192;
    multi_accept on;
}

http {
    keepalive_timeout 30;
    keepalive_requests 1000;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    gzip on;
    fastcgi_keep_conn on;
}

查看 kdatacenter 当前月价与库存

tcp_nodelay on 和 fastcgi_keep_conn on 这两个尤其值得开——前者关闭 Nagle 算法，小响应立刻发出去；后者让 Nginx 和 PHP-FPM 之间复用连接，省掉每次请求的握手开销。这两项对 TTFB 的改善是毫秒级的，但完全免费。

八、什么情况下不该选韩国VPS：四类明确的坏场景

这一节要说清楚：韩国VPS 有明确的地理优势，但它不是万能解。以下四种情况，韩国节点是错误的选择，依据全部是机房位置、线路类型、计费方式、IP 资源这些公开事实，与商家水平无关。

场景一：你的用户主要在中国大陆西部。 韩国到中国大陆的国际出口带宽有限，晚高峰时段（北京时间 20:00 到 23:00）跨境链路拥塞是物理层面的。西部地区的用户走韩国路径，光纤路径比走国内节点多出上千公里，绕路成本更高。替代方案：国内有备案需求的站点改用国内云服务器做静态分发，动态 API 保留在海外；没有备案需求又在意大陆体验的，先实测国内三大运营商到目标机房的三网延迟再决定。

场景二：你的业务需要大量原生住宅 IP 或需要频繁换 IP。 韩国节点的 IP 资源规模普遍不大，广播 IP 的比例在各个区域里算紧张的。替代方案：站群、账号矩阵、多 IP 采集这类需求，直接看明确标注「多 IP 可选」「可付费换 IP」的服务商，并且在第一次购买前就问清楚换 IP 的价格和冷却时间。

场景三：你的带宽需求是持续大流量（比如每月 10TB 以上）且以出站为主。 韩国机房面向大陆方向的国际带宽通常是按量或按套餐封顶的，超出后的处理方式（限速到多少、是否按 GB 计费、单价多少）差异极大。替代方案：先用真实业务量算清楚「月出站流量 ÷ 需要的峰值带宽」，然后优先看带大流量额度的美西或日本节点，再看是否有不限流量但带宽受限的选项。

场景四：你的站点是纯后台系统、没有公开网页，且访客在国内。 这种情况用不着地域优势，多付的溢价换不回任何东西，同时还要承担跨境链路的波动。替代方案：按 CPU 和内存单价挑最划算的一档即可，前面那张单位成本表就是干这个用的——从 1GB 到 24GB 内存，每 GB 单价能降 85%。

查 cloudcone 在售套餐与库存

# 判断你的业务到底在哪个象限：先量真实的出站流量和访问分布
cat /proc/net/dev | awk 'NR>2 {split($1,a,":"); printf "%-10s 收 %8.2f GB  发 %8.2f GB\n", a[1], $2/1073741824, $10/1073741824}'

# 按访客 IP 段统计请求分布（取前三段）
sudo awk '{print $1}' /var/log/nginx/access.log | cut -d. -f1,2,3 | sort | uniq -c | sort -rn | head -10

九、常见误区：这几个动作只会更慢

误区一：只加 CPU 不加内存。 PHP 和数据库都是吃内存的，CPU 核数翻倍而内存不变，只会更快地把内存耗光，然后开始 swap，延迟从 50ms 变成 800ms。加内存的边际收益通常大于加 CPU。

误区二：重启大法。 网站一慢就 reboot，这会让 Opcache 清空、数据库连接池重建、所有缓存失效，第一个访问者承担全部冷启动成本。该做的是找到慢的真正原因，而不是重置现场。

误区三：把所有东西都装进同一台机器。 数据库、PHP、邮件服务、爬虫任务挤在一台 2GB 机器上，爬虫把内存吃满，整站跟着倒下。至少把定时任务和邮件发送隔离出去，否则你的爬虫就是你的定时炸弹。

误区四：把 worker_connections 调得很大就以为能扛并发。 这只是把排队从应用层挪到了连接层，文件描述符耗尽时 Nginx 会直接拒绝连接。真正的并发能力取决于内存能养多少 PHP 进程和数据库连接，也就是第七节那个公式。

误区五：以为开了缓存就万事大吉，从不清缓存。 缓存不失效，就永远不知道它是不是还在正常工作。每次发版后手动清一次缓存，并检查命中率——如果清完立刻掉到 50% 以下，说明缓存键设计有问题。

digitalocean 官网机型与实时报价

误区六：拿单次测速结果下结论。 网络有抖动，凌晨和晚高峰的结果可能差一倍。每个指标至少测 10 次取中位数，且要分别在工作时段和晚高峰各测一轮。

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

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

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

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

十、常见问题

韩国VPS打开慢，换个更高配置的机器能解决吗？ 不能一概而论。先按第一节的方法分段测量：如果 TTFB 已经低于 100ms 而总时长很大，瓶颈在页面体积和前端资源，升配完全无效，做压缩和缓存才是正解；只有当 TTFB 超过 300ms 且内存谷值超过 40% 时，升配才值得考虑。反过来说，盲目升配最常见的结局是花了钱，TTFB 一点没变。

用 CDN 之后韩国VPS还有意义吗？ 有，但意义变了。CDN 解决的是静态资源就近分发和抗波动，不解决动态请求的计算和数据往返。如果你的业务是动态 API 或登录态页面，源站仍然必须是离用户近的机房，CDN 只是把静态部分卸走。韩国节点对东北亚方向的动态请求仍然有延迟优势。

开启 Gzip 会不会影响 SEO？ 不会。搜索引擎的爬虫能正常处理 gzip 传输的内容，主流爬虫都支持 Accept-Encoding: gzip。需要注意的是不要对图片和已经压缩过的格式（PNG、JPEG、WebP、MP4）再压缩，那些是无效功。

Opcache 的内存设置多少合适？ 2GB 内存机器设 128MB，4GB 设 256MB，8GB 及以上设 512MB。判断依据是 opcache.memory_consumption 配的值加上实际占用不会超过总内存的 15%，并且 opcache.max_accelerated_files 要大于你所有 PHP 文件的总数，否则部分文件不会被缓存。

慢查询日志开多大算合适？ long_query_time 设 0.5 秒是一个好起点——比这更短的查询通常不是体验瓶颈。日志文件会增长，注意配置轮转，否则几百 MB 的日志文件本身会拖慢磁盘 IO。

怎么知道优化到底有没有效果？ 建立基线、优化、再测，两次都用同一套命令、同一个时段、至少 10 次取中位数。把 TTFB、页面总大小、资源数、内存谷值这四个数记成一张表前后对比。没有基线的优化等于没有优化，因为你会分不清是优化起效还是网络恰好顺畅。

Windows 建站和 Linux 建站优化思路一样吗？ 差别不大，但具体命令不同。本文给的 Nginx、PHP-FPM、MySQL 命令都是 Linux 下的；Windows 上的 IIS + PHP 或 Windows + Nginx 组合，思路一致（压缩、缓存头、Opcache、数据库索引这四条完全通用），但需要换成对应的 Windows 工具，且文件描述符与进程管理的概念在 Windows 上不适用。

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