VPS延迟高怎么办：可行做法与顺序

一、先分清四种「延迟高」，别一上来就重装系统

多数人处理延迟问题的第一个动作是重装系统，这个动作几乎总是错的。 因为「延迟高」其实是四个完全不同的问题，它们的表现相似但根因和对策完全不同。

第一种：网络往返延迟高（网络 RTT）。 表现是 ping 的数值大。根因是物理路径：距离远、绕路、晚高峰国际出口拥塞。这一类只能靠换机房、换线路或换运营商解决，服务器内部怎么调都没用。

第二种：首字节响应慢（TTFB 高）。 表现是 ping 很快但网页打开慢。根因在服务器端：PHP 慢查询、数据库没索引、后端进程排队、磁盘 I/O 饱和。这一类重装系统没用，要靠优化应用和数据库。

第三种：页面加载慢但 TTFB 正常。 表现是首屏出来了但图片和脚本还在转圈。根因是带宽不足或资源加载顺序问题。 这一类要靠 CDN、压缩、图片优化解决。

第四种：交互操作有延迟感（点击后要等一下才有反应）。 表现是表单提交、翻页要等。根因通常是延迟叠加了应用处理时间，或者 WebSocket 这类长连接有额外开销。

这四类的区分方法很简单，跑三个命令就能定位：

# 1. 看网络往返延迟和丢包
ping -c 20 your-domain.com

# 2. 看首字节响应时间
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://your-domain.com/

# 3. 看总下载时间和实际速度
curl -o /dev/null -s -w "总计: %{time_total}s 速度: %{speed_download} B/s\n" https://your-domain.com/

对照着看结果，就能定位到哪一层：

现象	ping 延迟	TTFB	下载速度	问题所在
打不开	很高或丢包	测不出	测不出	第一层，网络路径
首屏转圈	正常	很高	正常	第二层，应用端
图片加载慢	正常	正常	很低	第三层，带宽
点击有延迟感	正常	正常	正常	第四层，交互层

查看 iwebfusion 当前月价与库存

这张表是本文的骨架。 定位错了，后面所有动作都是白费。

二、网络 RTT 高：物理路径问题怎么诊断

这一节处理第一种情况。 如果 ping 的延迟高到让你无法接受，要先确认是「一直高」还是「只在特定时段高」——这两者的解法完全不同。

先测三条基准线，区分是你的问题还是机房的问题：

# 基准 1：到网关，测本地网络质量
ping -c 20 $(ip route | awk '/default/ {print $3}')

# 基准 2：到公共 DNS
ping -c 20 8.8.8.8

# 基准 3：到你的服务器
ping -c 20 your-server-ip

怎么读这三个结果：

如果到网关的延迟就很高（超过 5 毫秒），问题在你的本地网络，跟服务器无关。家用宽带、无线 WiFi、公司网络都可能有这个问题，先解决本地。

如果到网关正常，到 8.8.8.8 正常，到服务器很高，那问题在服务器所在机房的线路。 这时候换配置、装什么都无效。

再区分是「一直高」还是「晚高峰高」。 连续测一整天，或者对比凌晨和晚上 8 点到 11 点的数据：

# 记下时间戳，方便对比
for i in $(seq 1 10); do date '+%H:%M:%S'; ping -c 5 your-server-ip | tail -2 | head -1; sleep 60; done

「一直高」意味着物理绕路，只能换机房或换线路。「晚高峰高」意味着国际出口拥塞，这种情况有一定改善空间，下面会讲办法。

还要看丢包率，这比平均延迟更能说明线路质量。 稳定丢包 1% 和「延迟从 150 跳到 400」这两种情况，哪个更糟？后者更糟。 因为 TCP 重传会让一次请求的耗时成倍放大。

关于 traceroute，要会说人话：

traceroute your-server-ip
# Windows: tracert your-server-ip

输出里每跳的星号（*）表示那一跳没回应，这不一定是故障——中间的路由器经常屏蔽 ICMP。有判断价值的是最后一跳之前的延迟跳变点。 如果从第 8 跳开始延迟从 30 毫秒变成 200 毫秒，那一跳就是瓶颈所在。

再说 ping 的一个常见误区：ping 通不代表网站快。 ICMP 优先级低，很多机房会限速或丢弃 ICMP。所以判断线路质量，mtr 比 ping 更可靠：

mtr -rw your-server-ip

mtr 会连续发包并统计每个中间节点丢包率，比单次 traceroute 信息量大得多。

