日本VPS打开慢怎么优化

一、页面打开慢，先把时间花在哪一段测出来

优化之前必须先定位，否则所有努力都是猜。页面打开的总耗时不是一个数字，是四段相加：

阶段	含义	典型占比	该由谁负责
DNS 解析	域名解析成 IP	20–150 毫秒	DNS 服务商、TTL
TCP + TLS 握手	建连与证书协商	50–300 毫秒	线路、是否启用 TLS 1.3、会话复用
服务器首字节（TTFB）	收到请求到吐出第一个字节	100–800 毫秒	应用代码、数据库、缓存
内容下载与渲染	HTML、JS、CSS、图片	500–3000 毫秒	资源体积、CDN、缓存头

zenlayer 官网机型与实时报价

用一条命令就能拿到前两段的真实数字：

curl -o /dev/null -s -w "
DNS解析: %{time_namelookup}s
TCP连接: %{time_connect}s
TLS握手: %{time_appconnect}s
首字节:  %{time_starttransfer}s
总耗时:  %{time_total}s
下载速度: %{speed_download} B/s
" https://你的域名

测的时候必须在外部网络做，不要在服务器本机测。在本机测，time_namelookup 几乎为零，time_connect 不到 1 毫秒，你看到的数字跟真实用户完全无关。正确做法是从自己家的电脑或者另一台机器上测，且分别测早高峰和凌晨两个时段。

读这组数字的规则：

- time_namelookup 大于 200 毫秒——问题在 DNS。检查解析器、TTL、以及是否有 IPv6 记录指向不可达地址。

- time_appconnect 减去 time_connect 大于 200 毫秒——问题在 TLS 握手。跨境链路的往返延迟和证书链长度都会放大这一段。

- time_starttransfer 大于 300 毫秒——问题在服务器端，去查应用和数据库。

- time_total 减去 time_starttransfer 很大——问题在内容体积和带宽。

还要加测两个数字才算完整：首屏渲染时间和完整加载时间。curl 只能测到网络层，看不到浏览器执行 JavaScript 之后的渲染表现。这两个数字要靠浏览器开发者工具的 Network 面板读：找 Finish 与 DOMContentLoaded 的时间差就是首屏渲染，找 Load 的时间就是完整加载。

完整的诊断顺序应该是这样的：先在外部网络跑一遍 curl 拿到四个时间段的数字，再用浏览器的 Network 面板看瀑布图确认瓶颈落在哪个资源上，最后去服务器上看应用和数据库的指标。顺序不能乱——先测后改，改完再测，每次只改一项，这样才知道收益来自哪里。

最后一条诊断纪律：一次只改一个变量。同时改 gzip、OPcache 和数据库索引，然后发现 TTFB 从 400 毫秒降到 200 毫秒，你并不知道是哪一项起了作用，下次遇到新问题也就没有可复用的经验。改一项、测一次、记一次，这个循环看起来慢，实际比盲目优化快得多。

一个反常识的事实：多数人以为「慢」是服务器性能问题，实际上一半以上的案例是线路问题。一台配置很高的日本机器，如果回程走的是绕路的普通国际线路，用户访问的首字节照样在 1 秒以上。所以在动手优化代码之前，先确认你的回程线路是什么类型。公开资料里 backwaves 的日本产品线接入联通 9929 / AS10099 精品网，digitalvirt 的日本东京节点提供 9929、CN2 GIA、CMIN2 等回国优化线路选项，vollcloud 的公开简介里说明其香港 CMIN2 产品去程 163、回程 CMI 直连——这类线路信息在买机器时就能查到，是选型阶段的事，不是优化阶段能补救的。

二、TTFB 和首屏：先解决服务器端那部分

TTFB 是最容易优化、也最容易被忽略的一段。它指的是从请求发出到服务器返回第一个字节的时间。

第一步：开 PHP OPcache。这是 PHP 站点收益最大、改动最小的一步。没有 OPcache 的 PHP 每次请求都要重新解析脚本文件、重新编译。

