2026 镇江云服务器最低那档 77 元能跑什么：随机端口和小内存的适用边界

77 元这一档最容易被误读的地方，是它把带宽和硬盘都定死了

77 元这个数字在镇江云的配置表里排在最左边，绝大多数人看到它的本能反应是「4 核 4G 卖 77 元，很便宜」。但把整张配置表横过来读一遍，会读出一个完全相反的结论：镇江云 A 型到 D 型，带宽那一栏从头到尾都写着 30M，数据盘那一栏从头到尾都写着 50G，端口那一栏从头到尾都写着「随机端口」。也就是说，从 77 元一路加到 209 元，多付出去的 132 元，没有换来哪怕 1M 带宽，也没有换来哪怕 1G 硬盘。

换个说法更准确：77 元这一档买的不是「缩水版服务器」，而是一台带宽和硬盘被钉死在 30M / 50G、但 CPU 和内存给得相当慷慨的纯计算节点。这个定位决定了它的价值区间——算力宽松、出口很窄、存储很薄。业务是不是适合这一档，本质上不是看它「够不够用」，而是看你的负载在这三个维度里到底吃哪一个。

先把「便宜」这件事拆成两半看

同等月付区间里，4 核 CPU 配 4G 内存属于偏厚的组合。很多入门级云主机在这个价位只给到 1 核 2G 或 2 核 2G，镇江云 A 型直接把 CPU 拉到 4 核心，这对编译构建、轻量应用容器、内部管理系统的 Java 进程、以及需要多进程并发的任务来说是实打实的收益。真正被压缩的不是算力，而是出口和存储。

于是判断路径就清楚了：如果你的业务是「CPU 忙、网络闲」——比如定时任务、数据清洗、内部接口、CI 构建机、爬虫的下游解析节点、企业内部 OA 与工单系统——那么 30M 和 50G 这两个上限在日常运行里根本碰不到，77 元这一档就是纯粹的性价比。反过来，如果你的业务是「CPU 闲、网络忙」——图片站、素材下载、视频分发、对外 API 大批量返回报文、网盘类应用——那么哪怕你加到 D 型的 209 元，带宽还是 30M，硬盘还是 50G，问题原封不动地留在那里。

这一档真实的能力画像

用一句能直接套用的话概括：镇江云 A 型是一台「 inland 计算容器」，它的强项是并发执行能力和进程调度，弱项是任何需要往外持续吐数据的动作。4G 内存同时是第二个需要盯紧的边界——这不是说 4G 不够跑程序，而是说它对「内存 + 磁盘缓存 + 并发连接数」三者的总和提出了要求。Web 服务每开一个并发连接都要占一部分内存，数据库缓存也要占内存，JVM 堆一旦设大了更是直接吃掉一大块。4G 的可用性，取决于你怎么分配这三块。

四档之间的差价，买的到底是什么

镇江云四个型号摆在一起看，规律极其整齐，整齐到几乎可以用一句话写完：加价只买算力，不买带宽，也不买存储。

逐档拆账：每一笔差价换回了什么

A 型 77 元是 4 核 4G，B 型 121 元是 4 核 8G。两者之间 44 元的差价，买到的是 4G 内存，CPU 核心数一动没动，带宽没动，硬盘没动。这一档差价的意义在于：如果你卡在内存上而不是 CPU 上——比如 Java 应用堆设不上去、数据库连接池开不大、Redis 数据集放不下——那么这 44 元是整张表里性价比最高的一笔支出。

B 型 121 元到 C 型 165 元，又是 44 元，这次买到的是 4 个 CPU 核心（4 核 8G → 8 核 8G）。内存没变。这一档针对的是并发执行线程吃满但内存还有余量的场景：多进程任务队列、并行编译、需要开多个 worker 的后台服务。判断依据很直接——如果监控里 CPU 长期跑在 70% 以上而内存还有富余，升级方向就是 C 型；如果反过来内存吃紧而 CPU 闲着，那应该停在 B 型甚至重新回看 A 型加内存的方案。

C 型 165 元到 D 型 209 元，还是 44 元，买到的是 8G 内存（8 核 8G → 8 核 16G）。到 D 型为止，这条产品线的顶部是 8 核 16G / 30M / 50G / 随机端口。可以看到四档之间的每一次加价都是整齐的 44 元，每一次都只动一个维度，而且交替着来：先加内存，再加核心，再加内存。这种设计其实是在告诉选型的人——先判断你缺的是核数还是内存，再决定往上走几档，别一上来就跳到顶配。

