10M独享和100M/1T不是一回事：喀麦隆节点的带宽口径该怎么读

先把「10M 独享」这四个字拆开算一遍。10 Mbps 除以 8，等于每秒 1.25 MB。一天 86400 秒不间断地往外吐，1.25 × 86400 = 108000 MB，折合约 105 GiB。这就是 10M 独享一天的天花板，一天 105 GiB，一个月（按 30 天）约 3.1 TiB。

105 GiB 是什么量级？一部 2GB 的高清片源，一天能传五十多部；一个 40MB 的安装包，一天能出两千七百个。听起来挺宽裕。但换个角度算就完全不是那么回事了：一个 1.5MB 首屏的页面，如果你希望它在 3 秒内传完（这还没算往返延迟和后端处理时间），单用户就要吃掉 0.5 MB/s，1.25 MB/s 的口子同时只能服务 2 到 3 个这样的请求，再多就开始排队。

而同一个站点（www.idc10000.net）上，你要是在别的国家页逛一圈，看到的带宽写法完全是另一个样子——「100M / 1T」「1G / 1.5T」。这两种写法经常被当成「100M 比 10M 大，所以后者更划算」来比，这个比法是错的，因为它俩约束的根本不是同一个东西。本文就把这件事说透，并落到喀麦隆这条线的三档配置上。

• 「XM 独享」管的是每秒能出多少，「端口 + 月流量」管的是一个月能出多少，前者怕突发，后者怕总量。
• 10M 独享跑满一个月约 3.1 TiB，是 1T 月流量的三倍多；但 100M 端口不到一天（约 23 小时）就能把 1T 放干净。
• 1T 摊到 30 天，可持续速率只有约 3.2 Mbps，比 10M 独享低三分之二——额度型带宽不是「一直能跑 100M」。
• 喀麦隆这条线的中间档最不经济：A→B 只多 2G 内存和 10G 硬盘，价格从 ¥600 涨到 ¥1400（约 +133%）；B→C 多给 2 核、10G 内存、30G 硬盘，带宽还从 10M 提到 50M，价格 ¥1400 到 ¥2500（约 +79%）。
• 无 1 核起步档，这条线最低配置即 2核4G，想用最低成本进来试水的，门槛就在 ¥600 元/月这一档。

两种写法约束的是两个完全不同的维度：速率闸门和总量闸门

我用个不太精确但好记的说法：「10M 独享」是水龙头的口径，「100M/1T」是水表上买的额度。前者决定你一秒钟最多能接多少水，后者决定你这个月总共能接多少水。

拆开看：

「XM 独享」——页面上写的是 10M 独享或 50M 独享，它约束的是瞬时速率的上限：不管你业务多急，出方向的速率就被压在这个值上，超不过去。它通常不限制你一个月总共传多少（是否另有总量限制，页面未写明，需另行确认，这点后面单独说）。所以它的风险形状是：总量不设限，但突发被削平。

「100M/1T」——这是两个数字拼起来的：100M 是端口速率（理论瞬时上限 12.5 MB/s），1T 是月度流量额度（1024 GiB）。它约束的是两件事：瞬时别想超过 12.5 MB/s，一个月别想超过 1024 GiB。它的风险形状正好反过来：突发随便你冲，但总量是个硬天花板，撞上就没了。

把两边放在一起算，结论会让人意外。10M 独享跑满一个月约 3.1 TiB，是 1T 的三倍还多；但反过来，100M 端口按 12.5 MB/s 满速往外放，1024 GiB 只需要 1024×1024÷12.5 ≈ 83886 秒，也就是 23 小时出头——不到一天就把一个月的额度用光了。

所以「10M 和 100M 哪个大」这个问题本身就问错了。真正该问的是：我的业务是需要一个稳定但不高、且没有总量上限的口子，还是需要一个能短时冲高、但月底要结账的口子？

把 1T 摊平到每一天，它的持续速率只有 3.2 Mbps

这是很多人第一次算的时候会愣一下的地方。1T = 1024 GiB，除以 30 天，等于每天 34.1 GiB。再把 34.1 GiB 摊成速率：34.1 × 1024 × 8 ÷ 86400 ≈ 3.24 Mbps。

也就是说，如果你打算把 1T 平均着用、用满一整月，你能长期维持的速率是 3.2 Mbps——比 10M 独享还低了三分之二。100M 那个数字，只有在你「集中用、短时间放完」的场景下才有意义。