# Debian/Ubuntu
sudo apt install php-opcache
# 检查是否启用
php -i | grep -E "opcache.enable|opcache.memory_consumption|opcache.max_accelerated_files"

关键参数：

; /etc/php/8.2/fpm/conf.d/99-opcache.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=60

opcache.validate_timestamps=1 且 revalidate_freq=60 这个组合值得解释：开启时间戳校验意味着代码改动能生效，但每 60 秒才检查一次文件是否变化。这个间隔把「每个请求都 stat 文件」的开销降到了每分钟一次。生产环境代码不常改的情况下，把 validate_timestamps 设为 0 并在部署时重启 PHP-FPM，性能会更好，但改代码后必须记得重启，否则改动不生效——这个坑很多人踩过。

第二步：调 PHP-FPM 的进程数。默认配置的进程数是按小机器设的，在 4 GB 内存的机器上通常偏少。

# 查看当前配置
grep -E "pm.max_children|pm.start_servers|pm.min_spare_servers|pm.max_spare_servers" /etc/php/8.2/fpm/pool.d/www.conf

调整的原则是：每个 worker 按 30 到 50 MB 内存估算。4 GB 机器减去系统和数据库占用，留给 PHP-FPM 大约 1.5 GB，那么 pm.max_children 设到 30 到 40 比较合理。低于这个数，并发一高就排队；高于这个数，会因为内存耗尽被 OOM killer 干掉。

pm = dynamic
pm.max_children = 32
pm.start_servers = 8
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500

pm.max_requests = 500 这一行是防内存泄漏的：每个 worker 处理完 500 个请求就重启，把累积的内存泄漏清掉。PHP 应用跑久了变慢、最后 OOM，八成是没设这个参数。

第三步：数据库连接池。PHP 每次请求都新建数据库连接，在高并发下连接建立的开销会很明显，而且容易撞上 max_connections 上限。

# 看当前连接数上限和实际状态
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected';"

对 WordPress 这类应用，可以启用持久连接（wp-config.php 里加 define('WP_USE_EXT_OBJECT_CACHE', true) 并配合 Redis），或者在 Nginx 前加一层 PHP-FPM 之外的连接池。更重要的是给数据库加索引——这是下一节的内容。

第四步：用 Redis 或 Memcached 做对象缓存。如果你的站点读多写少（博客、商城、内容站），这一项的收益通常排第二。

# 安装 Redis
sudo apt install redis-server
# 在 wp-config.php 里定义缓存对象
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

查 justg 在售套餐与库存

对象缓存能省掉的是数据库查询，不是 PHP 执行时间。一个典型的 WordPress 页面会发起 30 到 80 次数据库查询，加上对象缓存后能降到 5 到 15 次。TTFB 从 400 毫秒降到 150 毫秒是常见的结果。

三、静态资源压缩与浏览器缓存：改动最小收益最大

这一节的两项配置都是纯 Nginx 层面的，不需要改代码，收益却非常直接。

第一项：gzip 压缩。HTML、CSS、JS、JSON 文本类资源压缩后通常能降到原体积的四分之一左右。

gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 512;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml+rss
    application/rss+xml
    font/woff
    font/woff2
    image/svg+xml;

gzip_min_length 512 这一行别省。小于 512 字节的响应压缩后反而变大，因为压缩头本身有开销，还占用了 CPU。gzip_comp_level 6 是压缩率和 CPU 的平衡点，调到 9 最多再省 3% 体积，但 CPU 消耗翻倍——对流量大而 CPU 紧张的机器是亏的。

注意 gzip_types 里没有 image/png 和 image/jpeg。图片已经是压缩格式，再 gzip 一遍几乎无效却要付出 CPU。这两个是最常被错误加进去的类型。

第二项：浏览器缓存头。这决定了用户第二次访问时有多少资源根本不用下载。

# 静态资源长缓存，带内容哈希的文件名
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|webp)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