最后是丢包定位的关键命令：

mtr -rw -c 100 your-server-ip

查 racknerd 在售套餐与库存

如果某跳丢包率高但后面几跳丢包率是 0，说明那一跳只是在限速 ICMP，不影响实际业务。 如果最后一跳丢包率也是 0，说明线路没问题，你的延迟问题就不在网络上，应该去查应用层。

三、晚高峰延迟高是线路拥塞吗，能做什么

这一节处理「晚上特别卡、早上正常」的情况。 这是国内访问境外服务器最典型的症状。

根因是国际出口拥塞。 中国大陆到境外的出口带宽有限，晚高峰（通常 20:00 到 23:00）排队严重。这个问题的本质是共享资源的拥塞，不是你机器的问题。

能做的是三件事，按性价比排序。

第一件：确认是不是真的是拥塞。 在早晚两个时段各测一次：

# 早上测一次，存下来
ping -c 50 your-server-ip > /tmp/ping-morning.txt
# 晚上测一次
ping -c 50 your-server-ip > /tmp/ping-evening.txt

对比两个文件的丢包率和平均延迟。如果差异明显，就是拥塞。

第二件：换个更近的机房。 这是最有效的一招。距离对延迟的影响是线性的、可预测的，而线路质量是波动的、不可控的。 商品库里有明确的机房位置信息可以参考：云途全系是香港和国内双线独立 IP，sixtynet 有 LAX（洛杉矶）、Residential、IRVINE-PRO 三个标识，RosCloud 系列的 tags 标注为「俄罗斯」。

从国内访客的角度，香港是延迟最低的选择（通常 30 到 50 毫秒），日本次之（50 到 70 毫秒），美国西海岸明显更远（140 到 180 毫秒）。 如果你现在用的是美国西海岸且主要访客在国内，换到香港机房的延迟改善会比任何软件优化都大。

第三件：换线路类型。 优化线路（CN2 GIA、联通 9929 等）的价值就在于回程走优化路由，避开晚高峰的普通国际出口拥堵。但要注意一个前提：必须是双向优化。 只有去程优化、回程走普通路的话，页面打开快了，但表单提交和文件下载在晚高峰还是会慢。付款前一定要问清楚「回程是什么线路」。

查 cloudcone 在售套餐与库存

顺便说一句：如果你现在的机器是 500 Mbps 端口的型号，晚高峰它和 2000 Mbps 端口的机器在延迟上的表现是一样的——因为拥塞发生在国际出口，不在你的网卡上。所以「升级带宽能解决延迟高」是错的理解，提升带宽解决的是第三类问题（带宽不足导致的速度慢）。

四、TTFB 高：应用端慢怎么定位

这一节处理第二种情况，ping 正常但网页打开慢。 这是最值得投入时间的一类，因为服务器上的优化空间通常远大于换机房。

第一步：拆开 TTFB 的组成。 Nginx 收到请求到返回首字节，中间经过了 Nginx 处理、后端应用处理、数据库查询。要定位到具体是哪一段，用 Nginx 的响应时间日志：

sudo nano /etc/nginx/nginx.conf

在 http 块里加上：

log_format timing '$remote_addr - $request_time $upstream_response_time $status';
access_log /var/log/nginx/timing.log timing;

然后 reload 并观察：

sudo nginx -t && sudo systemctl reload nginx
sudo tail -f /var/log/nginx/timing.log

怎么读这两个数：

$request_time 是 Nginx 收到完整请求到发出最后一个字节的总时间。$upstream_response_time 是后端返回的时间。

如果两个数都高，问题在后端应用或数据库。如果 request_time 高但 upstream_response_time 很低甚至为 0，问题在 Nginx 自身或者网络传输。

第二步：查数据库慢查询。 这几乎总是 TTFB 高的元凶：

-- MySQL 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

-- 看当前的慢查询
SHOW VARIABLES LIKE 'slow_query_log%';

如果慢查询日志里出现大量 SELECT，就要加索引。 判断索引是否有效：

EXPLAIN SELECT * FROM your_table WHERE column = 'value';

看两个字段：type 不应该是 ALL（全表扫描），key 应该有值（用上了索引）。 如果 type 是 ALL 且表有几万行，这就是 TTFB 高的直接原因。

第三步：检查 PHP-FPM 的进程数和排队情况。

sudo systemctl status php8.2-fpm
ps aux | grep -c "[p]hp-fpm"