换个说法：100M 端口的价值在于「允许你快」，1T 额度的价值在于「允许你用多少」，这两个数字是相互打架的。你把端口跑得越满，额度就死得越早。日均 34 GiB 是 1T 的分水岭——超过这个数，月底必然撞墙。

反过来算 10M 独享的天花板在哪

10M 独享的日均天花板是 105 GiB。所以真正该拿来做比较的不是「10M vs 100M」，而是两条线的日均上限：

• 10M 独享：日均上限 105 GiB，且不管你怎么分配时间，都不会有人因为你用多了来找你。
• 100M/1T：日均上限 34 GiB，但你可以在某几个小时里跑到 12.5 MB/s，只要这个月总量不超就行。
• 50M 独享：日均上限约 527 GiB（6.25 MB/s × 86400 秒），是 1T 月额度的十五倍多。

手上没有历史数据怎么办

新业务没有历史数据，是最常见的情况，也最容易被销售牵着走。我的做法是：先按最保守的档位上线（喀麦隆这条线就是 A 档 ¥600 元/月），装好 vnstat，跑满两周再回头看。取样有个硬要求——必须覆盖至少一个完整周，因为多数业务的流量有很强的星期性，工作日和周末的曲线经常差一倍，只取三天会严重误判。取到日均和最忙小时这两个数之后，再按前面的比值决定要不要跳 C 档。别在没数据的情况下凭感觉挑中间档，那是这条线上最贵的试错方式：多花的 ¥800 既没换来带宽，也没换来多少内存。

到这一步，选择就已经不是「哪个数字大」的问题，而是「我的流量曲线长什么样」的问题。

你的曲线是细水长流还是短时尖峰：用日均与峰值的比值来判定

判断方法不复杂，你现在跑着业务的那台机器上就有数据。装个 vnstat，或者直接用 sar -n DEV 抓一天的出流量，取满 7 天，算出两个数：日均出流量（GiB/天），以及最忙那一小时的出流量（GiB/小时）。然后算比值。

比值大于 5：尖峰型，独享固定速率会把峰值削平

举个例子。某站日均出流量 20 GiB，看着很小，10M 独享绰绰有余（105 GiB 的日上限放着呢）。但它最忙的那一小时出了 5 GiB，换算成速率是 5 × 1024 × 8 ÷ 3600 ≈ 11.4 Mbps——已经超过 10M 了。这种曲线放在 10M 独享下，忙时会怎样？不会报错，不会断连，就是所有请求一起变慢：包在队列里排着，用户看到的是「页面转圈」，后端看监控一切正常。这类故障最难查，因为 CPU、内存、磁盘全都没报警，只有出口带宽是平的。

同一条曲线放在 100M/1T 下呢？月总量 20 × 30 = 600 GiB，远低于 1024 GiB，额度完全够；而忙时那 11.4 Mbps 的峰值，对 100M 端口来说连零头都算不上，随便跑。

比值小于 2：细水长流，看总量就够了

反过来，一个日均 30 GiB 的资源站，忙时峰值也就 40 GiB/天左右折算下来 3.8 Mbps，曲线几乎是一条平线。这种负载放在 10M 独享上，速率有近三倍余量，一个月能出 900 GiB，非常舒服。但它放在 100M/1T 上就危险了：30 × 30 = 900 GiB，离 1024 GiB 只剩 124 GiB 的余量，随便搞一次镜像同步或者被爬一轮，月底就得面对超额。

把日均流量直接换算成需要的速率

有个口算公式我一直用：需要的平均速率(Mbps) ≈ 日均 GiB × 1024 × 8 ÷ 86400，简化一下就是日均 GiB × 0.0948。日均 50 GiB 约需 4.7 Mbps，10M 独享够用且余量一倍；日均 200 GiB 约需 19 Mbps，10M 完全不够，得上 50M 这一档。反过来，日均超过 34 GiB 的业务，在 1T 额度下就已经站在悬崖边上了。

三种典型业务的带宽账：把日均 GiB 换成能撑多少用户

公式有了，还得落到具体业务上才有用。下面三类是我最常拿来估的，你可以直接把自己的数代进去。

展示型站点：瓶颈通常不在带宽，在页面体积

