澳大利亚云四档套餐端口都是100M：扩容该加机器还是升配置？

把澳大利亚这条云主机产品线的四档配置从 A 排到 D 摊开看，会出现一个很别扭的现象：CPU 从 1 核翻到 6 核，内存从 2G 翻到 16G，硬盘从 40G 翻到 320G，月流量从 2T 涨到 5T，月付从 ¥150 涨到 ¥1000——翻了六倍多。唯独端口那一栏，从头到尾写着同一个数字：100M。你加钱加到顶配，出网的速率天花板和 ¥150 那台入门机一模一样，一丁点没变。

这就逼出一个必须想清楚的问题：我从 A 型加到 D 型，到底买到了什么？没买到什么？当业务真的涨起来、100M 端口开始卡脖子的时候，正确的动作是继续往上加钱升到 D 型，还是横向多加几台便宜机器把流量摊开？

下面这几条是本文的核心判断，先放在前面：

一、四档端口恒定 100M，纵向升档买不到任何额外的出网速率——你花 ¥1000 买的 D 型，出网能力跟 ¥150 的 A 型完全相同，多花的钱全花在 CPU、内存、硬盘和月流量额度上。

二、100M 端口持续跑满，理论月吞吐约 31T，而最高档只给 5T 流量额度——这条线上真正的长期约束是流量额度，端口是留给突发用的，两者的角色完全不一样，别混为一谈。

三、瓶颈分两种，处理方式完全不同：长期平均用量大、月流量额度见底，纵向升档有效但天花板只有 5T；同一时刻并发大、端口被打满，纵向升档一点用都没有，只能横向加机器。

四、算单价的话，2 台 B 型（¥560）和 1 台 C 型（¥550）几乎同价，但前者出网能力翻倍、故障域一分为二——在端口恒定的产品线上，横向拆分几乎总是更划算。

五、每核单价从 A 到 C 一路下降（¥150→¥140→¥137.5），到 D 型反而反弹到 ¥166.7——D 型是这条线上边际成本唯一上升的一档，它贵在内存和硬盘，不在出网。

四档套餐逐列摊开：涨的是这四列，没动的是那一列

先把这条线的四档原样摆出来，一列一列看清楚。澳大利亚云 A 型 1 核 2G、40G 硬盘、100M 端口、2T 月流量、1 个 IP，月付 ¥150；B 型 2 核 4G、80G 硬盘、100M 端口、3T 月流量、1 个 IP，月付 ¥280；C 型 4 核 8G、160G 硬盘、100M 端口、4T 月流量、1 个 IP，月付 ¥550；D 型 6 核 16G、320G 硬盘、100M 端口、5T 月流量、1 个 IP，月付 ¥1000。以上为官网地区页公示价，实际以官网实时价为准。

看出门道了吗？CPU、内存、硬盘、月流量这四列，从 A 到 C 是标准的翻倍节奏：1 核到 2 核到 4 核，2G 到 4G 到 8G，40G 到 80G 到 160G。价格也跟着走：¥150 到 ¥280 到 ¥550，每一档大约是前一档的 1.9 倍左右。这条规律很有用，因为它意味着这条线的单位成本是可以精确外推的，预算预测不会拍脑袋。

但有两处打破了这个节奏，必须单独拎出来说。

第一处是端口。四档全是 100M，一档都没涨。在一个"往上加钱什么都变多"的价目表里，有一个字段从头到尾纹丝不动，这件事本身就是最强烈的信号——它在告诉你，出网能力在这条产品线上不是靠钱能买的资源，它是一个固定在规格表里的上限。

第二处是 D 型。它打破了"翻倍"的节奏：CPU 从 4 核只涨到 6 核（1.5 倍），但内存从 8G 跳到 16G（2 倍）、硬盘从 160G 跳到 320G（2 倍）、价格从 ¥550 跳到 ¥1000（1.8 倍）。也就是说，D 型的额外溢价主要压在内存和硬盘上，而这两样东西只有在你的单进程真的需要大内存、真的需要本地大容量存储时才用得上。

端口恒定意味着什么：出网能力不随花钱增长

端口速率和月流量额度，是两件完全不同的事

