国内城市页为什么四档带宽都是 1M：苏州这类页面升档买到的到底是什么

苏州云服务器页面上摆着四档配置，价格从 ￥73 元/月一路到 ￥648 元/月，最贵那档是最便宜那档的八点几倍，接近九倍。按一般人的直觉，价钱涨了这么多，配置总该全面涨一轮才对。可你把字段一行行读下来会发现一个很别扭的地方：CPU 从 1 核涨到 8 核，内存从 1G 涨到 16G，硬盘四档全是 40G，一个 G 都没动；带宽四档全是 1M，一个 M 都没动。硬盘不动还算能理解，很多业务本来就吃不了多少磁盘。带宽也不动，这就不是"理解一下"能过去的事了——因为绝大多数人买云服务器，心里默认的"快"就是带宽带来的，而这一格恰恰是四档里唯一从头到尾没变过的。

这篇就把这件事掰开讲清楚：在国内城市页这种字段体系里，升档到底买到了什么，没买到什么，以及带宽这笔账为什么必须单独算。结论先放在这儿——四档之间涨的价钱全部落在 CPU 与内存上，出口带宽是独立于档位的硬约束，靠升档买不到带宽；带宽敏感的业务得先把出口这笔账单独算清，或者把流量分出去，只在这个维度上加钱是白花。

苏州页四档字段摆在一起看，涨价涨在哪一格

先把四档原始字段完整抄出来，不做任何加工，这样反差才看得清楚。

这张表最该看的是最后一列——四档解决的都是 CPU 与内存层面的瓶颈，没有一档碰出口。也就是说，从 A 型升到 D 型，多花的那 575 元/月，买到的是 7 核 CPU 和 15G 内存，带宽一分没多。这不是页面漏标，也不是配置写错了，而是国内节点页面上带宽本来就不跟着档位走。

顺带再说一个字段细节，很多人一眼扫过去不会注意：内存这边，A 型的核数与内存是 1:1（1 核对 1G），B、C、D 三档的内存都是核数的 2 倍（2 核 4G、4 核 8G、8 核 16G）。这个比例关系说明档位设计本身就是围绕"算力配比"这条线拉的，硬盘和带宽压根不在这条线上。硬盘四档完全相同、都是 40G，带宽四档完全相同、都是 1M，这两个字段是独立于档位体系的常量。

国内页和海外页的字段写法，根本不是一回事

要理解为什么带宽是常量，得先看国内页和海外页在字段体系上的差别。同一家服务商的海外节点页面，带宽那一栏通常写成"端口/流量"两个字段，比如端口多少、每月流量多少，两个数字分开标，读者一眼就知道这是两条独立的约束：端口决定瞬时能跑多快，流量决定一个月总共能跑多少。

国内城市页不是这个写法。苏州页的带宽写作单值——1M，就一个数字，没有跟着档位变，也没有第二个配套字段。单值写法背后的含义是：这个数字是这一档机器在出口上的给定值，它不参与档位爬升。你买 A 型是 1M，买 D 型还是 1M。

这个差别非常关键，因为它决定了你在国内城市页上读配置时的思维方式要换一套。看海外页，你习惯的是"档位越高，各项都往上走"，配置表和价格是同向的。看国内页，你得把带宽这一格单独抽出来读：它是这个页面里的一个独立变量，跟左边那列价格没有任何联动关系。说白了，国内城市页的价格梯度描述的是"这台机器有多能算"，不是"这台机器出口有多宽"。

中国香港节点一类的海外页面之所以常用端口与流量双字段，是因为那边的使用场景里，跨境访问、内容分发、大流量下载占比高，流量账必须单独拎出来说。国内节点这边，业务主体通常是备案站点、政务与企业内网系统、小程序和 APP 后端、数据留在本地的轻量业务，这些场景的共同点是计算与存储在本地完成，出口上真正往外吐的数据量相对可控，所以带宽被做成了统一的给定值，而不是档位附属品。

这里有个阅读习惯上的坑值得单说。很多人是从海外页切到国内页来看配置的，脑子里还留着"端口随档位涨"的印象，于是看到国内页的 1M 会下意识以为这只是最低档的起点值，往上买自然会更宽。这个推测在本页上是不成立的——四档白纸黑字写的都是 1M，不存在"往上就更宽"这回事。字段体系换了，读法就得跟着换，拿上一套经验套这一套，是最容易出错的地方。

反过来说也一样。习惯了国内页这套单值写法的人去看海外页，容易只盯着一个数字看，忘了那边还有流量这个第二约束，结果月底发现流量跑超了。两套体系没有优劣之分，只是把约束写在了不同的位置。下单之前，先分清你正在看的是哪一种页面，这一步省不得。