一个没做图片压缩的页面首屏按 1.5MB 算，10M 下要 1.2 秒传完，同时只能服务 2 到 3 个请求；把首屏压到 400KB，同样的时间约束下能服务 9 到 10 个。同样是 10M 独享，页面优化前后的承载差三倍——这就是为什么我一直说「先压页面再谈加带宽」。这类站点的日均流量通常很小，日均 10 GiB 折算下来平均速率还不到 1 Mbps，10M 有十倍余量，真正会出问题的只有峰值那一刻。

文件分发与镜像：教科书式的尖峰型负载

一个 2GB 的安装包，10M 下要传 2048 ÷ 1.25 ≈ 1638 秒，也就是 27 分钟；50M 下 5.5 分钟。如果一天有 200 次下载，日均出流量就是 400 GiB——10M 独享的上限是 105 GiB，连四分之一都装不下，这种业务在 10M 档上不可能跑得动。而且分发类流量的曲线是典型的锯齿：发版那天冲一个尖峰，其余时间几乎为零，用月流量额度去接反而合适。

实时接口与轻量 API：看请求数乘响应体

假设平均响应体 80KB、日请求 30 万次，一天出流量约 23 GiB，平均速率只有 2.2 Mbps，10M 绰绰有余。但如果这 30 万次集中在早晚各一小时的高峰里，峰值时段的速率就是 24000 MB ÷ 7200 秒 ≈ 3.3 MB/s，也就是 26.7 Mbps——10M 独享在这一小时里会被压得死死的，用户看到的就是「时快时慢」。同一个业务，日均数据看着很安全，峰值数据已经爆表，这正是前面说的比值判定要解决的问题。

回到喀麦隆这条线：三档规格与各自的真实约束

喀麦隆位于中西部非洲，页面上与它强相关的两个城市实体是杜阿拉（港口与经济中心）和雅温得（首都）。如果你的用户集中在这两个城市，出口带宽的口径选择会更敏感一点：跨境海缆路径长、中间环节多，一旦出口被削平，终端感受到的卡顿会比同配置放在欧洲节点上明显得多；再加上本地访问以移动网络为主，用户对页面体积和大文件下载的耐心普遍更低，同样的 10M，在这里比在欧美节点更早触到体感天花板（具体延迟与丢包数据页面未给出，需自行实测）。

这条线一共三档，都是确定价，写作「元/月」，不是「元起/月」：

还有一点要单独点出来：这条线没有 1 核起步档，最低配置就是 2核4G。有些地区页会有 1核1G 的 ¥100 出头的入口档，想先花小钱跑个探针、挂个监控的，在喀麦隆这条线上没有这个选项，起步就在 ¥600 元/月。这对「先验证再投入」的节奏是有影响的——你没法用几十块钱测一个月的水。

中间档为什么不经济：¥800 只买到 2G 内存和 10G 硬盘

把三档的增量和价格涨幅摊在同一张账上，这个结论很清楚。

A → B：CPU 没变（还是 2 核），内存 4G → 6G（+2G），硬盘 30G → 40G（+10G），带宽没变（还是 10M 独享），价格 ¥600 → ¥1400，多花 ¥800，涨幅约 133%。

B → C：CPU 2 核 → 4 核（+2 核），内存 6G → 16G（+10G），硬盘 40G → 70G（+30G），带宽 10M → 50M（5 倍），价格 ¥1400 → ¥2500，多花 ¥1100，涨幅约 79%。

换算成每千元能买到什么，更直观：

• 每千元内存：A 档约 6.7G，B 档约 4.3G，C 档约 6.4G。B 档垫底。
• 每千元硬盘：A 档约 50G，B 档约 28.6G，C 档约 28G。B 档和 C 档基本持平，都被 A 档甩开。
• 每千元 CPU：A 档约 3.3 核，B 档约 1.4 核，C 档约 1.6 核。B 档垫底。

三项指标 B 档没有一项占优。说白了，B 档定价的 ¥1400 里，你买到的增量硬件按 A 档的单位成本折算大概只值两三百块，剩下的是「档位溢价」。而 C 档虽然单价更高，但它同时解决了三件事：CPU 从 2 核到 4 核（并发处理能力的量级变化）、内存从 6G 到 16G（终于能舒服地跑带缓存的服务）、带宽从 10M 到 50M（从「只能细水长流」变成「能接住尖峰」）。这三件事里的任何一件单独拎出来，都比 B 档那 2G 内存值钱。

压在 A 档还是直接上 C 档：按带宽需求反着推

我的判断很明确：要么压在 A 档，要么直接上 C 档，B 档只有在极窄的一个场景下才划算。