很多人把"100M"和"2T 流量"当成一回事，这是理解这条产品线最大的误区。说白了：端口速率是车道宽度，决定同一时刻最多能过多少车；月流量额度是这个月总共允许过多少车。一条两车道的高速，一个月只允许 1000 辆车通过，和一条两车道高速一个月允许 10 万辆车通过，车道宽度是一样的，区别在于你能跑多久、跑多少趟。

换到服务器上：100M 端口意味着你的机器对外吐数据的瞬时速率上限是 100Mbps，换算成下载速度大约是每秒 12.5MB（扣掉 TCP/IP 与以太网开销后实际可用一般在每秒 11MB 上下）。不管你买的是 A 型还是 D 型，这个上限都是每秒 12.5MB。2T、5T 则是这个月累计能吐出去的数据总量，用完了会怎样，取决于服务商的规则（官网页面未明示超额后的处理方式，这一点必须下单前问清楚，别凭经验想当然）。

100M 端口在这条线上到底能吃掉多少流量

做个简单除法就明白了。100Mbps 持续跑满，一天是 12.5MB × 86400 秒 ≈ 1080GB，也就是大约 1.05T。一个月按 30 天算，理论吞吐约 31.6T。

再看这条线给的流量额度：A 型 2T、B 型 3T、C 型 4T、D 型 5T。也就是说，就算你真能把 100M 端口 24 小时跑满，A 型的 2T 大约 1.9 天就见底，B 型 3T 约 2.8 天，C 型 4T 约 3.8 天，D 型 5T 约 4.7 天。

反过来把额度摊到每一天：A 型 2T 摊到 30 天是每天约 68GB，折合平均带宽约 6.5Mbps，只有端口能力的 6.5%；D 型 5T 摊到 30 天是每天约 171GB，折合平均带宽约 16Mbps，占端口的 16%。

这组数字说明什么？说明这条产品线的设计意图很明确——它假设你的业务是"日常低流量 + 偶尔突发"。平时平均只用掉端口的一小部分，端口宽度是为了扛峰值那几分钟准备的。如果你想做的是长期大流量持续输出（下载站、图床、音视频分发、做 CDN 的源站），这条线从设计上就不是给你用的，加钱也买不到：D 型给到 5T 已经是这条线的顶，而端口速率还是那个 100M。

这里要补一个更细的区分，因为它直接决定扩容方向：

如果你的问题是总量型——每天吐出去的数据多，月流量额度总是不够用，但同一时刻并不挤——那么纵向升档是有效的，因为流量额度确实在涨（2T→5T）。但天花板很低，最高只有 5T，而且越往上越贵。

如果你的问题是速率型——平时流量不大，但一到活动、一到高峰期、一到批量上传下载，端口瞬间被打满，用户端表现为页面加载转圈、接口超时——那纵向升档一分钱作用都没有。A 型和 D 型在这件事上完全等效。这时候唯一的出路是横向加机器，让两台、三台机器各自用各自的 100M 端口。

什么时候该纵向升档：瓶颈在这台机器内部的那几种情形

说了半天横向，也得把纵向说清楚。升档不是错，错的是搞不清瓶颈在哪就往上加钱。下面这几种情形，纵向升档是对的解法。

单机构建、编译与批处理

典型场景是 CI/CD 的构建机。1 核的 A 型跑一次完整的项目构建（Maven、Gradle、Go build、前端打包），可能要十几二十分钟，开发提交一次等一次。这类任务的瓶颈在 CPU 核数和内存，跟网络一点关系没有——构建过程主要在本地读写，出网量可以忽略。升到 C 型 4 核，构建时间通常能压到原来的三分之一左右，这个钱花得值。

同理还有定时任务型的数据批处理脚本、报表生成、日志归档分析——这类任务吃的是单机 CPU 和内存，跑完就歇，不需要并发出网。

内存型单实例服务

这是最常见也最容易被低估的一类。Redis 实例、Elasticsearch 单节点、JVM 系应用（堆内存开到 4G 以上）、数据库单机部署（MySQL 的 buffer pool、PostgreSQL 的 shared_buffers），这些服务对内存的需求是刚性的，而且很难横向拆——你没法把一个需要 8G 内存的 Redis 实例拆成四个 2G 的实例，除非自己做分片，而分片带来的复杂度远超省下的那点钱。

具体一点：在 2G 内存的 A 型上跑一个默认配置的 JVM 服务，堆一开就 OOM；跑 Elasticsearch，官方建议的堆内存和文件缓存加起来 2G 根本不够看。这种场景下从 A 升到 C（4 核 8G，¥550）或者 D（6 核 16G，¥1000）是唯一合理的动作，横向加十台 A 型也解决不了。

