日本VPS带宽怎么选

一、带宽、流量、突发：三个被混着写在一起的数字

日本VPS带宽这个词在产品页上通常只出现一个数字，但这个数字背后至少藏着三个完全不同的口径：端口带宽、月流量额度、以及带宽的独占程度。不把这三者分开，你就没法判断一个 1 Gbps 端口的套餐到底值不值，也没法估算自己一个月会用掉多少。

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

端口带宽是网卡的理论速率，也就是商家给你分配的虚拟网卡上限。它决定的是你的瞬时速度上限——一个大文件下载时你能跑多快，一个脚本批量拉取时你能占满多少管道。但端口带宽完全不限制你一个月总共传多少数据，一个 1 Gbps 的端口如果你只是挂机跑个脚本，每个月可能连 100 GB 都用不到。

月流量额度是周期内允许传输的总数据量。它才是决定你会不会被限速、会不会被追加收费的那个数字。日本机房普遍采用「端口带宽 + 月流量额度」双轨制：前者决定峰值速度，后者决定成本上限和可持续性。

第三件事是带宽的独占方式。同样的 500 Mbps 端口，独享和共享在晚高峰的实测差距可能是十倍。共享端口是机房拿一个大池子切成若干份分给客户，谁用得多谁占得多；独享端口是预留出来的，别人再忙也占不到你这部分。

理解这三个口径之后，选带宽这件事就变成了两道独立的题：第一道是「我的业务在高峰时段需要多少瞬时带宽」，第二道是「我一个月总共会传多少数据」。两道题各自的答案不同，商家却常常只让你看到一个。

二、端口带宽不等于你实际能用到的速度

很多新手把端口带宽当成保证值，这是最常见的误判。商家写 1 Gbps，意思是网卡协商速率是 1 Gbps，但这 1 Gbps 能不能兑现，要看宿主机交换网络的超售比、虚拟化层的调度策略、以及这台机器所在机架的上行总容量。

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

超售是这个行业的常态。一台物理服务器插十块万兆网卡，理论总带宽 100 Gbps，但机房上游只给它分配了 20 Gbps 的出口。那么任何一台虚拟机在自己网卡上测到的最高速度，都不会超过它和其他九台机器分到的份额。日本机房因为地价和出口资源紧张，超售比例往往比欧美机房更高，这使得「标称端口」和「实测峰值」之间的差距更明显。

第二个影响是虚拟化层的调度。KVM 类型的虚拟机在突发流量时可以得到较高的瞬时值，但持续的饱和带宽往往受限于宿主机 CPU 的软中断处理能力和虚拟交换层的排队策略。这也解释了为什么 iperf3 单流测出来的数字可能远低于端口标称，而多并发流测出来更接近。

第三个因素是全双工与单向限制。有些商家写的是「端口带宽」，指的是双向合计的流量能力；有些套餐写「上行 X Mbps / 下行 Y Mbps」，这在跨境场景里差别巨大——对内地的网站来说，下行（服务器发往用户）才是决定页面加载速度的方向。

# 1) 看网卡协商速率，这是端口标称值在系统里的体现
ip -br link show | grep -E 'eth0|enp'
cat /sys/class/net/eth0/speed 2>/dev/null

# 2) 看当前实际协商速率，1000 表示 1 Gbps
ethtool eth0 2>/dev/null | grep -E 'Speed|Duplex'

# 3) 用 iperf3 单流和多流对比，判断是「单流慢」还是「总带宽小」
# 单流只有几十兆、多流能到几百兆，说明是 TCP 窗口或路径问题，不是端口限制
iperf3 -c 你的本地IP -t 30 -P 1
iperf3 -c 你的本地IP -t 30 -P 16

# 4) 反向测试，从服务器主动拉，排除本地上行瓶颈
iperf3 -c 你的本地IP -t 30 -R