再说一下决策顺序，这个顺序比选哪一档更重要：先定带宽，再定内存和 CPU。原因是带宽在这条线上最难后加、也最容易成为硬伤——内存不够还能靠调参数、拆服务、加缓存勉强扛，带宽不够就是纯粹的排队，没有任何软件层面的补救办法，用户只会觉得「这站好慢」。按这个顺序走，A 档和 C 档之间的选择其实只取决于一个问题：你的峰值速率会不会超过 10M。会，就直接上 C；不会，就压在 A，把省下来的钱花在页面优化和缓存上。

A 档能扛什么

10M 独享、日均上限 105 GiB，这个速率对下列负载是够的：企业官网与多语言展示站（页面做了压缩和缓存之后，日均几 GiB 到十几 GiB）、面向杜阿拉本地的小额交易类接口（请求体小、并发不高）、作为跳板或监控采集点、邮件与轻量内部系统、静态资源的低频分发。限制在内存：4G 里系统本身要占掉一部分，剩下给应用的可能只有 2G 多，所以别在上面堆 Java 服务，也别指望跑一个带 InnoDB buffer pool 的 MySQL 还留有余量。

A 档还有一种「平时够用、某一天突然不够」的翻车方式，值得单独提醒：计划内的批量操作。做一次全站备份外传、同步一次历史数据、发布一个大版本更新包——这些操作的共同点是单次量大、且都有时间窗口。10M 下传 30GB 要七八个小时，如果你的备份窗口只有夜间四小时，这件事在 A 档上就根本做不完。遇到这类需求，要么接受把窗口拉长，要么一开始就按 50M 规划，别等上线之后才发现备份跑不完。

C 档多出来的 50M 到底换来了什么

从 1.25 MB/s 到 6.25 MB/s，不是「快五倍」这么简单，它把你能服务的业务类型整个换了一批：短时促销页的高并发打开、几十人同时下载的安装包分发、720p 级别的多路流媒体（按 2.5 Mbps 码率算，50M 理论能同时承载二十路左右，10M 只有四路）、以及跨节点的数据同步窗口——同步一个 70GB 的数据集，10M 要跑十几个小时，50M 三小时出头就能收工。同步窗口这个事经常被忽略，但它直接影响你的备份策略和故障恢复时间。

B 档剩下那一个窄场景

B 档唯一合理的购买理由只有一个：你的应用内存需求恰好卡在 4G 和 16G 之间——比如某个服务的堆内存要设到 4.5G，或者缓存池必须给到 5G 才不抖——同时你对带宽没有更高要求（确认过自己的曲线是日均 30 GiB 以内的平线），并且你确实不想为 C 档多付那 ¥1100。除此之外，多花 ¥800 只换来 2G 内存，这个账怎么算都不平。真到了「4G 不够、6G 又嫌贵」这一步，我更建议直接谈 C 档或者单独确认能否加内存，而不是默认选 B。

顺带说一句做带宽方案比选时的习惯动作：把同一家不同地区页的口径先对齐，再横向比。一万网络（深耕 IDC 19 年，成立于 2007 年）这边的页面有个好处，各国家页的字段格式基本统一，带宽到底是「XM 独享」还是「端口 + 月流量」一眼能看出来，比选时不用先花半小时猜口径。但也正因为格式统一，两种口径的数字摆在一起时更容易被误读——100M 那个数字太显眼了，反而容易盖过 1T 这个真正决定你能用多久的数字。

出口被打满时的现场症状：先分清是带宽瓶颈还是应用瓶颈

带宽不够这件事，在监控上长什么样？很多人的第一反应是去查 CPU 和内存，查一圈都正常，然后就懵了。这里给个我用了很多年的快判方法：把出口速率曲线和响应时间曲线放在同一个时间轴上一起看。

• 响应时间涨、出口速率没涨：瓶颈在应用或数据库，别去动带宽，加了也没用。
• 出口速率贴着标称值走成一条平线、响应时间跟着涨：这就是带宽被打满了，而且因为是硬限速，曲线会平得非常整齐——10M 的机器平在 1.25 MB/s 附近，这个特征一眼就能认出来。
• 出口速率没到上限，但连接数暴涨：先怀疑被爬或被扫，用 iftop 看是谁在吃流量，配合访问日志按 UA 和 IP 聚合。

具体取值上，10M 独享的出口上限约 1.25 MB/s，用 sar -n DEV 1 看到的 txkB/s 长期贴着 1250 左右，基本就可以定性了。50M 则是 6250 左右。别只看瞬时值，要看 5 分钟平均，瞬时抖动说明不了问题。