一个反直觉的结论

把四档的价格和规格排成序列，会得出一个很多人没想到的判断：如果你的瓶颈是带宽或硬盘，那么这四档里没有任何一档能救你。77 元解决不了的 30M 出口问题，209 元同样解决不了。遇到这种情况，正确的动作不是往上加档，而是换产品线——换到大带宽方案，或者把存储和分发拆出去，用对象存储 / CDN 承担出网压力，让镇江云这一档专心做计算。这个「加档无效」的判断，正是镇江云选型路上头一道分岔口。

再一道分岔口落在内存上。4G 内存配 4 核 CPU，平均每个核心分到 1G，这在现代应用栈里是偏紧的配比。如果你的技术栈是 Java / .NET 这类带运行时堆的，或者是需要跑 Nginx + PHP-FPM + MySQL + Redis 一整套的组合，4G 会很快见底。镇江云 B 型的 8G 之所以值得单独考虑，就是因为这一步把「每核 1G」变成了「每核 2G」，整机的可用余量立刻不同。

30M 带宽换算成一天能出多少流量

带宽是最容易被拍脑袋估计的一项。这里给一个可以直接套用的口径，先把 30M 从「兆」换算成真实的文件传输速度，再折算成日流量。

理论满速口径

运营商和机房标称的 30M 指的是 30Mbps（兆比特每秒），而操作系统里看到的下载速度单位是 MB/s（兆字节每秒），1 字节等于 8 比特。所以：30Mbps ÷ 8 = 3.75MB/s，这就是 30M 带宽在理想状态下每秒能往外推的数据量，约合每秒 3.75 兆字节。

把这个速度乘上一整天的秒数：3.75MB/s × 86400 秒 = 324000MB。按 1024 进制折算约为 316GB，按 1000 进制折算约为 324GB，粗略记作「一天满打满算约 320GB」。这就是 30M 带宽的日出网理论天花板。

必须强调：320GB 是理论口径，现实中几乎不可能跑到。原因有三条——其一，服务器不可能 24 小时持续满速输出；其二，TCP 握手、丢包重传、TLS 加密开销都会吃掉一部分有效载荷；其三，实际带宽还会受对端网络状况、跨运营商互联质量影响。真实可用量一定低于这个数字。

怎么用它估算自己的业务

把理论值变成可用估算，只需要引入一个「日均占用率」：

日均出网量 ≈ 320GB × 日均占用率

日均占用率取多少，取决于业务的访问曲线。对一个只在上班时间有人访问的内部系统，活跃时间可能只占全天的 25%，且活跃期也不是时刻满速，实际日均占用率往往在 5%–15% 之间，对应日出网量约 16GB–48GB。对一个全天都有请求但流量平稳的小型站点，日均占用率可能落在 10%–25%，对应日出网量约 32GB–80GB。而对一个做文件分发的业务，峰值时段会直接把带宽打满，日均占用率可以冲到 50% 以上，日出网量 160GB 起跳，这时候 30M 就明显是瓶颈了。

还有一个更贴近体感的换算方式：按单次响应体积算并发。假设你的页面平均响应体积是 1.5MB（含 HTML、CSS、JS 和几张压缩过的图），那么 30M 满速下单秒最多服务 3.75 ÷ 1.5 = 2.5 个请求，也就是说单个用户完整加载这样一个页面最快也要 0.4 秒，且这已经是独占全部带宽的理想情况。真实场景里带宽要分给多个访客，10 个人同时加载，每人分到约 0.375MB/s，加载时间就变成 4 秒左右。页面体积越大、并发人数越多，这个数字衰减得越快。

需要留意的另一点是方向。页面上标的「带宽 30M」具体指向出网（上行，服务器往外发）还是入网（下行，服务器往里收），抑或是双向合计 30M，镇江云页面未标注，选型前需向销售确认。对绝大多数「对外提供服务」的业务来说，卡的都是出网方向，这点必须在下单前问清楚。

50G 数据盘够不够：先分清系统盘和数据的比例

镇江云四档统一标注「数据盘 50G」。这里有个很容易踩的认知偏差：很多人默认 50G 是整机全部可用空间，实际上系统盘是否独立、系统盘多大，页面未标注，选型前需向销售确认。这个区分直接决定了 50G 到底够不够。