PHP-FPM 的进程数应该和 CPU 核数匹配。 如果是 2 核机器却只跑了 2 个 worker，而并发有 50 个请求，其余 48 个在排队，这就是 TTFB 高的原因。 调整配置：

sudo nano /etc/php/8.2/fpm/pool.d/www.conf

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

改完重启并验证：

sudo systemctl restart php8.2-fpm
ps aux | grep -c "[p]hp-fpm"

第四步：检查磁盘 I/O 是否饱和。 这在机械盘上尤其常见：

iostat -x 1 5

关注 %util 这一列，接近 100 说明磁盘已经饱和。 商品库里云途 HK.DS.S 标注的 disk_type 是 SAS HDD，其他多数机型是 SSD 或 NVMe。如果你的站点是数据库密集型而硬盘是机械盘，换 SSD 带来的 TTFB 改善会比任何软件优化都大。

第五步：检查是不是被资源占满了。

top
# 或者更直观的
htop

digitalocean 官网机型与实时报价

如果 CPU 使用率长期在 90% 以上，或者内存几乎没有剩余（swap 也在用），那就不是「延迟问题」而是「机器不够用」，该升配了。

五、带宽不足：图片加载慢和下载慢怎么解决

这一节处理第三种情况：首屏正常但资源加载慢。

先确认瓶颈在哪，用这个命令测实际吞吐量：

curl -o /dev/null -s -w "速度: %{speed_download} B/s\n" https://your-domain.com/test-10mb.bin

拿这个数值和端口速率对比。 商品库里的端口速率：RosCloud 全系 500 Mbps，sixtynet 的 LAX 系列 2000 到 10000 Mbps，云途 1000 到 2000 Mbps。

换算关系：500 Mbps 端口理论上限约 62.5 MB/s，2000 Mbps 约 250 MB/s，10000 Mbps 约 1250 MB/s。

如果实测速度只有端口速率的一两成，瓶颈通常不在带宽，而在下面四个地方：

第一，源站出口被占满。 同一台机器上跑着别的吃带宽的服务（备份同步、大文件下载、批量任务）。查一下：

sudo iftop -i eth0
# 或者
sudo nethogs

第二，单连接被限制。 很多商家对单连接速度做限速。测试方法是用多线程工具测总吞吐，对比单连接：

# 单连接
curl -o /dev/null -s -w "%{speed_download}\n" https://your-domain.com/test-10mb.bin
# 多连接
aria2c -x 8 -s 8 https://your-domain.com/test-10mb.bin

两者的差距能看出单连接限制有多严重。

第三，是访客侧的问题。 访客用移动网络、跨境 WiFi、公司代理，都会让你的「慢」和他的「慢」不一样。 判断方法是在不同网络环境下测同一个 URL。

第四，跨运营商的路由质量。 电信到联通、联通到移动之间互访质量差异很大。这时最有效的解法不是换机器，而是上 CDN。

CDN 怎么用？ 把静态资源（图片、CSS、JS、字体）放到 CDN 上，让它们从离访客最近的节点分发。这一步对第三类问题的改善是最直接的，因为它同时解决了跨运营商路由和源站带宽两个问题。

自己判断要不要上 CDN 的标准很简单：如果你的页面里有超过 500 KB 的静态资源，且访客分布跨多个省份，那 CDN 几乎一定会改善体验。

CDN 的配置有两个层次，作用完全不同。 第一层是把静态资源托管到 CDN，也就是把图片、CSS、JS、字体上传到 CDN 节点，让它们从离访客最近的位置分发。第二层是反向代理加速，把整个站点作为 CDN 的回源站来代理，CDN 节点负责与访客建立连接并缓存可缓存的响应。

第一层几乎零风险，建议优先做。 做法是把资源文件的 URL 换成 CDN 域名。Nginx 里可以不改代码，只在 HTML 输出时替换域名：

# 静态资源走 CDN，动态请求回源
location ~* \.(jpg|jpeg|png|gif|webp|svg|css|js|woff2?)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    proxy_pass https://your-cdn-domain;
    proxy_set_header Host your-cdn-domain;
}

第二层需要改 DNS 解析，把域名 CNAME 到 CDN 提供的地址。 这一层会改变整个站点的请求路径，回源配置错误会导致网站直接打不开，所以第一次配置时要做灰度——先用一个测试子域名验证，确认无误再切主域名。

CDN 也有它自己的开销和代价，这三点要提前知道：