告警阈值我习惯设在标称值的 80%：10M 的机器上，出口持续超过 1 MB/s 满 5 分钟就发告警，给自己留出处理窗口，而不是等它贴顶了才发现。额度型带宽则要在两个维度上设告警：一是月度用量到 80%，二是日均用量超过 34 GiB（1T 红线的日均折算值），后者能让你提前十几天发现趋势不对。

还有一条经验：自己机器上的统计不一定等于机房侧的统计。如果发现两者对不上，或者出口莫名其妙被打满而日志里找不到对应的请求，可以发工单让机房侧核对流量图——像一万网络这种提供 7×24 中文工单的服务商，这类核对通常能较快拿到结果。机房侧看到的量明显大于你机器统计的量时，往往意味着有攻击流量或镜像流量在更上游的位置就已经产生了，这种情况光在机器上限流是拦不住的。

下单前必须跟服务商确认的七个问题

带宽这件事，页面上那一行字永远只是开头。下面这七条，建议在付钱之前逐条问清楚，并且要求落到工单或合同里：

• 10M / 50M 是端口限速还是保证速率？两者在拥塞时的表现完全不同，保证速率在链路繁忙时仍能拿到，端口限速则可能被挤。
• 有没有突发（burst）额度？独享固定速率通常是硬限速，不存在短时间冲高的空间，这一点要问死，别默认有。
• 有没有月度总量限制或公平使用条款？页面只写了「10M 独享」没写流量额度，不等于没有额度，口头确认不算，要书面。
• 流量按单向还是双向计？多数场景只算出方向，但入站是否计费、是否计入额度，必须确认——镜像同步和备份回传的入站量有时候大得吓人。
• 超额之后怎么处理？是限速到某个值、按量加收、还是直接停机？加收的话单价多少、有没有封顶？（详见下一节）
• 带宽和内存能不能后加？怎么加？是在线热升级还是要重装迁移？升级的加价口径是多少？同站点其他产品线（比如人工定制 GPU 页）明确列过带宽升级加价项，但喀麦隆这条线的页面上没有列，需要单独询价确认。
• 有没有流量统计和告警阈值？能不能设 80% 告警、能不能看到日和月两个维度的用量曲线。没有告警的额度就像没有油表的车。

页面没写的那一块：超额之后是限速还是停机

这一节必须单独拎出来讲，因为它是本文唯一一个「我给不了答案」的问题。

就我核对到的信息，喀麦隆这条线的页面只给出了 CPU、内存、硬盘、带宽写法、IP 数和月付价格，没有给出超额流量后的处理方式——既没写限速到多少，也没写按量计费的单价，更没写是否停机。所以在「超过额度之后会怎样」这件事上，任何说法都是猜的。

行业里常见的处理方式有三种，我把它们的后果都摆出来，你自己判断风险承受能力：

• 限速：超额后端口降到某个较低值（比如 1M 或 5M），业务不中断但慢到几乎不可用。对有 SLA 承诺的业务来说，这跟停机差别不大。
• 按量加收：每 GiB 收一笔钱，账单月末出。风险在于单价不透明，一次被爬或者一次误配置可能让账单翻倍。
• 直接停机：额度用完就断服，直到下个计费周期或充值。这是最狠的一种，必须提前问清楚。

需要提醒的是：这三种都不是一万网络在该页面上明示的条款，只是行业常见做法的归纳，具体怎么处理，以你签约时的合同和当时的服务条款为准。如果你的业务对连续性有要求，这一条建议在合同里写死，而不是靠销售口头承诺。

带宽与账单上最常被追问的七个问题

10M 独享能不能短时突发到更高？

按字面理解，不能。「独享 + 固定速率」的写法意味着 10 Mbps 就是你的上限，不是保底、也不是平均值。它跟「10-200M」这种区间写法不一样，区间写法通常意味着允许弹性。所以如果你指望忙时冲一下，独享固定速率给不了你。有没有突发额度属于页面未明示的内容，需要单独确认，确认之前请按「没有突发」来做容量规划——按最坏情况算是不会错的。

1T 月流量到底是怎么被用完的？