两种截然不同的容量账

如果系统盘是独立的、不计入这 50G，那么 50G 可以全部划给业务数据，这个容量对中小业务来说相当宽裕。举几个可直接套用的量级：一套带若干插件的 WordPress 站点，含数据库和上传目录通常在 1G–3G；一个百万行级的 MySQL 业务表，含索引大约在 1G–3G；千万行级的表视字段多少在 5G–15G 区间；一个中等规模的 Java 应用包加日志目录，日常占用在 1G 以内。按这个量级算，50G 装下十几套中小站点的数据，或者一个跑了一两年的业务库，通常没有问题。

如果系统盘与数据盘共用这 50G，那么操作系统本身要先吃掉一块（常见 Linux 发行版 minimal 安装约 2G–5G，装齐运行环境后更厚），实际留给业务的可能只剩 40G 出头。这种情况下，容量规划要更保守一些，日志和备份必须提前设计归档策略。

用「日均增量」倒推可用天数

判断 50G 够不够，最实用的方法不是看当前占用多少，而是看每天涨多少。公式很简单：

可支撑天数 ≈ 50G ÷ 日均数据增量

举个示例场景：某业务数据库每天新增约 200MB 数据，同时应用日志每天产生约 150MB，合计日均增量 350MB。50G 除以 350MB，约等于 143 天，也就是四个月多月会触及容量上限。如果日均增量压到 100MB，同样 50G 可以支撑约 500 天。反过来说，如果业务每天要落 2GB 日志或原始数据，50G 只够撑 25 天——这种量级就不该在镇江云这一档上硬扛，日志应该外送到日志服务或对象存储。

还有一类业务天生和 50G 冲突：需要本地留存图片、附件、安装包、音视频素材的应用。这类数据的特点是「只增不减」，且单文件体积大。一部 500MB 的视频素材，100 个就吃掉 50G。遇到这种负载，正确做法是把文件层剥离出去，服务器上只保留索引和元数据。

随机端口意味着什么，什么业务会在这里卡住

镇江云四档的端口一栏统一写着「随机端口」。这是整张配置表里最容易被忽略、但上线时最容易出事的一项。忽略它的代价通常是：服务部署完了，本地 curl 能通，但外面就是访问不了。

对服务监听的直接影响

标准 Web 服务默认监听 80（HTTP）和 443（HTTPS）端口。在「随机端口」的分配模式下，实例拿到的对外服务端口不是这两个标准值，而是由平台分配的一个非固定端口号。这意味着部署时最先要改的动作是：Nginx、Apache 或应用自身的监听配置必须指向实际分配到的那个端口，照着教程写 listen 80 会直接导致服务起不来或起了也没人能访问。

同时，用户访问你的站点时，URL 里必须显式带上端口号，形如「域名:端口号」的形式。这一条会连带影响几件事：分享链接时端口号容易漏抄；部分企业内网出口只放行 80 和 443，非标准端口会被直接拦掉；移动端 App 或小程序里如果写死了不带端口的地址，请求会失败。

对防火墙与安全组策略的影响

第二个影响在放行策略上。很多运维习惯在 iptables、firewalld 或云平台安全组里直接写死放行 80/443，这套规则搬到随机端口环境里会全部失效——端口不对，包在进应用之前就被丢了。正确的做法是先登录实例确认实际分配到的端口号，再按这个号写放行规则，并且把这条规则写进部署文档里，避免重装系统后照旧配置又踩一次。

另外要注意，随机端口不等于「端口不重要」。分配到的端口一旦确立，就应该当作固定资产来管理：记录它、写进配置管理清单、在监控里加端口存活探测。因为它是随机分来的，重装或迁移后可能变化，凡是硬编码了这个端口号的地方（反向代理配置、健康检查、第三方回调地址）都要同步更新。

会在这里卡住的三类业务

其一是对外发布的正式站点，尤其是要做搜索引擎收录和品牌传播的主站。带非标准端口的 URL 在传播和收录上都不友好，用户体验也差。其二是需要接入 CDN 的业务——多数 CDN 服务的回源配置默认或仅支持 80/443 端口，回源端口非标准时可能无法接入，具体要以所用 CDN 的规则为准。其三是依赖第三方回调的服务，比如支付回调、消息推送回执，第三方通常只往标准端口回调。