苏州这类国内城市页，通常承载的是哪几类业务

要判断 1M 够不够，还得先看这类页面一般被用来干什么。国内城市页的机器，主流用途集中在四类，它们的共同点是"计算和数据在本地、对外出字节量有限"，这也解释了为什么带宽会被设成统一常量。

第一类是需要备案的国内站点。企业官网、品牌展示站、行业门户这一类，主体在国内、域名要备案、内容要合规，业务上要求机器落在境内。这类站点的页面通常是图文混排，首屏体积做得好的话并不大，日常访问的峰值也相对平缓和固定，出口压力主要来自图片有没有外置，而不是机器本身。

第二类是政务与企业内网系统。审批流、OA、内部报表、档案查询、生产管理系统，使用人群是固定的一批人，访问范围相对封闭，页面交互频繁但单次传输的字节数不大。这类系统真正吃紧的是内存和数据库性能——几十个人同时查一张大表，卡的是内存和 CPU，不是出口。

第三类是小程序和 APP 后端。这一类的分化最明显：如果后端只做接口转发、返回结构化数据、页面资源都已经放在内容分发网络上，那 1M 完全够用，瓶颈会在 CPU 和内存上；如果后端直接承担图片上传下载、返回未分页的大列表、或者把整包资源堆在源站上，那出口很快就会成为瓶颈，而升档对此毫无帮助。同样是小程序后端，两种做法的结局完全不同。

第四类是数据留在本地的轻量业务。出于数据归属、合规审计或内部管理的要求，业务数据必须放在境内机器上，不往公有对象存储里放。这类业务的特点是磁盘和内存需求明确，算力需求稳定，出口需求很小——因为数据本身不往外走。对于这一类，四档配置里最该关注的是内存和那块 40G 的硬盘能装多久，出口反而不是重点。

把这四类摆在一起看就明白了：国内城市页服务的这些场景，绝大多数卡点落在算力和内存上，出口不是主要矛盾。所以页面把带宽设成统一值，是对这类业务形态的一个顺应，而不是偷工减料。真正的风险在于，如果你的业务不属于这四类——你要做下载站、要做视频、要做图床——那你其实是在用一个为轻出口场景设计的配置体系，去做一件重出口的事。这时候最该做的不是升档，是重新审视架构。

带宽恒定意味着什么：升档买不到出口

把上面两层事实叠在一起，结论就很硬了：在国内节点上，出口带宽是独立于档位的硬约束，靠升档买不到带宽。

这句话要拆成两半来理解。前半句是"算力可以靠加钱买"——你的业务卡在 CPU 上（接口计算慢、报表跑不出来、编译耗时长），或者卡在内存上（服务频繁被 OOM 杀掉、数据库缓冲区太小、多个 Java 进程挤在一起），那么从 A 型升到 B 型、从 C 型升到 D 型，是直接对症的，钱花在刀刃上。113 元的档位差换来 1 核到 2 核、1G 到 4G 这种跨度，对内存吃紧的业务来说是立竿见影的。

后半句是"出口不行"——你的业务卡在带宽上（页面打开慢、图片加载转圈、下载进度条爬、API 大报文返回慢），这时候你从 A 型一路升到 D 型，花了近九倍的钱，出口那一格还是 1M，慢的地方一点没变。这就是典型的加钱加错了维度。钱花了，问题还在，然后你得出一个错误结论："这家机器不行。"其实机器没问题，是你买的维度不对。

说得再直白一点：如果你现在手上是一台 A 型，网站图片一多就卡，你的第一反应如果是"升到 C 型试试"，那这 266 元的差价基本是白花。你换回来的是 3 核 CPU 和 7G 内存，而拖慢你网站的那个东西——出口——一毫米都没变宽。

1M 这个格子，具体卡住的是哪些业务

先说清楚一个口径问题：1M 指的是带宽这一字段的给定值，1 Mbps 换算成字节速率大约是 128 KB/秒，这是带宽单位的标准换算，不是来自任何测试的结果。真实能跑出多少，还要看协议开销、连接数、丢包重传、源站响应时间这些因素，具体能扛多少访问，需按自有业务的页面体积与并发自行核算。我这里不给你一个"能扛多少人"的数字，因为那种数字脱离你的页面体积就是假的——一个 20KB 的首页和一个 2MB 的首页，答案能差两个数量级。