第一，缓存失效有延迟。 改了文件但访客看到的还是旧的，这对静态资源无所谓（文件名带哈希就解决了），但对 HTML 页面就要设置较短的缓存时间。

第二，CDN 会额外增加一跳延迟。 对极短请求来说，CDN 节点不在访客附近时反而会变慢。所以 CDN 适合静态资源和大文件，不适合实时 API。

第三，源站 IP 可能因此暴露。 如果你的源站 IP 被泄露，别人可以直接绕过 CDN 打你的源站。正确做法是在源站防火墙里只允许 CDN 的回源 IP 段访问。 这一步经常被忽略，做了 CDN 但源站照样裸奔，等于白做。

还有一个几乎零成本的优化：开启压缩和缓存。

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml;

location ~* \.(jpg|jpeg|png|gif|webp|svg|woff2?)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

查 hostwinds 在售套餐与库存

图片格式也要换。 同样的视觉质量，WebP 通常比 JPEG 小 25% 到 35%，比 PNG 小得更多。把 PNG 换成 WebP 这一项，对图片加载速度的改善往往超过升级一档服务器。

六、交互延迟：点击后要等一下才响应，该怎么查

这一节处理第四种情况，也是最少被单独讨论的一类。

典型症状：页面里的按钮点了之后有明显的「粘滞感」，但网络监控看起来一切正常。

原因一：数据库事务或锁。 检查慢查询之外，还要看锁等待：

SHOW PROCESSLIST;
SHOW ENGINE INNODB STATUS\G

输出里如果有大量 Waiting for table lock，说明有长事务占着锁。 这类问题的典型场景是：某个后台任务在跑批量更新，前台所有写操作排队。

原因二：前端渲染阻塞。 页面上一个慢 API 调用会卡住整个交互。要定位是哪个接口慢，给每个请求加标识：

location /api/ {
    proxy_pass http://backend;
    proxy_set_header X-Request-Id $request_id;
    add_header X-Backend-Time $upstream_response_time always;
}

然后在浏览器开发者工具的 Network 面板里看哪个请求耗时长。

原因三：长连接的心跳间隔。 WebSocket 和 SSE 这类技术，客户端的心跳间隔设置不当（比如 60 秒）会在服务端或中间链路上因为空闲超时而被断开，重连时用户就感觉到延迟。解决办法是把心跳间隔设短一些，比如 25 到 30 秒。

原因四：你测的是「服务端处理时间」，访客感受到的是「网络往返 + 服务端处理」。 这两个数要一起看：

# 服务端处理时间
time curl -s -o /dev/null https://your-domain.com/api/test

查看 interserver 当前月价与库存

如果服务端处理只用了 50 毫秒，但访客说「要等两秒」，那两秒里的 1.95 秒在网络往返和浏览器渲染里。 这种情况下应该去优化的是请求次数和资源体积，而不是服务器。

七、DNS 解析慢怎么办，为什么容易被忽略

这一节讲一个容易被完全忽略的原因：不是网络慢，是域名解析慢。

怎么判断是不是 DNS 问题：

# 对比本地 DNS 和公共 DNS 的解析耗时
time nslookup your-domain.com
time nslookup your-domain.com 8.8.8.8
time nslookup your-domain.com 223.5.5.5

如果本地 DNS 明显慢，换成公共 DNS 后正常，那问题就清楚了。 用户浏览器用的往往就是本地运营商的 DNS。

解决办法：

办法一，在服务器上写 hosts 绑定。 这只对你的机器生效：

sudo nano /etc/hosts
# 加入这一行
127.0.1.1 your-domain.com

注意这条只加速服务器自己访问自己的域名，访客不受影响。

办法二：给访客分发更快的 DNS 解析。 如果你的用户主要在国内，给域名配置 CNAME 到国内有节点的 DNS 服务商。这需要你的域名 DNS 服务商支持这种配置，不是所有场景都适用。

办法三，检查是不是 DNS 记录配错了。 常见的错误是同一条记录配了多个值：

dig your-domain.com +short

如果返回多个 IP，说明你配了多条 A 记录。 这本身不是错（可以做负载均衡或容灾），但如果这些 IP 分属不同机房不同线路，效果往往不是负载均衡而是随机延迟——一半用户走高速线路，一半走慢的。这会让你的延迟问题看起来「时好时坏」，极难定位。