与之相对，以下几类业务对随机端口完全不敏感：内部管理系统（访问者是自己人，地址记在内网文档里）、后端 API（调用方是自己控制的客户端，端口可配）、任务执行节点（根本不需要入站访问）。这正是「随机端口」这一约束最真实的筛选作用——它把镇江云这一档明确地推向了「对内 / 受控访问」，而不是「对公网广发」。

至于具体的端口分配范围、是否支持申请固定端口、是否支持端口映射或绑定独立 IP 后使用标准端口，镇江云页面未标注，选型前需向销售确认。这一条必须在下单前问清楚，它会直接决定部署方案能不能落地。

镇江节点适合放在哪类业务的哪一层

地域决定延迟的下限，规格决定能力的上限。镇江位于江苏，处在长三角城市群的覆盖范围内，这个位置决定了它天然适合服务华东一带的访问者——尤其是江苏本省及上海、浙江、安徽方向的本地业务。

按「业务分层」来摆位置

把一套典型业务拆成四层来看，镇江云这一类节点的适配度差异非常明显。

接入与分发层。这一层负责把内容推给终端用户，吃的是出网带宽。镇江云 30M 恒定带宽在这一层是硬伤，图片、视频、下载类分发不适合放这里，应该交给 CDN 或大带宽节点。

应用与计算层。这是镇江云最对口的层。跑 Web 应用进程、API 服务、任务队列、定时脚本、内部工具，吃的是 CPU 和内存，出网量小，4 核起步的算力给得足，随机端口对受控访问也不构成障碍。

数据与存储层。50G 数据盘决定了这一层只能放中小体量的库。百万到千万行级的业务库可以，TB 级数据仓库不行；业务主库可以，冷数据归档和文件仓库不行。

内部支撑层。堡垒机、监控采集端、CI/CD 构建机、内部 DNS、办公自动化系统——这些负载的共同特点是用户数量确定、访问时间可控、出网极少，是 77 元这一档最舒服的应用场景。

地域与合规这一层怎么考虑

站在国内节点的立场上，还有一个绕不开的环节是网站备案。一万网络深耕 IDC 19 年（成立于 2007 年），在国内节点上可协助免费网站备案，对于首次上云、手头没有备案经验的中小团队来说，这一项能省掉不少来回沟通的成本。备案的具体审核时限由主管部门流程决定，一万网络不承诺通过时限，这一点在排期时要留出余量。

把这几层连起来看，结论是清楚的：镇江节点的价值不在「便宜」，而在「用华东的位置承接计算密集、出网稀疏的那一层负载」。把它放在正确的层上，77 元能顶起一套完整业务的计算部分；放错层，加到 209 元也补不回来。

镇江云四档配置与适用边界对照表

这张表最值得反复看的是第三列和第五列。第三列告诉我们，四档之间每一次加价都是整齐的 44 元，且每次只动一个维度，先内存、后核心、再内存，所以选型时应该先诊断自己缺的是核数还是内存。第五列则给出了那条最重要的红线：只要瓶颈落在带宽或硬盘上，这四档里没有任何一档能解决问题。

一万网络在国内节点上还能怎么配

如果看完上面的分析，发现自己卡在 30M 或 50G 上，那么正确的动作不是硬加档，而是在一万网络的国内产品线里横向比一比，找一条出口或存储更宽的路。镇江云解决的是「便宜的计算」，它从来不是「便宜的带宽」。

三条可对照的国内路径

大陆各区物理机与云主机起步档。一万网络大陆节点的起步价区间在 ¥599–899：华西 ¥599 起、华东 ¥699 起、华南 ¥799 起、华北 ¥899 起（均为官网明示起步价，以官网实时价为准）。这条路径面向的是需要更大带宽、更大存储或独享资源的业务，和镇江云 77 元的定位不在同一量级，适合业务跑起来之后发现资源不够时的升级方向。

一万云弹性云。一万云 ¥25 起（官网明示起步价，以官网实时价为准），比镇江云 77 元还要低一截，走的是弹性伸缩路线。它的价值和镇江云不同——镇江云给的是「一次性确定的 4 核算力」，一万云给的是「可按需伸缩的入门算力」。如果你要的是临时测试环境、短期跑批、随时可能下线的实验性项目，弹性云更合适；如果你要的是一台稳定一直在跑的内部服务，镇江云的确定性更有价值。