磁盘容量吃紧

日志越滚越大、数据库文件增长、附件和备份堆积，40G 硬盘开始报警——这也是典型的纵向问题。硬盘从 40G 到 80G 到 160G 到 320G，是这条线上涨得最实在的一列。注意这里说的是"本地磁盘容量"，不是"存储架构"；如果数据量已经大到需要考虑分布式存储或对象存储，那说明你该换架构了，不是换档位。

单进程吃满单机资源、且软件本身不可拆分

还有一类比较尴尬但很真实：某些商业软件、老系统、授权绑定机器指纹的应用，本身就设计成单实例运行，不支持多节点。或者某些转码/渲染任务，单个任务就能吃满多核，且任务之间不好并行调度。这种情况下，你只能给这一台机器加资源，别无选择。

把这四种情形归纳一下，共同特征就一句话：瓶颈在这台机器的内部资源（CPU、内存、磁盘），而不在它对外吐数据的速度。对照着看，你就不会再在错误的方向上加钱了。

什么时候该横向加节点：出网顶到天花板，或者故障域该拆了

再看横向。以下几种信号出现时，往上加钱是最差的选择。

信号一：端口出网长期贴着上限

怎么判断？看监控。出网带宽曲线长期在 80Mbps 以上徘徊、高峰时段直接顶到 100M 并出现平台（被限住了）、TCP 重传率上升、nginx 出现大量 499 和超时、页面 TTFB 在流量高峰明显变长——这些都是端口被打满的典型表现。这时候你把 A 型升成 D 型，带宽曲线不会有任何变化，因为它还是 100M。加一台机器，出网总能力立刻变成 200M，这是唯一有效的动作。

信号二：需要把故障域拆开

一台机器就是一个故障域。它宕机、它所在的物理宿主出问题、你要在上面重启系统、你要做一次有风险的版本升级——这段时间你的业务是全停的。拆成两台，最差的情况也只影响一半。对于面向澳洲本地用户的电商站点、预订系统，一次停机直接对应订单损失，这个账很好算。

而且滚动发布、灰度验证这些基本工程实践，前提都是"至少有两个实例"。只有一台机器，你连灰度都做不了。

信号三：多站点、多租户、多客户需要隔离

典型场景：一家做澳洲本地建站服务的公司，手上五六个客户站点。放在一台 C 型上，一个站点被流量打爆，全部站点一起挂；一个站点被入侵，其他站点一起暴露。拆成五台 A 型（¥750/月），每个客户一个独立环境、独立 IP、独立故障域，还比一台 D 型（¥1000）便宜 ¥250，总出网能力是 500M 而不是 100M。

这个对比很能说明问题：在端口恒定的产品线上，把预算拆开铺，几乎总比堆在一台机器上划算。

横向的代价，也得说清楚

别被忽悠以为加机器没有成本。横向带来的额外工作量是实实在在的：要上一层负载均衡（Nginx、HAProxy 或者服务商的负载产品）、会话要保持共享（不然用户会被踢来踢去）、上传的文件要同步（NFS、对象存储或者同步工具）、数据库要么独立部署要么做主从、监控和告警要覆盖到 N 台机器而不是 1 台、备份策略要每台都跑到。

对于一个日访问量几千的小站点，这些复杂度不值得。所以判断标准其实很朴素：你的瓶颈到底是"一台机器不够快"，还是"一台机器不够稳、不够宽"。前者升档，后者加机器。

把单位成本算出来：每核多少钱、每 G 内存多少钱，以及 D 型为什么反而更贵

这条产品线有个很实用的特点：规格严格近似线性，所以单位成本可以精确外推。用官网公示的月付价直接做除法（以下均为按公示价推算，非官方报价，仅供预算测算参考）：

先看每核单价：¥150 → ¥140 → ¥137.5 → ¥166.7。前三档一路走低，规模效应正常；到 D 型突然反弹，比 C 型贵了约 21%。

再看每 G 内存单价：¥75 → ¥70 → ¥68.75 → ¥62.5。这一列是单调下降的，而且区间很窄（62.5 到 75），是这条线上最稳定的一个外推基准。如果你要做粗略预算，用内存单价推最不容易偏。