判断多 IP 到底是不是好事，要看这几条 IP 的实际属性。 用这个命令逐个查：

for ip in $(dig your-domain.com +short); do
    echo "=== $ip ==="
    ping -c 5 $ip | tail -2 | head -1
done

如果这些 IP 的延迟差异很大（比如一个 30 毫秒一个 200 毫秒），那这个「负载均衡」实际上是在给一半用户制造差体验。 更糟的情况是这几个 IP 在不同机房，DNS 轮询让用户在每次刷新时落到不同机房，缓存和会话都会乱。

正确的做法是：要么全部指向同一个机房的多个 IP（真正的负载均衡），要么在 DNS 层面做加权或地域解析。 纯粹的「A 记录轮询」只适合各个 IP 配置和网络路径完全相同的情况。

另一个 DNS 相关的常见问题：CNAME 链路过长。 如果你的域名 CNAME 到另一个域名，再 CNAME 到第三个，浏览器要多做两次解析。每多一跳解析就多几十毫秒，而且其中任何一环的 TTL 都会拉长整体生效时间。

检查 CNAME 链：

dig your-domain.com +trace

输出里的 CNAME 段如果超过两跳，就值得简化。

最后一个 DNS 层面的问题，也是最容易被忽略的：本地 DNS 缓存导致的「时好时坏」。 某些运营商的 DNS 服务器缓存配置不当，会返回过期的记录。你自己测试时反复 dig 可能拿到不同结果，访客那边却拿不到正确 IP。 验证方法是把 TTL 临时调小（比如 60 秒），观察几天后问题是否消失。

另一个检查是 TTL 设置。 解析慢有时是因为 TTL 太短导致频繁回源查询：

查看 itldc 当前月价与库存

dig your-domain.com | grep -i "minimum\|ttl"

八、换机房和换商家：什么情况下该走这一步

这一节回答一个问题：什么时候不该再调了，直接换。

先说清换机器的三个动作，代价递增：

动作一，同机房同配置重装系统。 只能解决系统层面的问题，对网络延迟完全无效。如果你的诊断结论是「网络路径问题」，重装是纯浪费。

动作二，同商家换机房。 保留账号和付款方式，只换机器所在的机房。这是网络延迟问题的主要解法。

动作三，换商家。 重新注册、重新配置、迁移数据。代价最大，只在两个动作都试过之后考虑。

判断该不该换的具体信号有五个：

信号一：ping 延迟高且全天稳定在高位，换任何应用层优化都不会改善。

信号二：mtr 显示某一跳持续丢包，且丢包率在最后几跳没有恢复。 这说明问题在对方的网络侧。

信号三：晚高峰延迟是白天的三倍以上，且你在香港或美国西海岸机房。 这种情况换更近的机房通常立竿见影。

信号四：换过两次机器都是同样的问题。 那问题很可能在你的方案本身，而不在机器。

信号五：商家不提供任何迁移或换机政策，且技术支持对线路问题推诿。 这是个务实的信号，说明换商家比继续折腾更省时间。

还有一点要算清楚：换机房的成本。 商品库里 LAX-STARTER 是年付 200 美元、折月 16.67 美元；如果要换机房而当前商家不提供迁移，你可能需要重新付一次年付。所以在做决定前，先确认现商家是否提供迁移——很多商家是提供的，这能把成本降到零。

顺带把商品库里的机房分布和价格列出来，方便对照：

机型	机房标识	年付/折月	内存	端口	月流量
LAX-STARTER	洛杉矶	200 美元 / 16.67	2 GB	2000 Mbps	5000 GB
LAX-MICRO	洛杉矶	400 美元 / 33.33	4 GB	4000 Mbps	10000 GB
Residential-STARTER	住宅 IP	260 美元 / 21.67	2 GB	2000 Mbps	5000 GB
IRVINE-PRO-STARTER	加州内陆	350 美元 / 29.17	2 GB	2000 Mbps	5000 GB
云途 HK.DS.M	香港	月付 350 美元	32 GB	1000 Mbps	10000 GB
云途 HK.DS.P	香港	月付 750 美元	64 GB	2000 Mbps	40000 GB

查 spinservers 在售套餐与库存

看这张表能得出两个结论。第一，同一家商家内部不同机房的价差是存在的（LAX-STARTER 16.67 美元对 IRVINE-PRO-STARTER 29.17 美元），换机房不一定更贵。第二，配置更高的机型往往端口也更高（LAX-MICRO 是 4000 Mbps 对 LAX-STARTER 的 2000 Mbps），但这解决的是第三类问题不是延迟问题。