大带宽与高防方向。一万网络另有高防大带宽 ¥700 起的产品线（官网明示起步价，以官网实时价为准），面向的正是出网流量大、需要抗攻击保障的业务。这一条是给「发现自己根本不是计算密集型而是流量密集型」的用户准备的出口。

怎么在这几条里做选择

判断顺序建议这样排：先算出网量。用前面第 3 节的口径估算日均出网，如果落在几十 GB 以内，镇江云 30M 够用，直接按 CPU 和内存需求在四档里挑；如果日均出网在 100GB 以上或者峰值经常打满带宽，就别在镇江云里加档，直接看大带宽方案或给镇江云配一层 CDN。再算存储量，用「50G ÷ 日均增量」倒推可支撑天数，撑不过半年的，把文件和日志外迁，或者换存储更大的产品。

一万网络深耕 IDC 19 年（成立于 2007 年），产品线从弹性云、地区云到裸金属、GPU 算力、高防大带宽都有覆盖，国内节点可协助免费网站备案，同时提供 7×24 中文工单、平均 5 分钟响应、免费系统盘每日 3 份快照与 30 秒回滚、5–20G 免费流量防护等基础服务。这意味着一次选型不必只盯一个档位——把计算放在镇江云、把分发交给 CDN、把冷数据放进对象存储，往往是比「加档」更省钱也更合理的组合。

四个容易踩的坑

坑一：把 77 元当成「先用着，不够再加档」的起点

为什么坑：很多人的心理是「先买入门档，不够再往上加」。在大多数云产品线上这个逻辑成立，但在镇江云这条线上不成立——四档的带宽恒为 30M、数据盘恒为 50G。如果你最终会发现自己需要 60M 带宽或 200G 硬盘，那么从 77 元加到 209 元的过程中，这个问题一步都没有被缓解，钱花了，瓶颈还在。

怎么避：下单前先做一次「瓶颈归位」：把预期负载按 CPU、内存、带宽、存储四项分别估一个量级，确认瓶颈确实落在前两项上，再买镇江云。只要后两项有一项超了，就不要从这里起步。

坑二：照着教程配 80/443，服务起了却谁都访问不了

为什么坑：端口一栏写着「随机端口」，但几乎所有部署教程的默认示例都是监听 80 或 443，防火墙放行规则也是照这两个端口写的。照抄的结果是：应用可能在本地监听成功，但外部请求进不来，或者根本绑不上端口。排查时又容易往 DNS、域名解析、防火墙上乱猜，白白耗掉半天。

怎么避：拿到实例后先确认实际分配到的端口号，把它记进部署文档；接着按这个端口写应用监听配置；再在 iptables / firewalld / 安全组里按这个端口放行，而不是 80/443。至于具体端口范围与能否申请固定端口，页面未标注，选型前需向销售确认。

坑三：50G 数据盘是「数据盘」，不等于整机存储

为什么坑：页面写的是「数据盘 50G」，有人会按「整机 50G」来做容量规划，上线后发现系统和运行环境已经先占掉一块，业务可用空间比预期少；也有人反过来以为系统盘另算，把 50G 全划给业务数据，结果系统分区空间告急。两种误判都源自同一个未明示的点。

怎么避：系统盘是否独立、系统盘容量多少，页面未标注，选型前需向销售确认。在确认之前，容量规划按「业务可用空间 ≤ 50G」来排，并且给日志单独设计轮转与归档策略（比如按天切割、保留 N 天、超出后外送），别让日志把数据盘填满。

坑四：用「月付价」倒推年成本，忽略了业务增长曲线

为什么坑：77 元/月看着便宜，年化 924 元也不多，但这是「当前负载」的价格。如果业务在一年内数据量翻倍、并发翻倍，那么真正要付的可能是 B 型或 C 型的年费，甚至要外购存储和 CDN。只按入门档算账，做出来的一年预算会严重偏低。

怎么避：做预算时按「起步档 + 一次升档 + 一次外购」三档来估：起步 77 元/月，预留一次升到 121 元或 165 元的可能，再预留文件/日志外送的成本。本文所列价格均为页面明示月付价，实际以官网实时价为准。

关于镇江云选型的七个高频疑问

Q1：77 元的镇江云 A 型，4G 内存跑得动数据库吗？