判读这组结果有个实用口诀：单流接近端口值，说明通道顺畅；单流低但多流能撑满端口，说明瓶颈在单条 TCP 流的窗口或路径，典型是跨境链路上有排队或丢包重传；多流也上不去，那就是超售或者宿主机层面的限制，属于商家的资源问题，不是你机器的配置问题。

三、用日访问量倒推你真正需要的带宽

带宽不是拍脑袋定的，是可以算出来的。核心公式很简单：峰值带宽 = 峰值秒数内的请求数 × 平均每次请求的传输量。

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

先要三个输入。第一个是日访问量（PV），也就是一天有多少次页面请求。第二个是每个页面在没有缓存命中时会被传输多少数据，这个值和你的页面设计直接相关。第三个是访问的时间集中度——如果流量全天均匀，峰值系数接近 1；如果集中在几个小时内，峰值系数会显著放大。

举个具体例子。假设一个日均两万 PV 的内容站，每个页面首屏实际传输量（HTML 加 CSS 加 JS 加首屏图片）按 800 KB 计算，访问集中在晚上八点到十点两个小时。两个小时是 7200 秒，二十万次请求平均下来是每秒 27.8 次请求。但真实的访问是脉冲式的，不会均匀铺开，峰值时段集中度按四倍算，峰值就是每秒 111 次请求。

每次请求 800 KB 折合 6.4 Mb（这里 Mb 是兆比特，除以八才是兆字节），111 次乘 6.4 Mb，峰值带宽约 710 Mbps。这个数字远超大多数入门套餐给的 100 Mbps 端口。

但请注意，这个 710 Mbps 并不等于你要买 1 Gbps 端口，因为上一步算的是「如果没有 CDN 和缓存」的情况。真实部署里，静态资源交给 CDN 分发、页面开启浏览器缓存之后，源站只需要承担动态请求，那部分可能只有 50 KB 甚至更少。同样再算一次，峰值带宽降到 44 Mbps 左右，一百兆端口就够用了。

这个计算过程本身就说明了为什么「带宽怎么选」的答案高度依赖你的架构：同样是日均两万 PV 的站点，纯源站直出和 CDN 回源，所需带宽能差出十倍以上。

# 1) 用 nginx 访问日志统计真实的每小时请求数分布，而不是拍脑袋估
awk '{print $4}' /var/log/nginx/example.access.log | cut -d: -f1 | sort | uniq -c | sort -k2

# 2) 统计每个请求的平均传输字节数（bytes 字段是响应体大小）
awk '{sum+=$10; n++} END {printf "平均响应 %.1f KB, 样本 %d\n", sum/n/1024, n}' \
  /var/log/nginx/example.access.log

# 3) 找出峰值小时的请求数，就是你做容量估算的基准
awk '{print $4}' /var/log/nginx/example.access.log | cut -d: -f1,2 | sort | uniq -c | sort -rn | head -5

# 4) 用 curl 确认单个页面实际传输了多少字节
curl -o /dev/null -s -w "size=%{size_download} ttfb=%{time_starttransfer} total=%{time_total}\n" https://你的域名/

第一条和第三条命令给出的数字是真实分布，比任何行业平均值都准。第二条命令尤其重要，很多人以为自己的页面只有 50 KB，实际上把图床里的原图算进去可能超过 2 MB。

四、流量额度怎么算：一个网页到底吃掉多少流量

带宽是速度，流量是总量，两者算的是完全不同的账。买 1 Gbps 端口配 1 TB 月流量的组合，看起来像「高速但限量」；买 100 Mbps 端口配 10 TB 月流量的组合，看起来像「低速但海量」。实际使用中哪一种更合适，取决于你的业务是「瞬时需要快」还是「长期需要多」。

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

