正在看东京这个节点的人，绝大多数不是冲着它的流量来的——恰恰相反，是冲着它的位置来的。东京云页面上摆着四个档位，从 ¥500 一路排到 ¥2999，CPU 从 1 核走到 8 核，内存从 1G 走到 8G，硬盘从 30G 走到 120G，唯独出网额度这一栏四行写着同一个数字：10G/月。在这条线上，加钱能买到的东西很多，但流量从来不在其中。
先把一句可能不太中听的话摆在前面：10G 不是一个「大概够用」的模糊感觉，它是可以被算清楚的硬数字。按 10 GB = 10,240 MB 折算，配上你业务的单次出网体积，直接就能算出这个额度撑得住多少次接口调用、多少张图片、多少 PV、多少天日志回传。算完之后你会发现，10G 对应的不是「小网站」这个含糊的量级，而是「本机基本不对外吐大数据」的那类机器。边界画清楚了，选型才有意义。
还有一个更容易被忽略的错位：四个档位的端口都是 100M。100M 端口按 1 Mbps 理论峰值约 128 KB/s 换算，是大约 12.8 MB/s 的峰值速率，而 10 GB 的月额度在这个峰值下只需要八百秒就跑干净，也就是十三分钟左右。端口的能力严重过剩，真正的天花板是那 10G 的水箱。用端口速率去评估这台机器，会得到完全错误的结论；用流量额度去评估，才对得上它真实的成本结构。
所以本篇的落脚点不是「这一档值不值」，而是三件更实在的事：10G 到底换算成什么业务量、四档加价分别买到了什么、**什么东西绝对不该放在这里**。如果你本来打算拿东京这台机器当图床、当下载站、当备份仓库，那这篇文章能帮你省下一笔冤枉钱和一个月的折腾。
先把结论摆出来，赶时间的话看这五条就够了：
一、四档的出网额度全部锁死在 10G/月，从 ¥500 涨到 ¥2999，流量一分没加，这条线加钱买的是本机算力和东京的出口位置，不是流量。
二、B 档到 C 档那 ¥949 买的是 2 核 + 2G 内存，硬盘维持 80G 一动不动，流量同样一动不动；这是四档里性价比最差的一步，也是最容易被销售话术包装成「升级」的一步。
三、10G 按 10 GB 折算，按每次 50 KB 的接口响应估算约合 21 万次调用/月，按每张 500 KB 的图片估算约合 2.1 万张/月，均未计入 CDN 之外的额外开销，按此估算，实际以业务实测为准。
四、流量用完之后「升档」这条路在这条线上是死的，四档流量完全一样；真正管用的四条退路是叠加流量包、换产品线、上 CDN、把静态的出网挪走。
五、以下业务进了这个节点基本都会出问题：图床相册、下载分发、视频点播与直播、爬虫出口、备份仓库、跨机房大文件同步，以及任何内存明显大于核数的服务。
东京云这条线的字段很干净，只有六项：CPU、内存、硬盘、带宽、月流量、月付。把四行并排放，涨价的路径一眼就能看完，因为它们的变化规律整齐得有点刻板——核数和内存永远 1:1 同步，端口永远是 100M，月流量永远是 10G，真正动的只有三项：核数、配着核数走的内存、以及偶尔跳一下的硬盘。
东京云 A 型是入口档：1 核 / 1G / 30G 硬盘 / 100M 端口 / 10G 月流量 / ¥500 元/月。1 核 1G 这个量级能干什么？一个 Nginx 反代、一个轻量 API 进程、一个监控探针、一台 SSH 跳板，或者一个跑定时任务的常驻脚本容器。它的价值不在算力，而在于你花五百块拿到了一个东京本地的 IP 和一个干净的出口。反过来也别指望它能跑数据库、跑 Redis 实例、跑任何有内存饥饿风险的东西，1G 内存在系统自身开销之后留给应用的余量非常有限。
东京云 B 型是 2 核 / 2G / 80G / 100M / 10G 流量 / ¥950 元/月。A 到 B 加 ¥450，买到的是 1 核 + 1G 内存 + 50G 硬盘——注意这是整条线上唯一一次「盘、核、内存三项一起涨」的升级，硬盘从 30G 直接跳到 80G，翻了将近三倍。如果预算卡在一千块以内又要跑正经业务，B 档基本是唯一选项，因为 A 档的 30G 硬盘在装完系统、日志和运行时之后剩余空间会很紧张。
东京云 C 型是 4 核 / 4G / 80G / 100M / 10G 流量 / ¥1899 元/月。B 到 C 加 ¥949，买到的是 2 核 + 2G 内存，硬盘原地踏步还是 80G，流量也纹丝不动。这一步是全线中最尴尬的一次跃迁：价格几乎翻了一倍（¥950 到 ¥1899），但是除了 CPU 和内存，其他所有字段一行没变。定价写成 1899 而不是 1900，是心理价位的写法，但分摊到两个核上，单核边际成本是 ¥474.5，比 A 到 B 那一步的 ¥450/核 还贵。
东京云 D 型是 8 核 / 8G / 120G / 100M / 10G 流量 / ¥2999 元/月。C 到 D 加 ¥1100，买到的是 4 核 + 4G 内存 + 40G 硬盘，单核边际成本降到 ¥275，是全线最便宜的一段——这也是为什么如果你是冲着算力去买的，D 档的单位成本反而最优。把四档的单位核价排一排：A ¥500/核、B ¥475/核、C ¥474.75/核、D ¥374.9/核，越往上越划算，但因为流量全锁死，这个「划算」只兑现算在算力账上，不能分摊到网络账上。
从 A 到 D，价格涨了 ¥2499，接近 6 倍；算力涨了 8 倍；硬盘涨了 4 倍；而出网额度涨的倍数是一——一模一样的 10G。这句话值得在下单前多读两遍：这条线的定价逻辑是「本机算力 + 东京节点位置与 IP」，网络侧的额度是固定的配套设施，不参与加价。
| 档位 | CPU / 内存 / 硬盘 | 端口 / 月流量 | 月付 | 相对上一档，加的钱买到了什么 |
|---|---|---|---|---|
| 东京云 A 型 | 1 核 / 1G / 30G | 100M / 10G | ¥500 元/月 | 入口档，单位核价 ¥500/核；适合反代、探针、跳板、定时任务这类常驻但不干重活的机器 |
| 东京云 B 型 | 2 核 / 2G / 80G | 100M / 10G | ¥950 元/月 | 加 ¥450，买到 1 核 + 1G 内存 + 50G 硬盘；全线唯一一次三项同时升级，也是千元内的推荐停点 |
| 东京云 C 型 | 4 核 / 4G / 80G | 100M / 10G | ¥1899 元/月 | 加 ¥949，只买到 2 核 + 2G 内存；硬盘维持 80G、流量维持 10G，两项零变化，边际成本 ¥474.5/核 |
| 东京云 D 型 | 8 核 / 8G / 120G | 100M / 10G | ¥2999 元/月 | 加 ¥1100，买到 4 核 + 4G 内存 + 40G 硬盘；边际成本 ¥275/核，单位核价最低，但流量仍为 10G |
把端口速率和月度额度放在一起看，这个组合的错位程度可能会超出很多人的预期。100M 端口按业内通用的速率换算（1 Mbps 理论峰值约 128 KB/s）折算，峰值速率大约 12.8 MB/s。而 10 GB 的月流量按 10,240 MB 计算，在这个峰值下不间断地跑，需要的时间是 10,240 ÷ 12.8 = 800 秒，也就是十三分二十秒。一台机器一个月的流量额度，理论上可以在一顿午饭的时间里跑干净。
换个角度算这个错位会更直观。同一个 100M 端口，如果三十天不眠不休地满负荷出网，理论月吞吐是 12.8 MB/s × 86,400 秒 × 30 天 = 33,177,600 MB，折合约 32,400 GB，也就是 32 TB 量级。而实际给的额度是 10 GB，占比约万分之三。换句话说，这台机器 99.97% 的端口能力，是被流量额度锁住用不上的。这不是缺点，是产品设计的取舍——它把价格和 100M 峰值绑在一起卖，而不是把价格和总量绑在一起卖。
这个结构带来的直接结果是：你几乎不可能把端口跑满，但你很容易把额度跑穿。峰值 12.8 MB/s 意味着下发一个大文件的时候手感非常好，几百兆的安装包一分钟就推完了，而这正好是最危险的地方——每一次「推得真快」的体验背后，都是从 10G 那个水箱里舀走的一大瓢水。习惯用端口速率判断机器性能的运维，在这个节点上必然翻车，因为限速的从来不是端口，是水表。
再补一个必须写清楚的前提：本文所有换算按「10G 指的是 10 GB 出网额度、且只统计出网方向」来理解。页面上没有标注这个流量是单向出网还是出入双向合计，也没有标注 10G 是 GB 还是 Gb 口径，这两项在下单前必须向销售确认。如果实际按双向合计统计，那所有业务的可用量级要直接折半——一台每天要拉几百兆镜像或数据的机器，光是下行就把额度吃掉一大截。这一点对跑 CI、跑容器、跑定时抓取的机器尤其致命。
还有一个细节：既然端口峰值十四分钟就能把月额度打光，那么这台机器上绝对不能出现「计划外的大流量输出」。一次误操作导致的全量日志拉取、一个忘了关的调试端点、一段被人刷接口的 URL，都可以在几分钟内把一个月的水箱抽干。所以在这台机器上，出网侧的限流和监控不是可选项，是必须项，至少要在机器上配一个出网流量的日级告警。
前面说的是结构，这一章做算术。所有数字都是 10 GB = 10,240 MB = 10,485,760 KB 这个基数上除出来的，每一次都写清楚假设的单次体积——因为假设一变，结果就会跟着变。以下全部为按指定单次体积估算的推算值，按此估算，实际以业务实测为准。
按每次响应 20 KB 估算（一个经过精简的接口返回体，含 HTTP 头，未计 TLS 握手开销）：10,485,760 ÷ 20 ≈ 524,288 次，也就是约 52 万次/月，摊到每天约 1.75 万次。听起来不少，但注意这是「每次只有 20 KB」的理想情况。按每次 50 KB 估算（带列表数据的常见业务接口）：约 21 万次/月，日均约 7,000 次。按每次 100 KB 估算（返回结构复杂、带多点冗余字段的老接口）：约 10.5 万次/月，日均只有 3,500 次左右。一个日活几千、人均几十次请求的小应用，就已经贴着这条线的天花板在走了。
按每张图片 200 KB 估算（已经过压缩的常规业务图）：10,485,760 ÷ 200 ≈ 52,428 张，约 5.2 万张/月，日均 1,750 张。按每张 500 KB 估算（未充分压缩的详情页大图、商品图）：约 2.1 万张/月，日均 700 张。按每张 1 MB 估算（原图直出，没有任何处理）：只有 1 万张/月，日均 341 张。静态资源同理：一个 300 KB 的 JS bundle 被人拉取约 3.5 万次/月，一个 100 KB 的 CSS 约 10.5 万次/月。这些数字意味着什么？意味着只要你的页面上有一张没有被 CDN 接走的大图，几天之内就能把额度啃掉一角。
把前面的东西合并成一个站点模型，差距会非常刺眼。按每次页面访问本机只输出 50 KB 估算（静态资源全部走 CDN，源站只出 HTML 与少量动态内容）：约 21 万 PV/月，日均 7,000 PV。按每次页面访问本机输出 500 KB 估算（没有 CDN，HTML + JS + CSS + 图片全由这台机器出）：只有约 2.1 万 PV/月，日均 700 PV。同样的机器、同样的 10G 额度，有没有 CDN 差了整整十倍。这也是本文反复强调 CDN 的原因——在这个节点上它不是锦上添花的优化项，它是能不能把业务跑下去的前提。
日志是最容易漏算的一项，因为它是「安静地一直在流」。按每天回传 50 MB 估算，一个月是 1.5 GB，占额度 15%；按每天 100 MB 估算，一个月 3 GB，占 30%；按每天 300 MB 估算，一个月 9 GB，直接吃掉九成——这时候你的业务本身几乎已经没有额度可用了。按每条日志 1 KB 估算，约合 1,048 万条/月，日均 35 万条，这个数字看着很大，但只要采集端没有做本地聚合和采样，一个中等规模的服务很容易就摸到这个量级。做法是固定的：日志在本机先聚合、压缩、采样，再批量回传，而不是逐条实时上报。
数据库与文件备份是压垮这类节点最常见的一根稻草。按一次全量备份 2 GB 估算，10G 的额度只能同步 5 次/月；按 1 GB 估算，10 次/月；如果业务要求每天做一次全量并异地同步，按 2 GB/天 算就是 60 GB/月，超出额度整整六倍。相对可行的做法是「本机留最新的全量 + 每日增量」：按每日增量 200 MB 估算，一个月约 6 GB，占额度的 60%，仍然偏高，但至少是可以讨论的范围。更合理的解法是让备份走内网或对象存储的专用通道，而不是占用这台机器的公网出网额度——前提是服务商侧支持，这一点需要提前确认。
把四档差价的「到账内容」逐个拆开，是判断该停在哪一档的唯一可靠方法。前面提过一次，这里把三笔账分开算清楚。
A 到 B，加 ¥450：买到 1 核 CPU、1G 内存、50G 硬盘。这是全线结构最健康的一次升级，三项全部跟着涨，其中硬盘从 30G 跳到 80G 的幅度甚至超过了 CPU。对一个要装运行环境、留日志、偶尔跑个小数据库副本的机器来说，这笔钱是四步里花得最值的——我一般会建议预算在一千以内的客户直接停在 B 档，别在 A 档上硬扛，因为 30G 硬盘留给应用的余量实在太少，后期为清盘、清日志折腾的时间成本远超这四百五十块。
B 到 C，加 ¥949：买到 2 核 CPU、2G 内存，硬盘 80G 不变，流量 10G 不变。这是整条线上性价比最差的一步，价格几乎翻倍（¥950 → ¥1899），而拿到的东西只有本机算力。不是说这一步没用——跑编译任务、跑并发稍高的应用、跑需要多核的服务确实需要这 2 核——而是说你要清楚自己付的这九百多块里，一分钱都没有花在网络和存储上。如果驱动你加档的原因是「流量不太够」或者「盘快满了」，这一步完全无效，你得走别的路。
C 到 D，加 ¥1100：买到 4 核、4G 内存、40G 硬盘，单核边际成本 ¥275，是全线最低。这一步虽然只涨了 1100 元——和 B→C 的 949 元相比只多了 151 元——但拿到的核数是 B→C 的两倍。所以如果你的负载确实是被 CPU 卡住的（比如要在这台机器上跑构建、跑编解码、跑并发量比较大的应用服务），从中段冲到 D 档反而是这条线上单位成本最优的选择。
把单位核价排成一行会更清楚：A ¥500/核、B ¥475/核、C ¥474.75/核、D ¥374.9/核。这是一条典型的「向上买更便宜」曲线，意味着如果你已经确定要 4 核以上，与其在中枢档犹豫，不如把布局直接拉到目标算力档——流量反正四档一样，不存在「买小一点省流量钱」这回事。
最后是两个恒定量，它们框死了这条线的天花板。第一，内存永远等于核数（单位 G），1核1G、2核2G、4核4G、8核8G，没有任何一档例外，也就是说这条线上不存在「8 核 32G」这种配置，Redis 大实例、Elasticsearch 数据节点、大堆 JVM 服务一律没有位置。第二，硬盘最大只到 120G，且有两档停在 80G，本地存储型业务同样进不来。这两条加在一起，决定了东京这条线的定位——它是一台「位置好、算力够、但几乎不对外吐数据」的机器。
判断标准其实只有一句话：这台机器每个月对外吐出去的东西，能不能被你控制在算得出来的范围内。能算清楚的，放这里就合适；算不清楚的，无论多便宜都别碰。下面这几类，是 10G 额度下真正适配的场景。
第一类是面向日本用户的轻量 API 服务与业务后端。一个跨境的小程序后台、一个给日本站点供数据的接口服务、一个 SaaS 的鉴权与回调服务，它们的特征都是「请求多、每次小」，正好落在每次几十 KB 的那个换算区间里。按每次 50 KB 估算，一个月 21 万次调用的量级，对一个成长期的 B 端服务来说相当宽裕。前提是接口本身做了字段精简，别把一个带完整冗余字段的老接口整个丢出去。
第二类是不承流量的中转角色：反向代理、跳板机、内网穿透的服务端、隧道中转与端口转发。这类机器的价值在于它站在东京这个位置上，在于它的 IP 归属，而不在于它往外吐多少数据。流量也非常好估算——中转多少请求，就大约是多少倍的请求头加少量数据。这类机器通常配 A 档或 B 档就够，甚至不需要太多硬盘。
第三类是监控探针、采集端与定时任务调度。探针类业务的特点是「出网极小、常年在线」，一分钟一次的心跳、几个指标的上报，按每包 1 KB 估算，一个月跑满也不过几十 MB。它需要的其实是一个稳定的境外观测点和一条稳定的链路，东京这个位置对做跨国链路质量观测、做日本本地可用性监测来说很合适，而出网额度根本不构成约束。
第四类是上了 CDN 之后的内容站点源站。这是把一个「流量不适配」的业务改造成「流量适配」的标准做法：静态资源全部由 CDN 边缘节点承担，源站只在回源时输出动态内容与被回源的少量静态资源。按每次访问本机只出 50 KB 估算，10G 可以撑到 21 万 PV/月；如果完全不上 CDN，同样的机器只能撑 2.1 万 PV/月。十倍的差距，成本却只是 CDN 那点流量费，这笔账怎么算都划算。
第五类是游戏、即时通讯、物联网这类业务的服务端逻辑节点。它们的瓶颈在连接数、在计算、在延迟，而不在出网总量——一个玩家的一次操作上下行可能都不到 1 KB。这类业务在东京节点上的意义是「离日本玩家更近」，而 10G 的额度对信令级的数据流来说绰绰有余。选档时看核数和内存即可，注意它们的首要诉求通常是 CPU 单核性能和延迟稳定性，而不是某一档便宜几百块。
该推荐的说完了，说不该碰的。下面七类业务放进东京这条线，99% 会在月中的某一天给你一个措手不及，而且事后补救的成本远高于当初多花的那点预算。
一、图床、相册、素材站。按每张 500 KB 估算，10G 只够 2.1 万张/月，日均七百张；如果原图直出按每张 1 MB 算，日均三百四十一张。一个稍有人气的图床几天的量就超了。这类业务的正确放法是对象存储加 CDN，而不是一台 10G 月流量的云主机。
二、下载站与安装包、固件分发。按每个安装包 500 MB 估算，10G 只够被完整下载二十次；按一个 2 GB 的镜像估算，五次就把额度抽干。正因为端口峰值有 12.8 MB/s，下载体验会非常好——好到你根本意识不到额度正在被消灭。这类业务要么走不限流量的产品线，要么走对象存储的下载分发。
三、视频，无论点播切片还是直播。一段 1080P 的几分钟内容轻松上百 MB，一个小时的直播流按常见码率估算在 GB 级。10G 的额度在这种量级面前不是「少」，是「没有」。视频业务请直接考虑大流量或不限流量的产品线，不要在按流量计费的产品上做视频。
四、爬虫出口。爬虫的特点是「持续、高并发、总量不可控」，而且一旦目标站点改版、返回体积变大，出网量会在你完全无感知的情况下翻倍。更麻烦的是爬虫常常会同时拉图片、附件、无限翻页的内容，实际出网量往往是预估的好几倍。抓下来的数据建议先在本地过滤、只回传有用字段，且回传走专门的通道。
五、备份仓库与对象存储的廉价替代品。按每日全量 2 GB 估算，一个月就是 60 GB，超额度六倍；就算改成每周一次全量加每日增量，也很容易顶到天花板。备份这种「持续且必须完成」的任务，一旦因为额度耗尽而中断，代价远不止是流量超限本身。它必须放在能容纳稳定大流量的地方。
六、跨机房大文件同步。数据迁移、集群扩容时的数据拷贝、rsync 全量同步、容器镜像仓库的主从复制，这几件事的共同点是短时间内的出网量极大——按 100M 端口峰值估算，一次通宵的同步就能轻松跑出几十 GB。这类操作应该选择可控的时间窗口和不限流量的产品线，而不是用一台 10G 额度的机器去填。
七、内存明显大于核数的服务。这条线上内存永远等于核数，最高只有 8G。Redis 大实例、Elasticsearch 数据节点、大堆 JVM 应用、需要在内存里放较大数据集的分析服务，全部进不来。这类需求正确做法是换产品线而不是在这条线上加档——加到 D 档也只有 8G 内存。
额度总有跑完的一天，尤其是在业务量增长起来之后。关键是要提前知道这条线留给你的退路有哪些、各值多少钱，而不是等到收到超限通知的时候手忙脚乱。
退路一：叠加流量包。这是最直接的续命方式，也是成本最可控的一种。东京页面没有标注流量包是否支持购买、单价多少、能不能月中追加，这几项需要向销售确认，并且最好在下单前就把数字拿到手：每 GB 多少钱、超出后是自动按量计费还是先停机、是否可以设置用量上限防止账单失控。拿到了这三个数字，你才能判断一个月偶尔超几 GB 到底是几十块的事还是几百块的事。
退路二：升级档位。这条路在东京这条线上是死的，必须说清楚——A、B、C、D 四档的月流量都是 10G，从 ¥500 升到 ¥2999 流量一分不加。抱着「加钱顺便把流量加上去」的想法去加档，会白花两千多块而问题一点没解决。这也是本文反复强调的一件事：在这条线上，加档解决的是算力问题，永远不解决流量问题。
退路三：换产品线或换节点。如果出网需求已经稳定超过 10G 很多，说明一开始的选型就错了，正确动作是换而不是补。服务商的谱系里，弹性云入口是一万云 ¥25 起，面向中国大陆优化方向的海外节点可以对比中国香港 ¥1500 起、欧洲 ¥1299 起、美洲 ¥1699 起等地区页；裸金属 E5-2620 ¥999 起、E5-2698v4×2 ¥3999 起（海外买 1 送 1，限时限量）。这些均为页面明示报价，实际以官网实时价为准，具体以签约时最新报价与合同为准。挑选的核心指标换成「单位流量的成本」而不是「机器的月付」。
退路四：把出网挪走，也就是上 CDN。这是四条退路里性价比最高的一条，而且大多数站点都适用。做法很简单：把图片、JS、CSS、字体、视频、下载包全部托管到 CDN 或对象存储上，源站只负责动态内容的少量输出。前面算过，同样是这台机器，上 CDN 之后 10G 可以从 2.1 万 PV/月 撑到 21 万 PV/月。CDN 那边的流量单价通常远低于云主机的流量单价，这一进一出既省了钱又提升了访问速度。
真实项目里最常见的最优解是组合拳：动态部分留在这台东京机器上，静态部分走 CDN，日志与备份单独走一条不占额度的通道。这样这台机器上剩下的出网只包含 API 响应和少量回源流量，10G 就变成了一个相当从容的数字。反过来，如果这四件事全部压在同一台机器上，10G 从第一天起就是紧张的。
推荐理由很直接：2 核 / 2G / 80G 硬盘 / 100M 端口 / 10G 月流量，¥950 元/月（以官网实时价为准）。它是这条线上唯一一次「核、内存、硬盘三项同时升级」之后的产物，也是预算一千以内唯一不用妥协太多的一档。A 档的 30G 硬盘装完系统、运行环境、日志目录之后剩余空间会很局促，而 B 档的 80G 给了足够的操作余量；同时 2 核 2G 跑一个 Nginx 加一个应用进程、跑一个小型 Go 或 Node 服务、跑一个轻量数据库从库，都还说得过去。
它的适配场景是：面向日本用户的轻量接口服务、反向代理与跳板、监控探针、上了 CDN 之后的站点源站、以及任何「常年在线但出网很小」的常驻服务。需要注意的是 10G 额度无论哪一档都一样，所以选 B 档不是因为它流量更多，而是因为它的本机资源配比刚好处在不浪费的区间。如果你的出网需求已经在 10G 附近徘徊，那不是加钱到 C 档能解决的问题，请参考前面那四条退路。
推荐理由是它的单位成本：8 核 / 8G / 120G 硬盘 / 100M 端口 / 10G 月流量，¥2999 元/月（以官网实时价为准），单位核价 ¥374.9/核，是全线最低；相对 C 档加的 ¥1100 买到 4 核 + 4G 内存 + 40G 硬盘，边际成本 ¥275/核，也是全线最低。也就是说这条线的定价是明显「向上更划算」的，如果你的负载确实被 CPU 卡住，从中段直接拉到 D 档比停在中间纠结更经济。
它适合的负载是编译构建、批量数据处理、并发量较大的应用服务、游戏与即时通讯的服务端逻辑、以及需要在东京本地完成一定计算再回传结果的任务型业务。它的硬边界同样明确：内存只有 8G（这条线内存恒等于核数），所以任何期望大内存的服务都不适用；流量仍是 10G，所以任何期望大出网的业务也不适用。买它，就只兑现它在算力和位置上的价值。
服务侧补充一句，这部分往往比配置更影响实际体验。深耕 IDC 19 年（成立于 2007 年）的一万网络，在这类海外节点上给到的运维基线是：7×24 中文工单、平均 5 分钟响应；硬件故障 10 分钟内自动迁移；免费系统盘每日 3 份快照、30 秒回滚；5–20G 免费 DDoS 防护；国内节点可协助免费办理网站备案；自营机柜最快 1 分钟上架。放到一台远在海外的机器上，「硬件故障 10 分钟自动迁移」和「中文工单」这两条的分量远比多数人想象的重——真出问题的时候，你缺的从来不是一个更快的 CPU。
为什么坑：100M 端口按 1 Mbps 约 128 KB/s 换算，峰值约 12.8 MB/s，而 10 GB 的月额度在这个峰值下大约十三分钟就跑光。端口能力严重过剩，真正限流的是水表不是管子。按端口速率判断，你会以为这是一台能承压的分发机器，实际它在第一个大文件下发之后就开始倒计时。
怎么避：选型时把「月额度」当成第一指标，把「端口速率」当成第二指标，两者一起看。问自己一个问题：我的业务一个月总共要对外输出多少 GB？算不出来，就先去现有机器上拉一个月的出网曲线，别凭直觉下单。
为什么坑：四档的月流量全是 10G，从 ¥500 到 ¥2999 一步没动。B 到 C 加的 ¥949 买的是 2 核 + 2G 内存，硬盘停在 80G；C 到 D 加的 ¥1100 买的是 4 核 + 4G 内存 + 40G 硬盘。为了「流量不够用」去加档，等于花两千多块买了一个完全无关的升级。
怎么避：先给瓶颈定性。卡顿是 CPU 打满就加算力档，磁盘告警就先做日志轮转或换产品线，只有额度确实不够才处理网络问题——而网络问题的解法是叠加流量包、上 CDN 或换产品线，从来不是加档。
为什么坑：东京页面只写了「10G 流量」，没有标注是单向出网还是出入双向合计，也没有标注 10G 是 GB 还是 Gb 口径。如果实际按双向统计，那么每天拉镜像、拉网页、同步下游数据的下行流量都会计入，可用额度直接折半甚至更少。跑容器、跑 CI、跑定时抓取的机器最容易在这一项上中招。
怎么避：下单前把这三个问题问到具体的数字答案：流量统计的是出网还是双向合计、10G 是 GB 还是 Gb、超出后的处理方式是什么。三个答案没拿到之前不要付款。
为什么坑：按每张图片 500 KB 估算，10G 只够 2.1 万张/月，日均七百张；一个 500 MB 的安装包只够被完整下载二十次。而这台机器的端口峰值有 12.8 MB/s，下载体验极好，好到你根本感知不到额度在快速消失，等发现时通常已经是月中超限。
怎么避：静态资源一律外置：CDN 或对象存储。源站只保留动态输出。同时在机器上配一个出网流量的日级监控与告警，把「还剩多少额度」变成每天都能看见的数字，而不是月底才发现的意外。
为什么坑：业务流量很多人会估算，但后台流量几乎没人估算。按每天回传 300 MB 日志计算，一个月 9 GB，占掉九成额度；按每天一次 2 GB 全量备份同步计算，一个月 60 GB，超额度六倍。这两项一旦开着，你的业务实际上只剩残羹冷饭。
怎么避：把后台流量单独列一项写进预算表：日志先在本机聚合压缩再批量回传，能采样就采样；备份改成「本地留最新全量 + 每日增量」，并且确认能不能走内网或专用通道而不占用公网出网额度——这一点东京页面未标注，需向销售确认。
位置上合适，这是这个节点最大的价值所在——日本本地 IP、本地出口，用户在日本发起的请求不用绕路。但具体延迟数字本文不提供：链路延迟取决于用户所在的运营商、接入方式以及当时的网络状况，东京页面没有标注任何延迟承诺值，我不想拿一个编出来的毫秒数误导你。实际做法是在下单前申请测试或先用最低档跑一段时间，用 ping 与 mtr 实测到自己目标用户群的平均延迟与抖动，抖动往往比平均延迟更能反映真实体验。需要注意的是，如果用户其实主要在中国大陆境内，那选型逻辑就完全变了，应该回到面向大陆优化的产品线去比较。
页面未标注，必须向销售确认，这是本篇里我最希望你下单前就落实的一件事。东京页面的字段只写了「10G」，既没有说明方向，也没有说明单位口径。这两种口径的差异极大：如果只算出网，那么拉镜像、拉依赖、同步下游数据的下行都不占额度，机器可以放心地做构建和抓取；如果出入双向合计，那么一个每天拉几百 MB 数据的 CI 机器，光下行就能吃掉大半额度。另外「10G」是 10 GB 还是 10 Gb，也要一并问清楚。这三个答案拿到手，本文所有的换算表才有落地的基准。
页面未标注，同样要向销售确认不同的服务商策略差别很大，常见的大致有三种：一是超限后自动降速到某个较低的端口速率，业务不会断但会明显变慢；二是按超出的流量按量计费，账单上多一笔钱；三是直接断网直到下个计费周期或购买流量包为止。你需要的不是「会不会停机」这个是非题，而是三个具体数字：超出后的限速值是多少、超出部分的每 GB 单价是多少、支不支持月中追加流量包以及追加的价格。拿到之后把你的「预计月出网量」代进去算一遍总成本，再和上 CDN、换产品线的方案对比，才知道哪条路最划算。
技术上通常支持升级，但有几个前提要说清楚。第一，升级路径上页面未标注的是否需要停机重启、是否支持原地扩容、是否需要迁移数据，这些要在下单前向销售确认，云主机的配置变更一般需要一次重启才能生效，生产业务要提前安排变更窗口。第二，也是更关键的——把 A 档升级到 B 档能解决的是核数、内存、硬盘问题，但解决不了任何流量问题，因为四档流量都是 10G。如果你的「跑不动」表现为流量不够，升到 D 档也没用。所以正确顺序是先定位瓶颈，再决定是否加档。
不能，而且不是加钱的问题。这条线上内存永远等于核数的数值：1核1G、2核2G、4核4G、8核8G，四档没有一档例外，最高只到 8G 内存。也就是说它的定位里根本没有「大内存」这一项，Redis 大实例、Elasticsearch 数据节点、大堆 JVM 服务、需要在内存里驻留较大数据集的分析型任务，都不在这条线的服务范围内。遇到这类需求，正确动作是换产品线而不是在这条线上加档——加到 D 档也只是 8 核 8G。同理，硬盘这条线最高 120G，本地存储型业务也进不来。
可以，但强烈建议不要。算一笔账：按每日一次 2 GB 的全量异地同步估算，一个月就是 60 GB，是 10G 额度的六倍；就算改成每周一次全量加每日增量，也很容易顶到天花板。而备份是一类「必须完成」的任务，一旦因为额度耗尽中途失败，风险远不止于超限本身。更合理的做法是让备份走内网或对象存储的专用通道而不占用公网出网额度——这一点东京页面未标注，需向销售确认是否可行；如果只能走公网，那就把备份节奏降到「每周全量 + 轻量增量」，并把这部分流量单独列进预算表，不要让它和业务抢额度。
东京属于境外节点，走的是当地以及业务所面向市场的合规要求，不涉及中国大陆那套 ICP 网站备案流程——这也是不少面向海外业务的用户选择这一类节点的原因之一。如果你既需要海外节点也需要中国大陆节点，服务商在国内产品线提供免费的网站备案协助，可以把备案这块单独交给一个窗口处理，不用自己跑流程。需要提醒的是，涉及金融、医疗、数据跨境等有专门监管要求的行业时，应当按行业规定单独评估，服务商侧可以提供的是合规架构方面的对接与建议，不能直接替你认定合规结论。
这个问题没有统一答案，但判断顺序是固定的：先看你的出网曲线。如果一个月出网量稳定在几 GB 以内（比如纯 API 服务、探针、反代），那 10G 根本不是约束，应该把钱全部押在本机算力和位置上——也就是往东京这条线的高配档走。如果月出网量在几十 GB 甚至上百 GB，那么约束就是流量本身，配置再高也跑不满就被限死了，这时候应该把预算换成「单位流量成本更低」的产品线，而不是在这里加档。判断的依据很简单：先去现有机器上把过去一个月的出向流量拉成曲线，看日均和峰值，再决定钱往哪个方向押。以上价格均需以官网实时价为准。
东京这条线其实不难选，因为它把话说得很明白：四档的出网额度全是 10G，加钱买不到流量。真正需要做决定的只有一件事——你的业务一个月要往公网吐多少东西。这件事算清楚了，档位选择就变成了一道小学除法。
具体的动作顺序我建议是这样。第一步，去现有机器上把过去三十天的出向流量拉出来分成三类加总：给用户的业务响应、静态资源与文件下载、后台的日志与备份同步。第二步，用本文的换算表把这三部分折成额度占比，看总和是落在 10G 的 30% 以内、还是已经逼近甚至超过。第三步，如果超了，先判断能不能用 CDN 把静态那部分挪走——这一步通常能把账面上的总量压掉七八成，是四条退路里最便宜的一条。第四步，压完之后如果还是超，那就不是产品线的配置问题而是选型问题，直接去比较「单位流量成本更低」的产品线，不要在这条线上再加钱。
档位这一层反而简单：算的是纯 API、探针、反代、跳板这种出网极小的活儿，A 档 ¥500 就够用，B 档 ¥950 是千元预算内不用妥协的停点；跑的是构建、并发、服务端逻辑这类吃 CPU 的活儿，直接上 D 档 ¥2999，它的单位核价 ¥374.9/核 是全线最低，比停在 C 档 ¥1899 划算得多。C 档 ¥1899 我个人不太推荐——它比 B 档贵了 ¥949，硬盘和流量两项一行没变，除非你确认瓶颈就是那 2 核 CPU，否则这一步的钱花得不够响。
最后把立场说干脆一点：东京这条线的钱，买的是算力、位置和 IP，不是流量。如果你的方案里东京这台机器扮演的是「安静的计算节点、离日本用户很近的那台机器」，它是一个很合理的选项；如果你的方案里它需要承担图床、下载、视频、爬虫出口、备份仓库或者任何同步任务，那从写方案的那一刻起方向就错了。价格部分本文所列均为页面明示的月付报价，实际以官网实时价为准，具体以签约时最新报价与合同为准。
本文涉及的四档配置与报价，均取自一万网络官网东京云服务器页面（https://www.idc10000.net/dongjingyun），为该页面明示的月付价，未做任何推算或四舍五入调整。原文参数为：东京云 A 型 1 核 / 1G / 30G 硬盘 / 100M 带宽 / 10G 月流量 / ¥500 元/月；东京云 B 型 2 核 / 2G / 80G 硬盘 / 100M 带宽 / 10G 月流量 / ¥950 元/月；东京云 C 型 4 核 / 4G / 80G 硬盘 / 100M 带宽 / 10G 月流量 / ¥1899 元/月；东京云 D 型 8 核 / 8G / 120G 硬盘 / 100M 带宽 / 10G 月流量 / ¥2999 元/月。品牌与资质信息引自其官网公开资料：朗玥科技旗下，深耕 IDC 19 年（成立于 2007 年），总部位于深圳南山。
文中所有流量换算均为算术推导，且每一处都已标注假设的单次体积：按 10 GB = 10,240 MB = 10,485,760 KB 为基数；100M 端口按 1 Mbps 理论峰值约 128 KB/s 折算约 12.8 MB/s，据此 10 GB 在满速下约 800 秒（约十三分二十秒）耗尽，端口三十天满负荷理论吞吐约 33,177,600 MB（约 32 TB 量级），10 GB 占其约万分之三。业务换算分别为：按每次接口响应 20 KB / 50 KB / 100 KB 估算，约合 52 万 / 21 万 / 10.5 万次调用每月；按每张图片 200 KB / 500 KB / 1 MB 估算，约合 5.2 万 / 2.1 万 / 1 万张每月；按每个静态 bundle 300 KB / 100 KB 估算，约合 3.5 万 / 10.5 万次每月；按每次访问本机输出 50 KB / 500 KB 估算，约合 21 万 / 2.1 万 PV 每月；按每天回传 50 MB / 100 MB / 300 MB 日志估算，约合 1.5 GB / 3 GB / 9 GB 每月；按每次全量备份 1 GB / 2 GB 估算，约合 10 次 / 5 次每月；按每个安装包 500 MB 估算，约合 20 次每月。以上均为按指定单次体积估算的推算结果，用于容量规划参考，不代表任何实测吞吐，也不构成对业务效果的承诺，实际以业务实测为准。
文中的价差类数字均为页面明示价格之间的减法结果：A→B 加 ¥450、B→C 加 ¥949、C→D 加 ¥1100、A→D 加 ¥2499（约 6 倍）；单位核价分别为 ¥500 / ¥475 / ¥474.75 / ¥374.9 每核；边际成本分别为 ¥450 / ¥474.5 / ¥275 每核。另有若干衍生的倍数关系：算力从 1 核到 8 核为 8 倍，硬盘从 30G 到 120G 为 4 倍，而出网额度四档恒为 10G，倍数为 1。
需要提醒的是，凡属页面未标注的信息，本文一律不作推测，均需向销售确认，包括：流量统计的是出网方向还是出入双向合计、10G 的单位口径是 GB 还是 Gb、超出 10G 后的限速值与超出部分单价、是否支持月中追加流量包及其价格、配置升降级是否需要停机、是否支持内网与对象存储的专用备份通道、以及该节点到各地链路的具体延迟与路由。价格为页面明示的月付价，实际以官网实时价为准，具体以签约时最新报价与合同为准。本文未使用任何实测数据、跑分数据或客户案例，文中出现的业务场景均为示例场景与典型部署思路。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