能跑，但要把它当成「专用库」而不是「混合库」。4G 内存里，操作系统和基础进程会占掉一部分，剩下能给数据库做缓存的空间有限。如果这台机器上还跑着 Web 应用、Redis 和定时任务，那么留给数据库的缓冲池会非常紧张，查询性能会明显下降。可行的做法是让 A 型只干一件事——要么当应用服务器，要么当数据库服务器，不要混装。如果确实需要一体部署（Nginx + PHP-FPM + MySQL + Redis 同机），建议直接看 B 型的 8G，多付的 44 元/月换来的是整机余量，比后期靠调参硬省内存划算得多。具体能支撑的数据量级，还要看表结构、索引设计和查询模式，建议上线前用真实数据压一次。

Q2：30M 带宽到底能撑多少人同时访问？

这个问题没有固定答案，取决于「每人每次取多少数据」。按前面给的口径估算：30M 理论满速约 3.75MB/s，若页面平均响应体积 1.5MB，单用户满速加载约 0.4 秒，但那是独占全部带宽的理想值；10 人并发时每人分到约 0.375MB/s，加载时间就拉长到 4 秒左右。若把页面压到 300KB（启用压缩、图片走 CDN、资源合并），同样的 30M 单秒可服务约 12 个请求，并发承载能力提升数倍。所以真正决定并发能力的往往不是带宽，而是你对页面体积的优化程度。这些换算是理论口径，实际还会受丢包、跨网互联质量影响。

Q3：随机端口能不能改成固定的 80/443？

镇江云页面在端口一栏统一标注「随机端口」，至于具体的端口分配范围、是否支持申请固定端口、是否支持绑定独立 IP 后使用标准端口、是否提供端口映射能力，页面均未标注，选型前需向销售确认。在确认之前，部署方案应按「必须使用非标准端口」来设计：应用监听配置、防火墙放行规则、对外访问地址都要带上实际分配的端口号。如果你的业务强依赖 80/443（例如要接入只支持标准端口回源的 CDN、或者要接受第三方固定回调），那么在下单前确认这一点就格外关键，它直接决定这个方案能不能落地。

Q4：50G 数据盘快满了，有没有扩盘的选项？

镇江云页面四档的数据盘统一标注为 50G，是否支持单独扩容、扩容的价格与上限，页面未标注，选型前需向销售确认。在确认之前，更稳妥的做法是从架构上减少对本地盘的依赖：日志按天切割并设置保留天数，超出后外送到日志服务或对象存储；用户上传的图片、附件、安装包直接写到对象存储，服务器本地只留索引；数据库定期做冷数据归档，把历史表迁出。这样做的好处是容量压力被转移到可弹性扩展的服务上，本机 50G 只需承接热数据，可支撑周期会显著变长。用「50G ÷ 日均增量」倒推可支撑天数，是判断是否需要尽快处理的最直接方法。

Q5：A 型加到 B 型多花 44 元只多 4G 内存，值不值？

要看瓶颈是不是真的在内存上。判断方法很直接：在 A 型上跑一段时间，观察内存使用率与 swap 使用情况。如果内存长期占满、开始用 swap、或者频繁出现 OOM 杀进程，而 CPU 利用率仍有余量，那这 44 元是整张表里性价比最高的一笔支出——它把「每核 1G」变成「每核 2G」，Java 堆能设上去、数据库连接池能开大、Redis 数据集能放进去，整机体验完全不同。反过来，如果内存还有富余而 CPU 长期跑在 70% 以上，那加内存没用，应该看 C 型的 8 核。先诊断、再加档，是镇江云这条产品线唯一正确的升级姿势，因为每一次加价都只动一个维度。

Q6：镇江这个位置，适合服务哪些地区的用户？

镇江位于江苏，处在长三角覆盖范围，天然适合承接上海、江苏、浙江、安徽方向的访问。如果你的用户集中在华东，把应用和计算层放在这里在地理上是合理的；如果用户主要在华南、华北或西部，就要考虑把节点挪到对应区域，或者用 CDN 把静态内容和动态加速铺到全国，让源站的位置不再成为体验变量。需要提醒的是，具体的机房名称、到各地的延迟毫秒数、路由走向，镇江云页面均未标注，选型前需向销售确认。如果需要给出延迟承诺，建议先用测试实例做一轮真实拨测，拿到数据再定，不要凭地域距离估算。

Q7：国内节点用镇江云，备案要怎么处理？