但不给具体数字，不代表分不清哪些业务会被卡住。下面这几类，基本上一眼就能判定它们会撞在 1M 这一格上：

图片为主的站点。产品图、案例图、Banner 没做压缩也没走分发，一张几百 KB，一个页面十几张图，首页加载就奔着几 MB 去了。这类站点的瓶颈在第一屏的字节数，不在 CPU。你给它 8 核 16G，它照样转圈。

文件下载与附件分发。安装包、PDF、素材包、客户端升级包，这类业务的全部负载就是往外出字节。哪怕你一天只有几十次下载，只要单个文件上了几十 MB，用户那头的体验就是"下不动"。这类业务在国内页的这套档位里怎么升都解决不了。

视频与音频点播。码率乘以时长就是字节数，视频天生是出口杀手。把视频源放在这台机器上直接对外播，是最典型的"拿算力当带宽用"的错误。

大量对外请求的后端。这一种是容易被忽略的。你的业务本身页面很小，但后端要频繁调用第三方接口、抓取外部数据、往对象存储上传、做跨机房同步，出方向的字节量一样会顶到出口。很多人只看"我页面小"，忘了后台任务也在抢同一条出口。

移动端接口返回大报文。小程序和 APP 后端常见的坑：接口一次拉全量列表、不做分页、不做字段裁剪，一个响应几百 KB。数据量越攒越大，出口就越来越挤。

还有一种混合情况最考验判断力：业务本身出口不大，但偶尔有突发。比如电商站点平时很轻，一到活动推送就是几倍的访问涌入；比如企业系统月底集中出报表，短时间内大量下载。这类业务的麻烦在于，平均值告诉你够用，峰值告诉你不够。解决办法也不是升档——峰值时段卡住的是出口，不是算力。正确做法是把突发的大体积内容提前推到分发网络上，让峰值那几分钟的字节不从源站走。

反过来，下面这些业务对带宽不敏感，升档是对症的：数据库服务（吃内存和磁盘 IO）、内部管理系统（并发人数有限，页面轻）、定时任务与数据处理（吃 CPU）、中间件与消息队列（吃内存）、代码编译与构建（吃 CPU 和多核）、需要数据留在本地的政企内网系统（访问范围固定，出口压力可控）。

判断方法其实就一句话：把你的业务按"往外吐多少字节"和"在本地算多久"分成两笔账，哪笔大就先解决哪笔。四档配置只管后一笔。

带宽这笔账怎么单独算，别混在档位里

既然带宽不跟着档位走，那它就得单独成账。算这笔账不需要复杂工具，三个数就能估个大概。

第一个数是单页体积。打开浏览器开发者工具看一次无缓存加载，把 HTML、CSS、JS、图片、字体全算上，记下总字节数。注意看的是压缩后的传输体积，不是磁盘上文件的原始大小。很多站点自以为页面只有几百 KB，一测发现首屏就两 MB 多，问题基本就在这。

第二个数是访问分布。不是看一天总共多少 PV，而是看峰值时段里每秒有多少次请求。一天一万 PV 平摊到二十四小时毫无压力，全挤在早上十分钟里就是另一回事。峰值并发才是决定出口够不够的那个数。

第三个数是单用户能接受的最长等待。这是个产品决策，不是技术参数。首屏三秒内出得来，和首屏八秒也无所谓，对应的出口需求完全不同。

三个数凑齐，单页体积乘以峰值每秒请求数，再和你手上带宽能提供的字节速率比一下，够不够就清楚了。这里我不替任何人算结果，因为这三个数每个人的业务都不一样，套别人的模板只会得出错误结论。具体能扛住多少，需按自有业务的页面体积与并发自行核算。

补两个容易被漏掉的变量。一个是重复访问的比例。如果你的用户每天来好几次，浏览器缓存和协商缓存会砍掉绝大部分重复传输，实际出口压力远小于"PV 乘以页面体积"这个粗算结果。反过来，如果每次访问都是新用户、都是全新资源，缓存帮不上忙，粗算结果就接近真实值。同样是日活一万，这两种情况的出口需求差得很远。

另一个是出方向之外的路径。很多站点以为所有字节都要从这台机器出去，其实表单提交、接口调用这类上行数据量很小，真正的大头永远是下行。做估算的时候只要盯住下行就行，把上行单独算进去反而会把数字搞乱。但有一种例外：后台任务会往外推数据，比如定时向第三方同步、备份上传、日志外发，这些属于出方向，而且和前端访问抢同一条出口，规划时不能漏。