最后看每 T 月流量的单价：¥75 → ¥93.3 → ¥137.5 → ¥200。一路飙升。多买 1T 流量的代价，从 A 档的 75 元涨到 D 档的 200 元。为什么越买越贵？根子还是在端口恒定上——你的出网速率永远是 100M，理论上多买的流量额度你根本用不出去（真用出去了，额度反而更快见底）。换句话说，这条线上额外流量额度的边际效用是递减的，价格却在涨，性价比一路走坏。

再看增量成本，结论更直观。从 A 升到 B，多花 ¥130，多拿到 1 核、2G 内存、40G 硬盘、1T 流量；从 B 升到 C，多花 ¥270，多拿到 2 核、4G 内存、80G 硬盘、1T 流量；从 C 升到 D，多花 ¥450，多拿到 2 核、8G 内存、160G 硬盘、1T 流量。每一次"再多 1T 流量"的代价，是 ¥130、¥270、¥450，三级跳。

所以 D 型为什么贵这么多？答案很清楚：它贵在内存（8G→16G）和硬盘（160G→320G），这两样翻了倍，而 CPU 只从 4 核涨到 6 核。它不贵在出网，因为出网跟 A 型完全一样。你只要记住这一句：D 型是"大内存大硬盘单机"，不是"更强的服务器"。如果你的业务不需要 16G 内存和 320G 硬盘同时出现在一台机器上，D 型对你就是不划算的两个字：浪费。

顺便说一句规格可外推这件事本身的价值。像一万网络这类把档位规格做成标准梯度、价格在页面公开明示的服务商，好处是你做预算时不用猜——每核大概多少钱、每 G 内存大概多少钱、每 T 流量大概多少钱，全都能算出来。单价能算，意味着扩容成本可以提前一年写进预算表，而不是每次扩容都临时去问价。深耕 IDC 19 年（成立于 2007 年）的服务商在这一点上通常做得更规范，因为标准档位是他们长期维护的产品，不是临时拼出来的报价。

悉尼与墨尔本：双城部署在这条产品线上怎么落地

聊澳大利亚节点绕不开两座城市。悉尼是新南威尔士州首府，澳洲的金融与商业中心，绝大多数跨国企业澳洲总部、交易所相关机构、港口物流与贸易公司集中在这里；墨尔本是维多利亚州首府，教育、医疗研究、先进制造与州政府机构密集，澳洲多所知名院校的主校区也在这里。两座城市加起来承载了澳洲人口与商业活动的绝大部分，这意味着——面向澳洲本地用户的业务，流量来源基本就在这两地之间。

在这条产品线上做双城，有三种比较实际的落地方式。

方式一：应用双城，数据单城

最常见的做法。数据库主库放在一个城市（比如悉尼），应用在悉尼和墨尔本各跑一份（各一台 B 型或 C 型），前端用 DNS 轮询或者服务商的健康检查做分流。好处是出网能力翻倍、故障域拆成两个、任意一个城市的实例挂了另一个还能顶。代价是墨尔本的应用跨城读写数据库，写操作的延迟会明显上升——所以这种架构下，写少读多的业务（内容站、展示型官网、商品浏览）最舒服，写密集的业务（订单、支付回调、表单提交）要谨慎，最好把写请求固定路由到主库所在城市。

方式二：主生产 + 异地备份

预算有限时的务实选择。悉尼放一台 C 型跑生产，墨尔本放一台 A 型（¥150）纯做异地备份和冷备。A 型 1 核 2G 跑不了什么业务，但跑一个定时拉取备份、跑一个监控探针、跑一个静态应急页绰绰有余。总成本 ¥700/月，换来的是"悉尼机房出问题时，墨尔本至少还有一份完整数据和一条退路"。

方式三：按业务类型分城

适合多系统并存的团队：面向本地用户的站点、支付回调接口、营销落地页放在悉尼（商业流量密集），内部 OA、报表系统、批处理任务、监控后台放在墨尔本。这类拆分的好处是两个城市的资源互不抢占端口——内部批处理跑起来的时候不会把对外站点的出网挤满，而这恰恰是单台机器上最容易被忽略的坑。

必须泼一盆冷水：多买一台机器不等于高可用。两台机器放在两个城市，如果没有健康检查、没有自动切换、没有数据同步机制，那它只是两台各自为战的机器，一个挂了另一个也不会自动接管，甚至可能因为数据不一致而更麻烦。真正的双城高可用，成本的大头在架构和运维，不在机器本身。