单个网页的流量消耗可以拆成几块来看。最容易低估的是图片。一张未经优化的商品主图可能是 800 KB，一篇包含 20 张图的详情页就是 16 MB，这个量级下，1000 次访问就是 16 GB，直接吃掉月额度的很大一部分。第二个容易被低估的是重复下载——如果页面的 CSS、JS、字体没有设置长期缓存或者没有加版本号指纹，每个访客每次访问都要重新下载一遍静态资源。Web 字体和前端框架的 JS bundle 尤其夸张，一个没做缓存优化的站点，静态资源重复下载能占到总流量的六成以上。

第三块是协议开销。HTTP/1.1 下每个请求都带完整的请求头和响应头，一次典型的 API 请求头部在一百到三百字节量级。高频的 AJAX 调用、轮询、心跳请求累积起来，这部分开销不算大但也不能忽略。

第四块是重定向和 404。如果站点里有大量无效链接被抓取，每个 404 响应同样消耗流量并占用连接。

# 1) 用 vnstat 统计日流量，这是判断额度够不够最直接的工具
vnstat --oneline b
vnstat -d   # 按天看
vnstat -m   # 按月看

# 2) 按协议分类看流量消耗，找出真正的大头
vnstat -p

# 3) 找出传输量最大的 20 个 URL，通常答案就在这里
awk '{print $10, $7}' /var/log/nginx/example.access.log | sort -rn | head -20

# 4) 找出访问最频繁但每次都很小的 URL，静态资源缓存问题的证据
awk '{print $7}' /var/log/nginx/example.access.log | sort | uniq -c | sort -rn | head -20

第三条命令输出如果全是图片路径，那就说明你的流量瓶颈是资源体积而不是流量本身，优先做图片压缩和 CDN 迁移。第四条命令输出如果是一堆 .js 和 .css，那就要去检查缓存响应头。

关于流量额度还有一点必须提前确认：额度的统计口径是「上传加下载」还是「只算下行」，超额之后是限速、停机还是按比例计费。这些条款各家差异极大，且经常写在服务条款正文里而不是产品页上，买之前必须问清楚。

五、独享带宽和共享带宽差在哪

独享带宽指这部分带宽是给你预留的，无论机房其他客户多忙，你的流量都走这条预留通道。共享带宽指机房维护一个大池子，所有客户共享，超出分配额度的部分按优先级排队，优先级低的客户会被限速甚至丢包。

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

差距最容易在晚高峰暴露出来。日本机房的共享池通常在本地时间晚上八点到十一点之间压力最大，因为这个时段同时叠加了跨境出口拥塞和机房内部的其他业务流量。同一台机器，平峰能跑满端口、晚高峰掉到几兆，在共享池里是常态，而在独享端口上基本不会发生。

第二个差距体现在延迟抖动上。共享池在排队时不仅速度下降，延迟也会出现明显的毛刺。这对交互型业务影响更大：网页加载从 80 毫秒变成 400 毫秒，用户的感受是「网站卡了」，而不仅仅是「下载慢一点」。

第三个差距体现在晚高峰的实际吞吐。粗略的估算方法是：共享端口在晚高峰的实际可用带宽通常只有标称值的三成到五成，独享端口通常能稳定在标称值的八成以上。这两个数字是行业常见经验值，不是任何一家商家的承诺，实际情况需要以你实测为准。

不过独享带宽也有它的成本。同样的月费，独享端口的价格通常比共享端口高一到三倍。日本机房尤其如此，因为优质线路的出口资源本身就稀缺，保留一部分带宽给某个客户的成本是实打实的。

一个折中的做法是「独享小带宽 + 共享大端口」。你只独享 20 到 50 Mbps 的保底带宽用于承载常规业务，其余突发需求走共享大端口补充。多数控制台都支持这种配置，但需要在下单时明确提出，并确认在合同或面板里写明保底带宽的数值和线路类型。

六、超流量之后商家会怎么处理

超出流量额度之后的处理方式，直接决定了超出的代价有多大。日本机房常见的处理方式有四种：按比例付费续用、降速限流、暂停服务、封禁端口。

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