# HTML 不长缓存，保证更新能立刻生效
location / {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

为什么要分开设置？HTML 里引用的是带哈希的静态文件名（app.a1b2c3.js），内容变了文件名就变，所以可以放心长缓存；而 HTML 本身每次都可能包含新的时间戳、动态内容，缓存久了用户看到的就是旧页面。这个「HTML 不缓存、静态资源长缓存」是现代前端部署的标准做法。

第三项：不要忘记压缩响应体之外的两件事。一是开启 HTTP/2，浏览器对同一域名的并发请求数从 6 个提升到 100 个，页面上的几十个资源请求能省掉大量往返延迟。

listen 443 ssl http2;

二是开 keepalive，避免每个请求都重建 TCP 连接。

keepalive_timeout 65;
keepalive_requests 1000;

第四项：合并和延迟加载。这个要改代码但收益大：把十几个 CSS 和 JS 合并成一个文件，减少请求数；把首屏用不到的 JS 设为 defer 或 async；图片用 loading="lazy"。

<!-- 非首屏图片延迟加载 -->

<!-- JS 延迟执行，不阻塞 HTML 解析 -->
<script src="/app.js" defer></script>

查看 zgovps 当前月价与库存

加 width 和 height 属性也有实际作用——浏览器据此预留空间，避免图片加载完成时的页面跳动（CLS）。这对移动端的影响尤其明显。

四、CDN 到底要不要上，什么情况下值得

CDN 不是万能药。它解决的是「静态资源离用户太远」的问题，解决不了「服务器自己处理得慢」。

先算一笔账，判断值不值得：

假设你的站点首屏有 2 MB 的静态资源，用户的下载速度是 2 MB/s（常见的家用宽带），那这部分耗时是 1 秒。如果你的访客主要在国内，而服务器在东京，跨境链路的实际单线程速度经常只有 300 KB/s 到 1 MB/s，那么同样 2 MB 要 2 到 6.7 秒。CDN 把这个资源推到离用户更近的节点，耗时能压到 200 到 500 毫秒。这就是 CDN 的价值来源。

什么情况下值得上 CDN：

场景	值不值得	原因
静态资源占比高（图片、JS、CSS）	值得	直接命中 CDN 的加速范围
访客分散在全国各地	值得	边缘节点覆盖比单点机房好得多
视频、下载、大文件	值得	带宽成本和时间双重收益
后台管理页面	不必	用的人少，没有加速价值
动态接口（需要实时数据）	部分	要做缓存键设计，否则会缓存脏数据
已经用了很好的静态托管	不必	重复加速

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

CDN 用在动态内容上的三个坑：

第一个坑是缓存键没设计好。默认按 URL 缓存，但很多动态接口的返回内容取决于请求头、Cookie、用户身份。按 URL 缓存会导致 A 用户看到 B 用户的数据。

第二个坑是缓存没设过期时间或者设成了永久。内容更新了但 CDN 还在返回旧版本，排查起来极其痛苦。更新内容后必须主动刷新缓存。

第三个坑是源站被 CDN 挡在后面，源站 IP 泄露风险下降但真实 IP 仍可通过解析记录找到。这一点要配合源站只允许 CDN 回源访问来彻底解决。

# 源站只允许 CDN 的回源 IP 访问，其他一律拒绝
# 具体 IP 段以你的 CDN 服务商文档为准
set_real_ip_from 你的CDN回源IP段;
real_ip_header X-Forwarded-For;

如果你的站点有登录态、会话、个性化内容，务必要把这类路径排除在 CDN 缓存之外。

CDN 还有一个经常被忽略的配置项：回源 HOST 与回源协议。如果源站是 HTTPS，CDN 回源也应该是 HTTPS，否则中间有一段明文传输；如果你的源站用的是 IP 直连而域名解析到别处，回源 HOST 配错会拿到错误的站点内容。这两个配置在首次接入时最容易出问题，表现是「CDN 加速之后偶发跳到别的站」或者「证书报错」。

再算一笔带宽账。CDN 缓存命中时，流量从边缘节点出，不消耗源站带宽，这部分直接省掉了源站的流量计费。缓存未命中时，流量仍然要回源拉取，源站的出站流量照算。所以 CDN 的带宽成本节省量约等于缓存命中率乘以总流量。如果你的套餐按流量计费且单价高（各档位从 3.41 美元/TB 到 19.99 美元/TB 都有），这个节省是可观的；如果你的套餐带宽上限固定不按流量计费，那这笔账就变成了「固定成本换固定成本」，纯看加速效果值不值。

关于要不要用第三方 CDN 还是自建反代：自建反代（比如在源站前面放一台带宽大的机器做缓存层）成本低、可控性强，但只有在你的网络本身带宽足够时才有效。如果源站的带宽上限本来就不够，加一层反代只是把瓶颈往后挪。判断依据是源站的带宽上限和实测下载速度的差距——如果实测已经贴着上限，那就是源站带宽不足，得换机器或者用真正的 CDN 节点。

还有一条常被忽略的账：CDN 会增加一跳。用户到边缘节点是快的，边缘节点回源是慢的。对于「缓存未命中」的那一次请求，CDN 反而比直连多了一段延迟。所以 CDN 的加速效果取决于命中率。静态资源命中率能到 90% 以上，动态页面命中率通常不到 10%，甚至为 0。

五、数据库调优：查询慢是页面慢的常见真凶

一个页面慢，先别急着调 Nginx，去看数据库。一个没有优化的 WordPress 站，TTFB 里七成时间都在等数据库。

第一步：找出慢查询。开启慢查询日志。

# /etc/mysql/mariadb.conf.d/50-server.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5

# 分析慢查询日志，按耗时排序
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

long_query_time = 0.5 表示超过 0.5 秒的查询记进日志。这个值定得很关键——定成 10 秒你只能看到最极端的情况，定成 0.01 秒日志会大到没法看。0.5 秒是个合适的起点。

第二步：看有没有缺索引。这是最高频的问题。

# 用 EXPLAIN 看查询的执行计划
EXPLAIN SELECT * FROM wp_posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY post_date DESC LIMIT 10;

看 EXPLAIN 结果的三个关键点：

- type 列：ALL 表示全表扫描，几万行的表上这是灾难；ref 表示用了索引；const 或 system 表示最优。

- key 列：显示实际用到的索引。如果是 NULL 而 type 是 ALL，就是缺索引。

- rows 列：预估扫描行数。这个数字远大于实际返回行数，说明索引选择性差。

-- 补上缺失的索引
ALTER TABLE wp_posts ADD INDEX idx_status_type_date (post_status, post_type, post_date);

索引顺序的原则是：等值条件的列在前，范围条件的列在后。上面这个索引里，post_status 和 post_type 都是等值条件，post_date 是范围条件，所以顺序是这样排的。

第三步：改掉 N+1 查询。这是应用层最常见的性能杀手。表现是慢日志里同一个查询出现几十次，每次都很快但加起来很慢。

-- N+1 的典型形态：先查列表，再对每个 id 单独查一次
SELECT * FROM wp_posts WHERE ID IN (1, 5, 9, 12, 18);
-- 而不是
SELECT * FROM wp_posts WHERE ID = 1;
SELECT * FROM wp_posts WHERE ID = 5;
-- ... 重复几十次

用 WordPress 的话，预加载（WP_Query 的 posts 参数）或者对象缓存能直接解决这一类问题。

第四步：调整 InnoDB 缓冲池。内存够的话，缓冲池应该能装下大部分热点数据。

# /etc/mysql/mariadb.conf.d/50-server.cnf
innodb_buffer_pool_size = 1G
innodb_log_buffer_size = 32M
innodb_flush_log_at_trx_commit = 2

innodb_buffer_pool_size 的设定原则：专用数据库服务器给到物理内存的 50% 到 70%；和网站共用一台机器时给 25% 到 40%。在 4 GB 内存的机器上跑网站加数据库，给 1 GB 是合理的。

innodb_flush_log_at_trx_commit = 2 这个参数要理解清楚它的含义：设为 1 是最安全的（每次提交都写盘），设为 2 是每秒写一次盘，MySQL 崩溃可能丢失最后一秒的事务。对博客和展示型站点，这个取舍是划算的；对订单、支付这类不能丢数据的业务，保持 1。不要盲目照抄别人的配置。

第五步：清理碎片和优化表。

OPTIMIZE TABLE wp_posts;

查看 backwaves 当前月价与库存

第六步：定期检查表结构。WordPress 这类应用会积累大量 wp_postmeta 之类的表，某些查询在数据量大后会明显变慢。

六、图片优化：往往是最容易拿到的收益

一个典型页面的体积构成里，图片往往占 50% 到 70%。如果你的站点有大量未优化的原图，优化图片的收益通常高于所有代码层优化之和。

第一步：确认图片尺寸和页面实际显示尺寸匹配。一张 3000 像素宽的原图被塞进 300 像素的容器，浏览器要下载完整原图再缩放，浪费了十倍的流量。

# 找出体积最大的图片
find /var/www/html/wp-content/uploads -type f \( -iname "*.jpg" -o -iname "*.png" \) -size +200k -exec ls -lh {} \; | head -20

第二步：转成现代格式。WebP 通常比 JPEG 小 25% 到 35%，AVIF 还能再小 20% 左右。

# 使用 cwebp 批量转换
sudo apt install webp
find /var/www/html/wp-content/uploads -name "*.jpg" -exec cwebp -q 80 -m 6 {} -o {}.webp \;

# 用 WebP 插件让 WordPress 自动输出 WebP

第三步：按需加载和懒加载。首屏之外的图片用 loading="lazy"，首屏图片反过来用 loading="eager" 加上 fetchpriority="high"。

     loading="eager" fetchpriority="high">

第四步：用 CDN 的图片处理能力。如果已经上了 CDN，让它自动做格式转换、尺寸裁剪、质量压缩，你只管上传原图。这一步的价值是「一次配置，长期受益」。

查 digitalvirt 在售套餐与库存

第五步：给图片设置正确的缓存头。图片 URL 一般不变，可以设很长的缓存期。但要注意更新图片后要换文件名，否则用户一直拿旧的。

七、OS 与内核层面的调优

这一层收益不如上面几层，但有几项是低成本高回报的。

第一项：BBR 拥塞控制算法。Linux 默认的 CUBIC 算法在高带宽高延迟链路上表现不佳，BBR（基于瓶颈带宽和往返时延的拥塞控制）在跨境链路上通常有 20% 到 50% 的吞吐提升。

# 检查当前算法
sysctl net.ipv4.tcp_congestion_control
# 启用 BBR
modprobe tcp_bbr
echo "tcp_bbr" >> /etc/modules-load.d/bbr.conf
sysctl -w net.ipv4.tcp_congestion_control=bbr
echo "net.ipv4.tcp_congestion_control = bbr" >> /etc/sysctl.conf

BBR 对跨境链路的帮助最明显，这正是日本节点的典型场景。启用后重测一遍 time_starttransfer 和 speed_download，把前后数字记下来。

第二项：文件描述符上限。高并发时 Nginx 会报 "too many open files"。

# 查看当前值
ulimit -n
# 临时提高
ulimit -n 65535
# 永久生效
echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf

第三项：TCP 参数。这几个调整能让长连接和高并发场景更稳：

cat >> /etc/sysctl.conf << 'EOF'
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
EOF
sysctl -p

net.ipv4.tcp_tw_reuse = 1 允许重用 TIME_WAIT 状态的连接，对频繁建立短连接的站点（尤其是有大量 API 请求的）能显著减少端口耗尽的问题。

第四项：swap 的取舍。内存小于 2 GB 的机器，配置 1 GB 到 2 GB 的 swap 可以避免 OOM 导致的进程被杀。但要清楚 swap 的代价：一旦开始用 swap，响应延迟会从毫秒级跳到几百毫秒甚至秒级。所以 swap 是保险，不是性能方案。内存充足的机器可以直接关掉 swap，让 OOM killer 快速暴露问题而不是让系统慢慢拖死。

# 查看是否在用 swap
free -m
# 临时关闭
sudo swapoff -a

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

第五项：定期更新系统和内核。Linux 内核的 TCP 栈在 5.x 系列里有多轮实质改进，安全补丁也在持续更新。但更新要分两步：先在备用机器验证，重启窗口选在低峰，并保留一个回滚用的旧内核条目。

八、测速工具怎么用，测出来的数字才有意义

优化效果的度量要靠工具，不能靠感觉。

工具一：WebPageTest。它从真实浏览器、多地区、多网络条件下加载页面，给出完整的 waterfall 图和视频录制。这是唯一能看到「用户实际看到了什么」的工具。免费版可以手动选区域和连接速度。

工具二：curl。做前后对比最快的方式。

# 连续测五次取中间值，避免单次抖动干扰
for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s  总计: %{time_total}s  大小: %{size_download}B\n" https://你的域名
  sleep 1
done

取中间值而不是平均值。平均值会被偶发的网络抖动拉偏，而中间值（排序后的第三个）更能代表稳定表现。

工具三：GTmetrix / PageSpeed Insights。给出 Lighthouse 评分，涵盖 FCP（首屏内容绘制）、LCP（最大内容绘制）、TBT（总阻塞时间）、CLS（累积布局偏移）四个核心指标。

这四个指标的合格线：

指标	含义	良好	需改进
FCP	首屏内容绘制	< 1.8 秒	> 3.0 秒
LCP	最大内容绘制	< 2.5 秒	> 4.0 秒
TBT	总阻塞时间	< 200 毫秒	> 600 毫秒
CLS	累积布局偏移	< 0.1	> 0.25

查看 hostkvm 当前月价与库存

这些是行业通用的 Web 性能标准（Google 制定的 Core Web Vitals 阈值），可以直接作为验收线。

工具四：curl 测首字节的专用方式。只看 TTFB 的时候用这个，输出更干净：

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

测速的三个纪律：

第一，在外部网络测。在服务器本机测出来的数字没有参考价值。

第二，早晚高峰各测一轮。跨境线路的晚高峰劣化可能把首字节从 150 毫秒拉到 800 毫秒，只测凌晨会得到过于乐观的结论。

第三，每一步优化后都要重测并记录。不记录就不知道哪一步有效，也就没有优先级。

九、按收益排序的优化清单

把所有手段按「收益 ÷ 成本」排一遍，这个顺序是执行依据。

第一梯队（立刻做，零风险，收益最大）：

优化项	典型收益	耗时
开启 gzip 压缩	传输量降 60%–75%	10 分钟
配置浏览器缓存头	二次访问静态资源零下载	10 分钟
启用 HTTP/2 + keepalive	并发请求数从 6 提升到 100	5 分钟
开启 PHP OPcache	TTFB 降 30%–50%	10 分钟
设置 pm.max_requests	消除长期运行后的内存泄漏	5 分钟

查 vollcloud 在售套餐与库存

第二梯队（收益明显，需要一点配置工作）：

优化项	典型收益	耗时
启用 BBR 拥塞控制	跨境链路吞吐提升 20%–50%	15 分钟
加 Redis 对象缓存	数据库查询减少 60%–80%	1–2 小时
数据库补索引	慢查询提升一个数量级	2–4 小时
图片转 WebP + 懒加载	页面体积降 40%–60%	2–4 小时
调整 InnoDB 缓冲池	热点数据不再落盘	30 分钟

第三梯队（收益大但有取舍）：

优化项	收益	取舍
上 CDN	静态资源加载时间降 50%–80%	增加一跳、增加成本、缓存设计复杂
换更好的回程线路	首字节可能从 800 毫秒降到 150 毫秒	需要换机器、涉及数据迁移
应用层重写	性能上限最高	开发成本高、周期长

第四梯队（先别做）：

盲目换更高配置的机器、为了「感觉快」重装系统、把所有能开的实验性内核参数都打开。前两项在没有定位问题之前是浪费钱，第三项可能降低稳定性。

关于第四梯队里的第一项补一句：换机器确实有效，但前提是你已经确认瓶颈在机器上——也就是 top 显示 CPU 长期跑满、或者磁盘 IO 的 await 值很高。如果 CPU 使用率只有 20%，换双倍配置的机器，首字节一点都不会变。

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

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

只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 zenlayer 当前机型与价格
做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 justg 当前机型与价格
主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 zgovps 当前机型与价格
只是开发测试、临时用：按小时或月付，用完就删，别买年付。看景文互联当前机型与价格

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

十、常见问题

日本VPS打开慢，是服务器配置不够还是线路问题，怎么判断？

看两个数字。第一，time_starttransfer 大于 300 毫秒说明服务器端慢，去查 top 和慢查询日志。第二，在服务器本机执行 curl 测出的 time_starttransfer 如果只有几毫秒，但外部测出来是几百毫秒，差距就在链路上。本机快、外部慢，答案就是线路不是配置。

开了 gzip 还是慢，问题在哪？

先确认压缩真的生效了：curl -H "Accept-Encoding: gzip" -I https://你的域名，看响应头里有没有 Content-Encoding: gzip。如果没有，检查 gzip_types 里有没有这个文件的类型。另外注意 gzip_min_length，小于 512 字节的不压缩。还要确认压缩后的体积确实小了，用 curl -w "%{size_download}" 对比压缩前后的下载字节数。

首字节时间怎么压到 300 毫秒以内？

按这个顺序试：确认 OPcache 已启用（php -i | grep opcache.enable）；把 pm.max_children 调到内存允许的上限；给数据库补上缺失的索引（用 EXPLAIN 看 type 是不是 ALL）；接入 Redis 对象缓存；最后启用 BBR。如果做完这些 TTFB 还是超过 300 毫秒，那瓶颈就在网络上，该考虑换线路而不是继续调代码。

CDN 会不会让网站变慢？

会，在两种情况下：一是缓存未命中时，多了一跳回源延迟；二是动态内容被错误缓存，返回了脏数据。判断方法是看缓存命中率——静态资源命中率低于 80% 说明缓存键设计有问题，动态接口要显式设置不缓存。

数据库慢查询怎么定位？

开慢查询日志（slow_query_log = 1，long_query_time = 0.5），然后用 mysqldumpslow -s t -t 10 /var/log/mysql/slow.log 按耗时排序看最慢的十条。拿到 SQL 后用 EXPLAIN 看执行计划，重点看 type 列（ALL 就是全表扫描）和 key 列（NULL 说明没用上索引）。WordPress 站点可以装 Query Monitor 插件在后台直接看。

图片优化能带来多少提升？

看图片在页面体积里的占比。如果占比 60%，转成 WebP 加上懒加载后通常能让页面总体积降 40% 到 60%，在 2 MB/s 的网络下就是从 1 秒降到 0.4 秒。但要配合尺寸匹配使用——给一张 3000 像素的原图做 WebP 压缩，收益远小于直接输出 600 像素的版本。

优化完怎么证明有效？

每一步优化前后用同一套命令、同一时段、连续测五次取中间值。记录 TTFB、总耗时、下载字节数三个数字。没有前后对比数字的优化报告是不可信的，也无法判断下一步该往哪个方向做。

日本VPS访问慢，是不是只能换机房？

不一定。先确认慢在哪一段：如果 DNS 解析慢，改 DNS 就解决；如果 TLS 握手慢，确认是否启用了 TLS 1.3 和会话复用；如果 TTFB 慢，做上面第一、二梯队的优化；如果只是内容下载慢，加缓存和压缩。只有确定是跨境线路本身的问题（首字节稳定在 500 毫秒以上且服务器端指标正常），换机房才是有效手段。

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