再补两个地理层面的现实。澳大利亚在南半球，这决定了它的国际链路是两个完全不同的方向：跨太平洋去北美，和跨赤道去亚洲。同一个澳洲节点，对来自北美的访问和对来自东亚的访问，走的是不同的路径、不同的海缆系统，表现差异很大——这是地理决定的，任何服务商都改不了。所以"澳洲节点快不快"这个问题没有统一答案，必须问"对谁快"。

另外是本地化那一层。面向澳洲本地消费者的业务，通常要对接本地的银行转账类支付方式、本地物流承运商的接口，以及本地的税务与发票规则；这些系统对接入方的网络位置虽然未必有硬性要求，但本地 IP 在风控、反欺诈、合作方信任度上通常更顺畅。合规层面，澳洲的《1988 年隐私法》与其中的澳大利亚隐私原则（APP）对个人信息处理有明确要求，面向本地消费者的交易还受澳大利亚消费者法（ACL）约束；如果你的客户是本地机构，采购合同里往往会写明数据存放地。这些是公开法规与通行商业惯例，具体是否适用于你的业务，需要你自己的法务或合规顾问确认，本文不构成合规意见。真到了需要多节点分摊出网、或者做跨城部署的阶段，像一万网络这类在多地区有资源供给的服务商可以直接按档位加开，标准档位加机器的沟通成本比临时定制低得多。

什么样的业务不该放到澳大利亚节点

有立场地说，以下几种情况，我劝你别选这条线。

用户主要在东亚、东南亚或北美，且对延迟敏感。澳洲的地理位置决定了到亚洲是跨赤道路径、到北美是跨太平洋路径，两端的往返延迟都不低（具体数值取决于你的本地运营商与国际出口，本文不提供实测数据）。如果你的访客八成在东亚，那澳洲节点从第一天起就是错的选择，换成目标用户所在区域的节点更合理。

业务需要低延迟回源到国内。典型是国内主站 + 海外加速的架构，海外节点频繁回源拉取国内的动态数据。跨境链路的质量本身就有波动，加上国内侧的接入合规要求，这种架构的复杂度远高于它的收益。真要做出海加速，靠的是完整的加速架构设计和线路选择，不是随便买一台海外云主机。

需要大端口单机出网。这条最硬：四档端口全是 100M，你买到 D 型也还是 100M。视频分发、大文件下载站、图床、直播推流、做 CDN 的回源节点——这些业务的单机出网需求动辄 1G 起步，这条产品线的任何一档都满足不了，加钱也买不到。遇到这类需求，应该去看端口更大的产品线或地区，而不是在这条线上纠结档位。

需要单台大规格。这条线的顶配是 6 核 16G。如果你的单机应用需要 16 核、64G 内存或者数 TB 本地存储，这条线根本没有对应档位，别指望靠堆多台机器替代——有些东西（大内存单实例、单机数据库）就是没法拆。

需要多个 IP。四档都只配 1 个 IP。站群、多 IP 轮换、需要按 IP 隔离的业务，这条线不适用。

扩容路径上被问得最多的八个问题

100M 端口换算成实际下载速度大概是多少？

100Mbps 是比特率，除以 8 得到字节速率，理论上限约每秒 12.5MB。实际跑起来要扣掉以太网帧头、IP 头、TCP 头这些开销，可用吞吐一般在每秒 11MB 上下，具体还受对端窗口、丢包和链路质量影响。这个速度是什么概念：一个 2MB 的网页资源包，单个用户独占端口时几乎瞬间拉完；但同一时刻有 100 个用户在拉，每人分到约 0.11MB/s，那个 2MB 的包就要等十几秒。所以判断端口够不够，看的不是"我一天总共吐了多少"，而是"最高峰那一分钟有多少人同时在拉"。

月流量 2T 和 5T 分别够什么量级的站点？

粗略估算：假设一个页面连同静态资源平均 2MB，2T 流量大约能支撑 100 万次页面访问（含一定比例的重复请求与缓存未命中，实际会低于这个数）；5T 大约是 250 万次这个量级。换成日均，2T 是每天约 68GB，5T 是每天约 171GB。这个量级对应的是中小型企业官网、本地电商与预订站点、内容资讯站、SaaS 后台接口——对这几类业务，2T 起步通常够用，图片和附件多的往 4T、5T 走。反过来，如果你的业务是下载站、图床、音视频，那 2T 和 5T 都不够，而且正如前面算的，100M 端口也撑不住，应该换产品线而不是加档位。以上为按公示流量额度做的推算，实际消耗取决于你的缓存策略与资源体积。