还有一点要提醒：估算出来的数字是用来判断"量级"的，不是用来做精确承诺的。你算出峰值需要大约每秒几百 KB 的出口，和手上的供给一比，如果差了一个数量级，那就别犹豫，肯定不够；如果只差一点点，那就靠压缩和缓存去抹平，没必要大动干戈。这种量级判断比精确到小数点的计算有用得多。

算出来不够怎么办，路子有三条，都是把流量从这台机器上挪走，而不是把这台机器升上去：

第一条，把静态资源分出去。图片、视频、安装包这类大体积内容放到对象存储上，通过内容分发网络就近命中，源站只处理动态请求。这一条解决了绝大多数图片站的困境，而且和你在哪一档毫无关系——你在 A 型上做和你在 D 型上做，效果一样。

第二条，把页面本身做瘦。图片压缩与新一代格式、按需加载、接口分页与字段裁剪、开启压缩传输、合理设置缓存头。这些是零成本或低成本的，但能直接砍掉出口压力的大头。很多站点做完这一轮，会发现 1M 够用了。

第三条，把出口需求单独提。带宽既然是独立字段，那就单独跟服务商确认能不能在这个字段上调整、怎么计费、调整后的价格是多少。这是唯一一条真正"加宽出口"的路，但它走的是带宽这个通道，不是档位这个通道。价格官网页面上没有直接列出，需实时询价、以官网实时价为准。

这三条的共同点是：它们都不需要你先花 575 元把档位从 A 升到 D。如果你眼下的问题是出口，先做这三条，再去想算力够不够。顺序反了就是白花钱。

下单前，把这几个问题问清楚

下面是国内节点上被问得最多的七个问题，回答都围绕字段口径，不绕弯。

1M 到底能扛多少访问？没有脱离页面体积的统一答案。1 Mbps 换算成字节速率约 128 KB/秒（纯单位换算，不涉及任何测试），用你的单页体积去除它，得到的是理想状态下每秒能出多少个首屏，再拿这个数和你的峰值每秒请求数比。真实的并发承受能力还要扣掉协议开销和连接损耗，需按自有业务的页面体积与并发自行核算。

带宽能不能单独加？从苏州页的字段体系看，带宽是独立于四档的字段，四档都是 1M，页面本身没有给出随档位变化的带宽梯度。能不能在这个字段上单独调整、如何计费、价格多少，需要下单前直接向服务商确认，以官网实时报价与合同为准。不要默认"升档就会变宽"，页面写得很清楚，不变。

图片、视频该不该走内容分发？该。这类业务的负载本质就是出字节，放在带宽恒定的机器上是最不划算的做法。静态资源外置之后，源站承担的只剩动态请求，出口压力会降一个量级。这一条和档位无关，A 型做和 D 型做收益相同。

备案期间能不能先上小档？可以这么规划，但要想清楚两件事。一是备案期间站点通常还在调试阶段，访问量小，A 型的算力够用，没必要提前为大并发买单。二是档位之间的算力跨度是明确的（1 核 1G 到 2 核 4G 到 4 核 8G 到 8 核 16G），前期按实际负载选，后期确实卡在 CPU 或内存上再往上升，路径是清晰的。备案相关，官网提供的是备案协助，具体办理节奏和结果以主管部门审核为准，任何"包过""百分百通过""保证多久下证"的说法都不成立，听到就当没听见。

硬盘四档都是 40G，数据多了怎么办？40G 是这四档共同的硬盘字段，升档不会带来任何额外磁盘空间。这意味着如果你升档是因为"空间不够"，那升错了——空间问题要单独解决。系统盘之外挂数据盘、把冷数据挪到对象存储、做定期归档清理，这三条才是正解。选型时把 40G 当成常量看待，别指望 D 型会送你更大的盘。

国内节点和海外节点能不能混着用？可以，而且很多业务本来就该混着。国内节点承接需要备案的主体业务与本地数据，海外节点（比如中国香港方向）承接不需要落地备案的外部访问与大流量分发。两个方向的字段体系不同，海外页常用端口与流量双字段，规划时别拿一套思路套两边。

升档时原来的机器怎么办？算力升档涉及的是 CPU 与内存这两个字段的变化，迁移前要确认的是镜像、数据盘、快照怎么处理，以及升档过程需要多长的窗口。这些属于交付细节，官网页面没有给出统一口径，下单前直接问清楚，写进合同或工单，别靠口头承诺。另外要提醒一句，升档只改变 CPU 与内存，硬盘停留在这四档共同的 40G，带宽停留在 1M，如果你升档的动机里掺杂了"顺便多要点空间或多要点带宽"的期待，那这部分期待是落空的。