一万网络在国内节点上可协助免费网站备案，对于没有备案经验的中小团队，这项协助能省掉不少流程上的来回沟通。需要说明的是，备案的审核时限由主管部门的流程决定，一万网络不承诺通过时限，所以在项目排期上要为备案留出弹性，不要卡着上线日去做。另一个实务建议是：如果业务对上线时间要求很紧，可以先在镇江云上部署内部系统和后端服务（这些不依赖域名对外访问），把对外发布的环节排在备案完成之后，这样不会影响开发和联调进度。涉及域名、主体资质等具体材料要求，以主管部门的最新规定和一万网络备案协助人员的清单为准。

先判断出不出网，再决定上不上这一档

把全文的判断收拢成三条可以直接执行的结论。

该上 77 元这一档的业务：出网量小、以计算为主的负载。具体说就是——日均出网在几十 GB 以内、数据日均增量压得住（用 50G 除以日均增量能撑过半年）、访问者是受控人群因而对随机端口不敏感。典型例子：内部 OA 与工单系统、CI/CD 构建机、定时任务与数据处理脚本、对内 API 服务、监控与堡垒机、企业展示型官网（静态资源走 CDN）。这些负载吃的是 CPU 和内存，而这一档恰恰在这两项上给得厚。

必须从 B 档或更高起步的业务：内存是瓶颈的，从 B 型 121 元起步；CPU 核数是瓶颈的，从 C 型 165 元起步；两项都要余量的，直接看 D 型 209 元。判断依据就是监控数据——内存吃满看 B 型，CPU 吃满看 C 型，都吃满看 D 型。这里要特别注意那句反复强调的话：加档只买算力，如果你缺的是带宽或硬盘，加档没有意义。

根本不该选这个节点的业务：三类。出网型业务算一类——图床、素材站、视频分发、下载站、网盘类，30M 恒定带宽对它们是硬天花板，正确做法是换大带宽方案或把分发交给 CDN。存储型业务算一类——需要本地留存大量图片、附件、音视频素材或 TB 级数据的，50G 数据盘撑不住。强依赖标准端口对外发布的业务也算一类——需要搜索引擎收录的品牌主站、需要接入只支持 80/443 回源的 CDN、需要接受第三方固定回调的服务，在「随机端口」能否调整为固定端口得到确认之前，不要贸然部署。

一句话收尾：镇江云这一档的性价比，只对「算得多、吐得少、存得薄」的业务成立。先用第 3 节的带宽口径和第 4 节的容量公式各算一遍，再决定要不要下单，比看价格表拍脑袋靠谱得多。

这些数字从哪来

本文所引用的镇江云四档配置与价格，均取自一万网络官网镇江云页面（https://www.idc10000.net/zhenjiangyun ，页面标题：镇江云服务器租用-镇江云主机租用-镇江vps服务器租用）的明示信息：镇江云A型 CPU 4核心 / 内存 4G / 带宽 30M / 数据盘 50G / 端口 随机端口 / 77 元/月；镇江云B型 CPU 4核心 / 内存 8G / 带宽 30M / 数据盘 50G / 端口 随机端口 / 121 元/月；镇江云C型 CPU 8核心 / 内存 8G / 带宽 30M / 数据盘 50G / 端口 随机端口 / 165 元/月；镇江云D型 CPU 8核心 / 内存 16G / 带宽 30M / 数据盘 50G / 端口 随机端口 / 209 元/月。页面描述原文为：镇江高端机房自建自营云服务器。一万网络镇江云主机，配置齐全，性价比高，弹性购买，国内访问速度快，超低延迟，最快30s上架，智能监控，稳定安全有保障。

文中涉及的大陆各区起步价（华西 ¥599 起、华东 ¥699 起、华南 ¥799 起、华北 ¥899 起）、一万云 ¥25 起、高防大带宽 ¥700 起，均为官网明示起步价，实际以官网实时价为准；本文所列镇江云价格为页面明示月付价，下单时请以官网实时价为准。

文中凡属页面未标注的信息——具体端口分配范围、是否支持固定端口、系统盘是否独立及其容量、机房名称、各地延迟毫秒数、路由走向、带宽方向（出网/入网）界定、数据盘是否支持扩容及扩容上限——一律标注为「页面未标注，选型前需向销售确认」，本文不作任何推测或编造。文中出现的容量量级、并发估算、示例场景均为基于明示参数的推演口径，非实测数据，仅供选型参考。