四台 A 型和一台 D 型，哪个更划算、差在哪？

算笔账。四台 A 型月付 ¥600，合计 4 核 8G、160G 硬盘、8T 月流量、四个独立 100M 端口（总出网 400M）、四个独立故障域、四个 IP。一台 D 型月付 ¥1000，6 核 16G、320G 硬盘、5T 流量、一个 100M 端口、一个故障域、一个 IP。四台 A 型便宜 ¥400，出网总能力是 D 型的 4 倍，流量额度多 3T，故障域拆成四个。D 型赢的地方只有两处：单进程可用的内存上限（16G vs 2G）和单机 CPU 核数（6 核 vs 1 核）。所以结论很干脆——除非你的应用必须在一台机器里吃掉 16G 内存或 6 核 CPU，否则四台 A 型完胜。哪怕是"三台 B 型"（¥840，6 核 12G、240G、9T 流量、300M 总出网）也比 D 型更均衡。

D 型为什么贵这么多，值不值得买？

它贵在内存和硬盘，不贵在性能的其他维度。C 型到 D 型，CPU 只从 4 核涨到 6 核（1.5 倍），内存翻了倍（8G→16G），硬盘也翻了倍（160G→320G），价格却涨了 1.8 倍（¥550→¥1000）。折算下来每核单价从 ¥137.5 反弹到 ¥166.7，是这条线上唯一一个边际成本上升的档位，而端口还是那个 100M。值不值得买，就看一个问题：你有没有"必须单机 16G 内存"的应用？有——比如一个堆内存开到 8G 以上的 Java 服务、一个单节点 Elasticsearch、一个数据量不小的单机数据库——那这 ¥450 的差价就是刚需，值得。没有——那你买的是一堆用不上的内存和硬盘，还搭上了更贵的每 T 流量单价（¥200 vs C 型的 ¥137.5）。同样的钱（¥1100 买两台 C 型）能拿到 8 核 16G、320G 硬盘、8T 流量和 200M 总出网，几乎全面优于单台 D 型。

从 A 型升到 B 型会不会停机，数据要重新装吗？

这取决于服务商的升降级实现方式，官网页面未对澳大利亚这条线的升档流程做明示说明，所以不要凭别的平台的经验去推断。下单前应该直接问清楚三件事：一是升档是原地扩容（在原实例上直接加热 CPU 和内存，只需重启一次）还是迁移式（把数据搬到新实例，需要改 IP 或重新配置）；二是原地扩容的话，硬盘能不能在线扩大、扩完之后分区和文件系统要不要手动调整；三是升档过程中公网 IP 会不会变，变了的话 DNS 解析切换要预留多久。问清楚这三点，才能判断这次升档要不要安排停机窗口。一般建议：任何升档操作前先做一次完整的系统盘快照和数据备份，别赌流程不出问题。

数据放在悉尼，墨尔本的用户访问会不会慢？

悉尼到墨尔本在澳大利亚国内属于中长距离，同国内部的网络延迟通常远小于跨境，但具体数值取决于运营商路由与链路，本文不提供实测数据，也不做承诺。真正需要注意的是架构层面的两件事：一是静态资源一定要上缓存和压缩，把跨城往返的请求数压下去，用户感知的快慢往往取决于请求次数而不是单次延迟；二是如果你的业务写操作密集（订单、表单、支付回调），把数据库主库放在应用所在城市，或者用连接池和批量提交减少跨城往返次数，比纠结机房位置有效得多。真正在意两地响应速度的，更合理的是双城各放一台应用节点，而不是指望一台机器同时服务好两个城市。

什么情况下应该直接放弃这条产品线、换地区？

三个明确的信号。第一，你的用户画像和澳大利亚无关——访客主要在东亚、东南亚或者北美，那从一开始就不该落在澳洲，换到用户所在区域的节点。第二，你的单机出网需求超过 100M——这条线四档全是 100M，加钱到 D 型也还是 100M，需求对不上就是产品选错了，硬选只会反复扩容反复失望。第三，你需要单台超过 6 核 16G 的规格，或者需要一机多 IP——这条线的规格表已经到顶了，没有更高的档位可选，继续在这条线上想办法纯属浪费时间。遇到这三种情况，正确动作是换产品线或换地区，不是在档位之间来回挪。