按比例付费续用是最宽松的方式，通常按超出的 GB 数乘以一个单价计费。问题在于这个单价往往比套餐内的流量单价贵三到十倍，而且很多商家在续用页面上不写单价，必须联系客服才能知道。这个单价必须在购买前问清楚并记下来。

降速限流是最常见的方式。超出额度后端口从 1 Gbps 降到 1 Mbps 甚至更低，业务不会中断，但基本等于停摆。这种情况下流量消耗速度也大幅下降，实际上是在强制你等下个月或付费。

暂停服务和封禁端口比较极端，通常发生在额度超出很多之后。商家先给你邮件提醒，宽限期几天内处理就恢复，超期未处理则停机。这对个人博客影响不大，但对电商、接口类业务等于直接下线。

无论哪种方式，核心都是同一个问题：你的业务是「可中断」还是「不可中断」。可中断的业务可以接受超流量限流，把额度买得紧凑一点省钱；不可中断的业务必须预留安全余量，或者提前买好超额流量包。

# 1) 设置流量告警脚本，到达额度阈值就通知你，而不是等商家发邮件
cat > /usr/local/bin/traffic-alert.sh <<'EOF'
#!/bin/bash
LIMIT_GB=800
USED_GB=$(vnstat --oneline b | awk '{print $3}')
echo "used=${USED_GB}GB limit=${LIMIT_GB}GB"
awk -v u="$USED_GB" -v l="$LIMIT_GB" 'BEGIN{
  if (u/l > 0.7) print "警告：已用 " u "GB，达到额度 " l "GB 的 70%";
  else if (u/l > 0.9) print "严重：已用 " u "GB，即将限速";
}'
EOF
chmod +x /usr/local/bin/traffic-alert.sh

# 2) 每小时检查一次，并接入邮件或 webhook 通知
echo '0 * * * * /usr/local/bin/traffic-alert.sh' | crontab -

# 3) 找出流量增长最快的时段，告警阈值可以按这个时段动态调整
vnstat --hours h

# 4) 设置 logrotate，防止访问日志本身吃掉磁盘和备份空间
cat > /etc/logrotate.d/nginx <<'EOF'
/var/log/nginx/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}
EOF

第二条的告警阈值建议设在额度的百分之七十。多数商家在百分之八十到九十才发提醒邮件，等到邮件到达时可能已经过去了两三天，而流量还在以每天百分之几的速度增长。

七、线路类型决定带宽的性价比

同样是十兆带宽，普通国际带宽和优化线路的价格可能相差数倍。这不是商家定价不透明，而是背后的资源成本完全不同。

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

普通国际带宽走的是日本机房的常规出口，流量到达内地后需要经过国际骨干网的公共通道，代价是高峰期排队多、丢包率不稳定。优化线路则是专门为中国方向预留的跨境容量，比如电信的 CN2 GIA、联通的 9929、移动的 CMIN2，它们的成本体现在需要向运营商单独采购这部分带宽。

带宽单价上的行业常见估算区间可以给一个量级参考：普通国际带宽折算下来大约每 Mbps 每月十几到四十元人民币；CN2 GIA、CMIN2 这类优化线路则可能达到每 Mbps 每月两百元人民币以上。以上都是估算区间，不是任何一家的报价，具体以官网当日报价为准。

日本机房在带宽成本上有一个客观优势。日本是全球互联网的骨干节点之一，NTT、SoftBank、KDDI 在日本都有密集的骨干网互联，国际带宽资源本身比大多数区域充足，因此同等配置下日本 VPS 的端口带宽通常标得更慷慨，流量额度也给的更多。缺点在于从日本到内地的路径要经过至少一段国际出口，再进入中国境内的骨干网，路径比香港多一跳。