九、哪些做法没用，别浪费时间

这一节讲常见的无效动作，因为它们消耗的时间往往比排查本身还多。

无效动作一：重装系统。 它只在你确定系统层面有问题时才有用（比如装了一堆乱七八糟的东西、怀疑被入侵）。对于 90% 的延迟投诉，重装没有任何作用，而且会让你丢掉已有的配置和排查线索。

无效动作二：在服务器上「优化网络」。 网上流传的各种 sysctl 调优、网卡调优教程，绝大多数是针对几十年前的高延迟卫星链路的。在现代机房环境里，默认的 TCP 参数通常就是合适的。乱调 tcp_tw_recycle、tcp_timestamps 这类参数反而可能造成连接异常——tcp_tw_recycle 在 NAT 环境下有已知的严重问题。

无效动作三：换 DNS 服务商来「优化延迟」。 DNS 解析通常只占首屏时间的几十毫秒。除非你的测试明确显示解析耗时异常（第七节的方法），否则换 DNS 对总延迟的影响微乎其微。

无效动作四：盲目升级带宽。 带宽解决的是第三类问题（带宽不足），不是第一类（路径延迟）。 如果你的 ping 是 180 毫秒，升到 10000 Mbps 端口，ping 还是 180 毫秒。先诊断，再花钱。

无效动作五：装加速工具。 各类「一键优化脚本」「VPS 加速工具」大部分只是改改内核参数或装个缓存，对物理路径没有任何影响。而且这类脚本本身是供应链风险——你在用一个来源不明的脚本以 root 权限改系统。

查 justg 在售套餐与库存

无效动作六：只看单次测试结果。 延迟是一个波动量，单次测试说明不了问题。 至少要连测 10 到 20 次取中位数，跨时段测多次。用中位数而不是平均值，因为一次丢包会把平均值拉偏。

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

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

• 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 iwebfusion 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 racknerd 当前机型与价格
• 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 cloudcone 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 digitalocean 当前机型与价格

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

十、按顺序做一遍：从诊断到解决的操作清单

这一节把前面九节压成一份可以照着走的清单。

第一步：跑三个基础命令，确定问题在哪一层。

ping -c 20 your-domain.com
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s 总计: %{time_total}s 速度: %{speed_download} B/s\n" https://your-domain.com/
curl -o /dev/null -s -w "DNS解析: %{time_namelookup}s\n" https://your-domain.com/

第二步：如果是网络层高，继续测。

mtr -rw -c 100 your-server-ip

看结果：最后一跳丢包率是 0 且延迟正常 → 不是网络问题，跳到第三步；最后一跳延迟高 → 是路径问题，走第七步的换机房流程。

第三步：如果是应用层高，逐项排查。

# 数据库慢查询
sudo grep -i "slow" /var/log/mysql/*.log | tail -20
# PHP-FPM 进程数
ps aux | grep -c "[p]hp-fpm"
# 磁盘饱和度
iostat -x 1 3
# 实时负载
top -b -n 1 | head -15

第四步：如果是带宽层，加资源缓存并上 CDN，同时检查源站是否有其他任务在抢带宽。

sudo iftop -i eth0

第五步：如果是 DNS 层，换公共 DNS 验证，确认后在域名侧配置更快的解析。

第六步：所有软件层排查做完还是慢，就换机房；换机房无解，再考虑换商家。

最后给一张自查表，每一项都有明确的判定标准：

检查项	命令	达标标准	不达标就查
网络往返	ping -c 20	丢包 0%，延迟符合预期档位	第二节 / 第三节 / 第八节
中间跳丢包	mtr -rw -c 100	末跳丢包 0%	第二节 / 第八节换机房
DNS 解析	curl -w "%{time_namelookup}"	低于 50 毫秒	第七节
首字节	curl -w "%{time_starttransfer}"	低于 300 毫秒	第四节
实际速度	curl -w "%{speed_download}"	达到端口速率的合理比例	第五节
磁盘饱和	iostat -x 1	%util 低于 80%	第四节
CPU 负载	uptime	低于 vCPU 核数	升配
内存占用	free -m	谷值低于 15% 使用率	升配

zenlayer 官网机型与实时报价

八项跑完，结论自然就出来了。 延迟问题最忌讳的就是凭感觉乱试——按这张表走一遍，比在群里问十个人都快。