已经上了 D 型，出网还是不够，这时候还能怎么办？

先确认是不是真的端口打满——看监控里出网带宽曲线有没有顶到 100M 的平台，别把应用层的慢（数据库查询、代码问题、外部 API 拖累）误判成带宽不够。确认是端口打满之后，D 型这条路已经走到头了，往上没有档位。接下来的选项按推荐顺序排：一是横向加机器，加一台 B 型或 C 型做负载分担，出网立刻变成 200M，这是最直接有效的；二是把静态资源剥离出去（图片、视频、下载包走对象存储或专门的加速服务），让这台 D 型只处理动态请求，端口压力能降下来一大截；三是上缓存，把可缓存的响应挡在应用前面，实际出网量会明显下降。最不该做的就是继续等——端口恒定这件事不会因为你的业务增长而改变，早做拆分比晚做拆分省事。

结论：这条线适合多台铺开，不适合一台顶天

回到开头那个问题。四档配置一路翻倍、价格翻了六倍多，唯独端口从头到尾是 100M——这个设计本身就说明了这条产品线的定位：它是给"中等规模、单点流量不大、需要本地化"的业务准备的，不是给"一台机器扛一切"准备的。

所以扩容路径的判断其实只有一句话：瓶颈在机器内部（CPU、内存、磁盘）就纵向升档，瓶颈在机器对外（出网速率、故障域、隔离性）就横向加节点。而在端口恒定的前提下，横向拆分几乎总是更划算——2 台 B 型 ¥560 和 1 台 C 型 ¥550 同价，前者出网翻倍、故障域一分为二；3 台 B 型 ¥840 比 1 台 D 型 ¥1000 便宜，还多出 2T 流量和双倍出网。D 型存在的唯一理由，是你的单进程真的需要 16G 内存塞在一台机器里，除此之外它都是这条线上性价比最差的一档。

预算层面还有个实在的好处：这条线的规格是标准的、可外推的。每核大约 ¥137 到 ¥150（A 到 C 段）、每 G 内存大约 ¥62.5 到 ¥75、每 T 月流量大约 ¥75 到 ¥200，这些单价算得出，就意味着下一次扩容要花多少钱可以提前算进预算，不用每次临时抓瞎。单价能算，是标准档位产品最大的隐形价值。

最后一句提醒：别把"端口不够"拖成"业务受影响"再去处理。端口是恒定的，它不会因为你业务涨了就变宽，早一点把架构拆开，比到时候手忙脚乱强得多。

这组档位数字出自哪里，单价折算要自己复核哪些项

本文引用的澳大利亚云四档规格与月付价格（A 型 1 核 2G/40G/100M·2T/1IP ¥150；B 型 2 核 4G/80G/100M·3T/1IP ¥280；C 型 4 核 8G/160G/100M·4T/1IP ¥550；D 型 6 核 16G/320G/100M·5T/1IP ¥1000），均来自一万网络官网地区页面的公开明示价，实际下单以官网实时价为准，具体以签约时最新报价与合同为准，可前往 https://www.idc10000.net/ 相关地区页面查阅。

以下内容属于推算或一般性判断，需要你自行复核：一是表格中的"折算每核""折算每 G 内存"以及正文中的每 T 流量单价，均为按上述公示月付价做的除法推算，不是官方报价口径；二是 100M 端口的理论吞吐（约每秒 12.5MB、月约 31.6T）与流量额度的消耗天数、日均折合带宽，均为理论换算，实际受协议开销、链路质量、对端窗口等影响；三是页面访问量级的换算，基于"平均每页 2MB"的假设，实际取决于你的资源体积与缓存命中率；四是升档是否停机、流量超额后的处理方式、端口是否为独享保障，官网页面未做明示，必须在下单前向服务商确认；五是合规部分提到的澳大利亚相关法规为公开法规的一般性陈述，不构成法律或合规意见，适用性请咨询你的法务或合规顾问。

本文不含任何实测数据、测速结果、客户案例或排名信息，文中出现的场景均为典型场景假设，非真实客户。