国内城市页四档该按哪个字段选（苏州篇）

回到苏州这张页面。四档摆出来，73、186、339、648，单位都是元/月，没有"起"字，梯度是干净的。选的时候，我的建议是按下面这个顺序看字段，而不是按价格从低往高挑。

第一步先判断你卡在哪。看监控：CPU 长期高位就往上看档位，内存频繁告警就往上看档位，磁盘空间告急别往上看档位（四档都是 40G，看了也没用），出口打满也别往上看档位（四档都是 1M，看了同样没用）。后两种情况要在档位之外单独解决。

第二步再看算力配比。A 档是 1 核 1G，核数与内存 1:1；B、C、D 三档的内存都是核数的 2 倍。如果你的业务是内存型的——数据库、缓存、多进程 Java 服务——从 A 往上跨一档，内存的增长幅度比核数大得多，性价比就体现在这里。如果业务是计算型的——批处理、编译、密集运算——那就看核数，8 核 16G 的 D 档是这条线的终点。

第三步把带宽和硬盘从决策里摘出去。它们在这张页面上是常量，不参与四档之间的比较。你需要多少出口、需要多少磁盘，是两笔要和档位并行算的账，不是在四档里挑一个就顺带解决的事。很多人选配置的时候把四个字段混在一块儿权衡，结果就是在算力上过度消费、在出口上毫无准备。

还有一种做法是值得考虑的：如果预算允许，先按算力需求选一档，把出口问题用架构手段解决（静态资源外置、压缩、缓存），跑一段时间看监控，再决定要不要在算力上继续加码。这种"先分账、再决策"的节奏，比一上来就挑最贵那档踏实得多。最贵那档给你的 8 核 16G，如果业务根本用不上，那就是纯粹的多余支出；而它省不掉的那一格 1M，才是你真正要解决的问题。

最后补一句关于 40G 的。四档硬盘完全相同，这个事实的另一层含义是：磁盘规划要按最低预期做，不要指望升档能换来空间。系统、运行环境、日志、业务数据加在一起能不能压进 40G，是选任何一档之前都要先算清楚的账。日志轮转、定期归档、冷数据外迁，这些习惯比多买一档管用。

国内节点这块，一万网络把四档配置直接摆在页面上的做法挺省事——深耕 IDC 19 年（成立于 2007 年），字段自己核一遍心里有数。

最后说句实话：国内城市页这种"档位只管算力、带宽单独成账"的设计，本身不是坑，坑在于很多人带着"贵的就是更快的"这个预设去看配置表。你把字段一行行对完就会发现，这套体系其实比那种什么都跟着档位涨的表格更诚实——它明明白白告诉你，出口这件事得另外谈。

数据来源与口径说明（苏州国内节点篇）

本文所引用的配置与价格数据，均来自一万网络苏州云服务器页面（slug: suzhouy），官网地址为 https://www.idc10000.net/ ，具体条目以该页面上苏州国内节点云服务器的实时展示为准。文中出现的四档字段——A 型 CPU 1 核、内存 1G、硬盘 40G、带宽 1M、￥73 元/月；B 型 CPU 2 核、内存 4G、硬盘 40G、带宽 1M、￥186 元/月；C 型 CPU 4 核、内存 8G、硬盘 40G、带宽 1M、￥339 元/月；D 型 CPU 8 核、内存 16G、硬盘 40G、带宽 1M、￥648 元/月——均系照抄官网字段，未作任何改动、外推或补充。

需要说明的口径有四点。其一，价格单位为"元/月"，页面上不带"起"字，本文沿用同一写法。其二，四档硬盘字段完全相同、都是 40G，四档带宽字段完全相同、都是 1M，本文据此判断这两个字段为独立于档位体系的常量。其三，内存方面，A 档核数与内存为 1:1，B、C、D 三档内存均为核数的 2 倍，此为页面上字段之间的比例关系描述，不代表任何性能承诺。其四，国内页带宽写作单值（1M），与海外页"端口/流量"双字段写法不同，本文据此讨论两套字段体系的阅读差异。

文中未引用任何自行测试得出的数据，也未给出具体的并发数、下载速度与时延数值。涉及带宽能否承载多少访问的地方，一律表述为需按自有业务的页面体积与并发自行核算。文中未引用任何真实客户案例，所举业务场景均为典型部署思路，并非特指某一真实客户。带宽单独调整的方式与价格、备案办理节奏、升档迁移窗口等未在页面上明示的内容，需实时询价或以官方答复为准。

具体以官网实时报价与合同为准。