日本机房公开的产品线也能看出这种分化。广告库里有结构化套餐数据的商家里，justg 的公开产品线标注了 CPU 核数、内存、硬盘、端口带宽与月流量四个口径，入门档标称 500 Mbps 端口配 1024 GB 月流量，这一档位可以作为「端口带宽与流量额度组合」的单位成本参考锚点，但它是共享型 VPS 的配置口径，不要直接当成日本节点的承诺值。zenlayer 的公开定位是面向人工智能的分布式云平台，在东京设有办事处，网络侧强调全球分布与超互联，这类产品更适合对全球访问质量有要求的场景。backwaves 的公开说明里提到美国与日本 VPS 接入联通 9929 与 AS10099 精品网，并提供 IEPL、IPLC 专线互联，属于带宽成本明显更高的一档。digitalvirt 的公开节点覆盖东京，回国可选 9929、CN2 GIA、CMIN2、4837 等线路；zgovps 的数据中心布局在洛杉矶、荷兰诺德韦克与大阪，使用第四代 AMD EPYC 处理器。其余像 hostkvm、vollcloud、恒创科技、景文互联、tokyonline 这些商家，在本站广告库里只有文字简介、没有结构化套餐数据，具体机型与报价一律以官网当日报价为准，不要拿别家的数值去套。

选线路的判断标准应该回到业务本身：静态展示类、对延迟不敏感的业务，用普通国际带宽配大流量额度最划算；表单提交、登录、下单、API 调用这类交互型业务，值得为优化线路付费；跨境专线类产品则完全是另一个预算层级，不要和普通 VPS 放在一起比价。

八、到手以后怎么验证带宽是真的

买之前所有的分析都是推算，推算必须在拿到机器之后被实测修正。验证要分三步走：验证端口上限、验证独享程度、验证流量额度。

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

验证端口上限用 iperf3，找一台和你本地网络条件接近的机器做对拉。至少要测三组：单流、8 流、16 流，每组跑满三十秒排除慢启动干扰。同时要做反向测试，因为从服务器主动拉取和从本地拉取的瓶颈位置完全不同，本地家用宽带的上行通常只有下行的几分之一，不做反向测试会误判成商家限速。

验证独享程度靠对比时段。挑一个平峰时段（比如凌晨四点）和一个晚高峰时段（比如晚上九点）各跑一次同样参数的 iperf3，把两个结果并排比较。如果晚高峰的结果只有平峰的百分之三十左右，那基本可以判定是共享池。独享端口在两个时段的差距通常在百分之十以内。

验证流量额度要用真实流量而不是理论值。装上 vnstat 让它跑几天，看实际消耗速率，再和商家标注的额度做除法。这个步骤能提前发现「额度写的是理论值，实际扣的是双倍流量」这类坑——有些商家按上下行各计一次来统计，也就是你上传 1 GB 下载 1 GB 会算成 2 GB。

# 1) 三组并发测试，把结果存下来做对比
for p in 1 8 16; do
  echo "=== P=$p ==="
  iperf3 -c 你的本地IP -t 30 -P $p | tail -3
done

# 2) 反向测试，排除本地上行瓶颈
iperf3 -c 你的本地IP -t 30 -R | tail -3

# 3) 换个公网节点再测一次，排除单条路径的问题
iperf3 -c 另一个测试节点IP -t 30 -P 8 | tail -3

# 4) 记录每个时段的实测值，供晚高峰对比
cat > /usr/local/bin/bw-probe.sh <<'EOF'
#!/bin/bash
TS=$(date +%Y-%m-%d\ %H:%M)
V=$(iperf3 -c 你的本地IP -t 20 -P 8 | grep 'sum' | awk '{print $6}')
echo "$TS bw=${V}Mbps" >> /var/log/bw-probe.log
EOF
chmod +x /usr/local/bin/bw-probe.sh

# 5) 装 vnstat 做流量统计
apt install -y vnstat && vnstat --oneline b

判读时有个容易出错的点：如果单流结果远低于多流，先别急着怪商家，先看 tcp_congestion_control 和 net.core.default_qdisc 的设置。跨境链路上的 bufferbloat 会让单流延迟暴涨、吞吐上不去，这时候换拥塞控制算法（比如 bbr）往往比换商家更有效。