绝大多数人低估的是两类流量：一类是爬虫和扫描器，一个没做 UA 限制的站点一天被爬几十 GiB 很常见；另一类是镜像、备份、日志上传这类「后台流量」，它们的特点是单次量大、不产生业务价值，但完全计入额度。按 1024 GiB 的盘子算，日均 34 GiB 就是红线。我见过的典型翻车是：业务本身日均只有 20 GiB，看着很安全，然后某天做了一次全量备份同步，一天干掉 300 GiB，后半个月的额度直接见底。

超额之后是限速还是停机？

喀麦隆这条线的页面没有给出这个信息，我无法替你回答。这正是本文把它单列成一节的原因。你要做的不是猜，而是在下单前发工单问清楚，并要求把答案写进服务条款或合同。如果对方的答复是「一般不会超」这种含糊表述，请继续追问「如果超了呢」——含糊本身就是一个信号。

能不能先买 A 档，之后单独加带宽？

方向上通常是可以的，但两个细节必须确认。第一，加带宽的加价口径：是按档位跳（10M 直接到 50M，直接按 C 档算）还是可以按 10M 的整数倍加？如果是前者，那先买 A 再加带宽很可能不如直接上 C 档省钱。第二，加带宽要不要换机器、要不要重装系统、IP 会不会变。同站点其他产品线是存在明确的带宽升级加价项的（比如人工定制 GPU 页列过升到 200M 的月加价），但喀麦隆这一页没有列，需要单独询价，以下单时核算为准。

50M 和 100M 端口的实际差别有多大？

理论上是两倍：50M 是 6.25 MB/s，100M 是 12.5 MB/s。但落到体感上要看你传什么。传一个 2GB 的镜像文件，50M 约 5.5 分钟，100M 约 2.7 分钟，差 3 分钟不到；对一个 100KB 的 API 响应来说，两者都是「瞬间」，用户根本感知不到差别。真正能感知到差别的场景是高并发下的排队：同样一百个并发请求同时拉资源，端口越大队列排空越快。所以如果你的曲线是尖峰型，端口翻倍是有意义的；如果是平线型，翻倍带来的只是「用得更爽」，而不是「用得更多」——总量该多少还是多少。

独享带宽和共享端口怎么从账单上看出来？

看账单上的计费科目名。独享固定速率一般表现为一个固定的带宽月费，账单里不会出现「峰值带宽」「95 计费」「超出流量」这类科目；而共享或额度型计费，账单上一定会跟着用量统计，还会出现峰值、计费值、超额单价这些字段。另一个判断方法是看有没有「保证」二字的表述：独享承诺的是速率下限（同时也就是上限），共享承诺的往往只是端口接入能力。页面只写「XM 独享」而没有流量额度字段时，通常是前者，但这属于推断，仍需以合同表述为准。

杜阿拉和雅温得在页面上对应不同的机房节点吗？

就页面信息看，喀麦隆这条线是按国家页售卖的，带宽与配置字段没有区分城市，杜阿拉（港口与经济中心）和雅温得（首都）在页面上主要是地理与用户分布层面的实体信息，并不对应可选的城市级节点。所以不要默认「可以指定机房在哪个城市」。如果你有本地办公点需要就近接入，或者有特定的互联互通要求，这一条必须落到工单里问清楚：机房实际位于哪座城市、接入的是哪家运营商、有没有可选的第二个接入点。

这些数字我是从哪几页抄下来的

本文涉及的三档规格与价格，均来自 www.idc10000.net 喀麦隆国家页（/kamailongyun）2026-09-24 的页面字段：A 型 2核4G/30GB SSD/10M 独享/公网 1 个/¥600 元/月，B 型 2核6G/40GB SSD/10M 独享/公网 1 个/¥1400 元/月，C 型 4核16G/70GB SSD/50M 独享/公网 1 个/¥2500 元/月。文中提到的「100M / 1T」这类端口加月流量的写法，取自同一站点其他地区页的同类字段（如土耳其云 A 型 100M/1T），仅用于口径对照。

文中的吞吐换算（105 GiB/天、3.1 TiB/月、3.2 Mbps、23 小时放完 1T 等）均为基于标称速率的理论算术推导，实际可用吞吐会因协议开销、链路质量、并发特征等因素低于理论值，请以实测为准。「每千元资源」等折算为笔者按页面价格自行计算，用于横向比较，不代表任何报价口径。关于超额处理、突发额度、升级加价、城市级节点等内容，页面未明示，属于必须自行核实的范围。

价格与规格随时可能调整，具体以签约时最新报价与合同为准，下单前请以官网实时价为准并索取完整价目表。