九、不同场景该配多少带宽：一张对照表

把前面的计算方法落到具体场景上，可以得到下面这张对照表。表中端口和流量两列是起点值，不是必须值，实际还要按上一节的公式用你自己的访问量校准。

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

选型的逻辑可以归纳成三句话。静态展示型业务，优先保证线路稳定和延迟可控，带宽给够不超用的余量即可，别为端口数字多付钱。传输型业务，优先算清楚总流量成本和超额规则，速度要求可以靠多节点分摊。交互型业务，优先看晚高峰的单流延迟和丢包，而不是看标称端口。

还有一个务实的策略：先用一个月入门档把业务跑起来，积累真实的访问日志和流量曲线，再决定升配还是降配。多数人第一次买 VPS 都存在配置浪费——买了大带宽却只有几百 PV/day，买了大流量却因为静态资源没做缓存而白白消耗。

十、常见问题

日本VPS带宽买多少够用？ 先用日访问量倒推，不要用感觉估。核心算法是峰值秒数内的请求数乘以单次传输量，再除以八换算成兆比特。以一个日均两万 PV、商品图走 CDN 的电商站为例，源站只承担动态请求，峰值带宽大概在四十到六十兆比特区间，一百兆端口足够。反过来，如果图片全部从源站直出且访问集中在两小时内，同样流量下峰值需求会上升到几百兆比特。具体数值一定要用你自己机器的访问日志跑一遍上面第三节的命令再定。

端口带宽标 1 Gbps，为什么 iperf3 只能跑到 200 Mbps？ 三个常见原因：一是本地家宽上行限制，二是单条 TCP 流受跨境链路拥塞窗口限制导致单流偏低（用 16 并发流再测一次即可区分），三是宿主机层面的超售和虚拟交换层排队。先做单流与多流对比、再做反向测试，才能确定问题出在商家还是自己这边。另外，别用浏览器下载文件测带宽，浏览器测试会被本地网络、服务器文件大小、HTTP 并发策略等多个因素干扰。

月流量额度用完了会怎样，必须知道吗？ 必须问清楚，这是选带宽时最容易吃亏的地方。要问清三件事：统计是上行加下行合计还是只算下行，超额后是限速还是停机，超额流量的续费单价是多少。如果这三项含糊，务必在下单前让客服以文字形式回复并留存。不同商家的处理差异很大，有的基本停机，有的降到 1 Mbps 继续跑，有的主张按比例付费且单价合理。

独享带宽值不值这个钱？ 判断标准是看你的业务是否对晚高峰敏感。用 iperf3 在平峰和晚高峰各测一次，如果晚高峰掉到平峰的百分之三十以下，说明你现在的共享带宽在高峰期确实是瓶颈，独享就有意义。如果两个时段差距不到百分之十五，独享带来的收益很小，不值得为此多付一倍价钱。折中办法是只独享二三十兆的保底带宽。

流量额度能不能后期加？ 多数商家提供额外流量包或按比例付费两种方式，但流量包的计价单价通常明显高于套餐内包含的部分，加购前要算清楚实际单价。另一个更省钱的思路是技术侧先减流量：给静态资源设置长期缓存头、给图片加 WebP 或 AVIF 格式、把大文件转到对象存储并用 CDN 分发。很多站点做完这三项，流量消耗能直接砍掉一半以上，再谈加购就从容得多。

日本节点和香港节点比带宽性价比，哪个高？ 香港机房的国际出口资源更稀缺，优质 BGP 和优化线路的每兆比特月成本明显更高，端口带宽通常给得比日本保守；日本是全球骨干节点之一，国际带宽资源相对充足，同等价位下端口和流量额度往往更慷慨，代价是到内地的路径比香港多一跳、延迟略高。做静态分发和批量下载选日本更划算，做面向内地用户的低延迟交互业务选香港更合适。这些是结构性差异，具体价格仍以官网当日报价为准。