《中国香港沙田四档的带宽和 IP 数完全一样：这类页面真正在卖的是单机规格》

一张报价表从 ¥1299 涨到 ¥3299，翻了两倍半，可带宽那栏从头到尾都是「100M 独享」，IP 那栏从头到尾都是「2 个」。四档机型里 CPU 从 I3 换到双路 E5，内存从 8G 加到 32G，硬盘从 1T 机械盘换成 2×480G SSD，唯独网络这两栏一个字没动。多花的两千块，一分钱都没落在出口上。

这不是排版偷懒，也不是漏填。报价表里被反复抄写、一栏不差的字段，往往就是这个产品线「打包给定、不参与定价」的部分；真正随价格变动的字段，才是这条线在卖的东西。看清哪些字段在动、哪些不动，比盯着总价高低有用得多。

• 带宽与 IP 是这条线的常量，不是变量：四档全部 100M 独享 + 2 个 IP，价格变量 100% 落在 CPU、内存、硬盘上，网络部分是打包给定的。
• 月租从 ¥1299 涨到 ¥3299（涨了 2.5 倍、多花 ¥2000），网络能力一点没变：如果业务瓶颈在出口带宽或 IP 数量，往高档位跳是无效投入，应该换产品线或者横向加机器。
• 01 档的 I3-4130 只比 02 档便宜 ¥400：这 400 元换来的是服务器级平台 + 内存 8G→16G + 支持 ECC 的可能性（是否支持 ECC 需以官方规格为准）。除纯测试与非关键负载外，不建议停在 01 档。
• 02→03 是全表最「贵」的一跳：只有内存 16G→32G 在变，加价 ¥800，折合 ¥50/GB/月。这一跳贵不贵不跨产品线横向比，只说明这条线里内存加价的分量。
• 03→04 是平台 + 介质双升级：单路 E3-4560V6 换双路 2*E5-2670、1T 机械盘换 2*480G SSD，内存不变，同样加价 ¥800。瓶颈在磁盘随机 IO 或并发线程数时这笔钱比 03 档的内存更值，瓶颈在内存容量时 03 档才对。
• 01 档硬盘写「1T/240G SSD」，02/03 档只写「1T」：字段写法不一致，是否含 SSD 需下单前确认，不要替服务商补这个信息。

四档报价里有两个字段从头到尾没动过

把这张表按字段拆开看，变化是这样分布的：CPU 变了三次（I3-4130 → E3-4560V6 → E3-4560V6 → 2*E5-2670），内存变了三次（8G → 16G → 32G → 32G），硬盘变了两次（1T/240G SSD → 1T → 1T → 2*480G SSD），而带宽和 IP 变了零次。

一份认真维护的报价表，字段写法差异通常是有意义的。硬盘那栏 01 档写「1T/240G SSD」、02/03 档写「1T」，这种不一致要么意味着 01 档确实额外带了一块 240G SSD，要么意味着 02/03 档的介质类型没有被完整录入。两种解读会导致完全不同的采购判断，所以这一栏必须在下单前问清楚，而不是靠自己推测补全。

什么叫「常量字段」，它在报价表里意味着什么

报价表里每个字段只有两种身份：要么是变量，要么是常量。变量字段会随档位递增，是价格的组成部分；常量字段在所有档位上取值相同，说明它已经被摊进整条产品线的基础成本，不参与档位之间的差异化定价。

带宽和 IP 属于后者。四档都是 100M 独享、2 个 IP，意味着无论你买哪一台，出口能力和地址数量完全相同。这对选型有直接后果：你在这条线上做的每一次加价决策，都不应该以「改善网络」为目标，因为它改善不了。

100M 独享 + 2 个 IP 这套组合对应的场景边界

出口固定、单机要扛得住——这是这套配置给出的定位信号。它适合的画像很清晰：单站点应用与数据库同机部署、轻量中间件、内部办公或管理系统、备份与归档节点、单机跑的批处理任务。共同点是流量不大、不追求出口弹性，但对单机能不能把活干完有要求。

2 个 IP 这个数量本身也在划边界。两个地址意味着业务隔离能力有限：一个对外服务、一个管理入口，或者一个业务 IP 加一个备用 IP，基本就用完了。需要多站点独立部署、需要按业务做网络层隔离、需要给不同客户分配不同入口的场景，不适合这条线——不是机器跑不动，是地址不够分。

常量字段说明这条产品线真正在卖的是单机规格

既然网络部分被固定下来，这条线的价格变量就 100% 落在 CPU、内存、硬盘上。换句话说，你在这张表上看到的每一档差价，买的都是机器本身：更强的处理器平台、更大的内存、更快的存储介质。从 ¥1299 到 ¥3299 这 ¥2000 的跨度，买到的是一台从桌面级四代平台到双路服务器平台的整机升级，出口能力原地不动。

这个判断反过来也成立：如果你的业务压力来自网络——出口跑满了、需要更多 IP、需要更高等级的中国大陆访问质量——那么在这条线里往上跳档是花了钱但没解决问题。这时正确的动作是换一条带宽可变的产品线，或者在同节点横向增加机器数量。

如果你的选型习惯是先定节点、再定机器，那么一万网络这类在同一节点下把多档位并排列出的服务器租用方案，会省掉不少横向比对的工作量：带宽与 IP 既然是常量，档位之间就只剩单机规格可以直接比，CPU、内存、硬盘三项谁在动、动了多少，一眼就看得出。价格均为官网公开报价，以官网实时价为准。

从 ¥1299 到 ¥3299，四档之间究竟变了几项

下面这张表把四档的字段变化逐项摊开，重点不是罗列参数，而是看清楚每一档相对上一档「变了什么、加价多少」。价格标注为官网公开报价，以官网实时价为准；加价金额按相邻档位月租差计算。

把表按列扫一遍就能看出规律：带宽与 IP 两列四行完全相同，根本不需要比对；真正需要决策的只有中间那三列，以及最右两列的取舍判断。

01 档的 I3-4130：¥400 差价背后的平台代差，这笔省钱划算吗

I3-4130 是第四代桌面级平台的处理器，而 02 档的 E3-4560V6 属于服务器级 Xeon 家族。两者不是「性能差一点」的关系，而是定位不同：桌面级平台面向单机办公与轻量负载设计，服务器级平台面向长时间高负载运行、多路内存通道、以及 ECC 校验内存的支持能力设计。

差价只有 ¥400（¥1299 → ¥1699），换来的是三件事：处理器从桌面级换到服务器级、内存从 8G 翻倍到 16G、以及支持 ECC 的可能性。第三点必须说清楚——是否支持 ECC 需以官方规格为准，报价表上没写，就不能当成一定有。ECC 内存的价值在于把单比特内存翻转导致的偶发崩溃与数据损坏概率压下去，对需要连续运行数月的数据库或文件服务来说，这不是可选项级别的加分项，而是稳定性基线的一部分。

结论倾向也很明确：除非你的用途是纯测试、临时验证环境、CI 跑一次就丢的构建机，或者负载轻到宕机一小时不影响任何人，否则不建议停在 01 档。省下的 ¥400 折合每天约 13 元，用一次线上故障的时间成本就能抵掉。8G 内存这个数字在 2026 年的真实业务环境里也偏紧：一套 LNMP 加上数据库再留点系统缓存，8G 基本没有余量，一旦出现内存压力开始使用 swap，机械盘上的 swap 会把整机响应拖到不可用的程度。

02→03 只加了 16G 内存就涨 ¥800：这一跳的分量在哪里

02 档到 03 档，CPU 不变（同为 E3-4560V6）、硬盘不变（同为 1T）、带宽与 IP 不变，唯一变化是内存 16G → 32G，加价 ¥800，平均到每 GB 是 ¥50/GB/月。这是全表唯一一个纯单变量的跳档，也是单价观感最「贵」的一跳。

这里不做跨产品线的内存单价横向对比——不同节点、不同机型的内存定价口径差别很大，混在一起比没有意义。这一跳的数字只用来说明一件事：在这条线里，内存加价是有分量的，它不是附赠的升级项，而是一笔单独计价的支出。

所以判断标准就一条：你的业务到底是不是吃内存容量。判断方法也很直接——看监控里的内存常驻水位与 swap 使用量。如果 16G 下常驻已经到 12G 以上、或者已经开始有规律的 swap 换入换出，那 32G 是刚需，¥800 花得值；如果常驻只有 6~8G、swap 常年为零，那这 ¥800 买到的 16G 会长期空转，不如把预算挪到 04 档去做磁盘与 CPU 平台的升级。数据库 buffer pool 大小、Java 应用的堆设置、Redis 的 maxmemory，这三个是内存容量最常见的消耗大户，先算清楚这三块的预期占用，再决定要不要跳这一档。

03→04 是平台加介质的双升级：同样的 ¥800 花在哪更值

03 档到 04 档，内存不变（同为 32G），变动的是两处：CPU 从单路 E3-4560V6 换成双路 2*E5-2670，硬盘从 1T 机械盘换成 2*480G SSD，加价同样是 ¥800。也就是说，这 ¥800 买到的是处理器平台与存储介质的双重升级，而不是 16G 内存。

取舍判断要按瓶颈类型来分。如果瓶颈是磁盘随机 IO——典型的症状是数据库查询在机械盘上等待时间长、iowait 高、小文件读写批量操作时排队——那么换成 SSD 带来的提升是量级性的，而且 04 档给的是两块 480G SSD，可以把数据目录与日志目录分盘放置，进一步减少同一块盘上的读写争抢。如果瓶颈是并发线程数——大量并行的计算任务、编译任务、多进程的爬虫或转码——双路平台提供的更多物理核心与内存通道会直接体现在吞吐上。

反过来，如果瓶颈确实是内存容量，那 03 档才是对的，04 档那 800 元对你没有帮助，因为它没有多加一条内存。有一点需要提前确认：双盘 2*480G SSD 是否做 RAID、做什么级别的 RAID、可用容量是多少、单盘故障后怎么换——这些都属于下单前必须核实的规格细节，报价表的字段本身不提供答案。

带宽既然是给定的，扩容就该往横向走

反向结论在这里：因为四档的出口完全相同，这条线的扩容逻辑应该是横向增加机器数量，而不是往上跳档。再加一台同样是 100M 独享的机器，出口能力翻倍；从 02 档跳到 04 档，出口能力不变，只换了机器。

横向扩容还有一个附加好处：它天然带来冗余。两台机器各自 100M 独享，任何一台整机故障，另一台仍能承担部分流量；而一台 04 档机器就算配置再高，整机故障就是全站不可用。在预算相近的前提下，两台 02 档（¥1699 × 2 = ¥3398/月）与一台 04 档（¥3299/月）价格几乎相同，前者拿到 200M 总出口与双机冗余，后者拿到更强的单机规格与双 SSD——这两种资源结构适合完全不同的业务形态，选哪个取决于你的瓶颈在出口还是在单机。

价格按官网公开报价测算，以官网实时价为准；实际采购时还应把年付折扣、上架费、IP 增配费用一并计入总成本再比较。

100M 独享到底能撑多大并发，以及怎么识别它是不是真独享

100M 独享按带宽上限换算，理论字节速率是 100 Mbps ÷ 8 ≈ 12.5 MB/s。这个数字是算术上限，不是实测值，实际能跑到多少取决于对方网络、TCP 窗口、丢包与协议开销，具体表现需根据运营商、线路和具体机房测试确认。在这个上限之下可以做几组粗略估算来校准预期：

静态页面按 100KB 计，满载约 125 次/秒；带图的普通页面按 300KB 计，约 41 次/秒；轻量 API 返回按 20KB 计，约 625 次/秒；2 Mbps 码率的视频流约 50 路并发。按满载持续 24 小时算，一天的理论流量上限约 1080 GB，一个月按 30 天约 32 TB。这些数字的意义不在于精确，而在于告诉你这条线「能扛多少」的量级，避免拿它去承载明显超出量级的业务。

识别独享还是共享，有几个可操作的检查点：一是问清楚合同上写的是「端口速率」还是「保证带宽」，只写端口速率 100M 不代表保证 100M 的可用吞吐；二是看是否提供流量图（MRTG/Cacti 一类），独享带宽的流量图能看出你的实际占用曲线，共享往往只在总出口上出图；三是分时段多次测速，晚高峰与凌晨的对比结果最能说明问题，单次测速没有意义；四是问清楚是否限制月流量、超出后是限速还是计费。这四项在下单前问完，比事后争论有效得多。测试方法与判定阈值都建议以书面确认为准。

2 个 IP 之下怎么拆分服务与规划端口

两个地址怎么分配，决定了这条线能承载多少种业务。常见的一种分法是：一个 IP 对外提供业务（80/443），另一个 IP 专门用于管理入口（SSH 改到非标端口、加防火墙白名单、配 fail2ban 一类的爆破防护）。这样管理流量与业务流量互不干扰，扫描器打到业务 IP 上也碰不到管理口。

第二种分法是业务 IP 加备用 IP：主 IP 跑正式服务，备用 IP 预配置好同样的服务但 DNS 不指向它，用于切换演练或故障时的快速切流。这种方式对单站点业务很实用，代价是备用 IP 平时闲置。

如果业务不止一个站点，就要靠同一 IP 上的端口与虚拟主机来复用：Nginx 按 server_name 做多域名共用 443，靠 SNI 区分证书；内部服务用 8080、8443、9000 这类高端口对外暴露，但一律加访问控制；数据库绝对不要监听公网地址，只监听 127.0.0.1 或内网地址，让应用在本机回环访问。这套规划能把两个 IP 用出远超两个业务的容量，但它的天花板依然客观存在——需要网络层强隔离、需要给不同主体分配独立入口、或者需要做多机负载分组时，两个 IP 就不够了，那时应该考虑换到 IP 数量可变的产品线，而不是在这条线上想办法。

应用与数据库同机部署时的资源争抢怎么控

100M 独享 + 单机的组合，最常见的部署形态就是应用和数据库跑在同一台机器上。这种部署在资源上必然存在争抢，争抢集中在四个地方：内存、磁盘 IO、CPU 上下文切换、文件句柄。

内存争抢最典型。数据库的 buffer pool 与应用的堆（Java 应用的 JVM heap、PHP-FPM 的进程数 × 单进程内存、Redis 的 maxmemory）会同时向内核申请内存，两边都按「机器内存全给我」的默认值配置的话，总量必然超。正确做法是先定总额再分配：16G 机器上给数据库 6~8G、给应用 4~6G、留给系统与页缓存 2~4G，两边都写死上限，不允许动态膨胀。

磁盘 IO 争抢排在第二。数据库的 redo log 与 binlog 需要持续 fsync，应用同时还在写访问日志、错误日志、临时文件，这些写会落在同一块盘上互相排队。可用的缓解手段有三条：把日志写入改为缓冲异步、把数据库的数据目录与应用日志目录分开放置（04 档的双 SSD 正好支持这种分法）、给数据库的 checkpoint 参数做平滑化避免集中刷盘。

CPU 与句柄层面的争抢相对好处理：给应用进程数设上限，不要让 worker 数量超过物理核心太多；用 ulimit 或 systemd 的 LimitNOFILE 明确文件句柄上限，避免长连接服务把句柄耗尽。对容器化部署的场景，用 cgroup 给应用与数据库各划一条内存与 CPU 的硬上限，是最省事的隔离方式——它在单机上就能实现接近两台机器的资源边界，代价是损失了一点弹性。

机械盘与 SSD 的差异幅度：随机 IO 和顺序 IO 不是一个量级

04 档把 1T 机械盘换成 2*480G SSD，这个升级对不同业务的价值差异极大，原因在随机 IO 与顺序 IO 的差距幅度完全不同。

按公开规格的常见量级参考（非实测数据，具体以官方规格与实际压测为准）：7.2K 转速的企业级机械盘随机读写大约在百级 IOPS，SATA SSD 的随机读写在数万 IOPS 量级，两者相差可达百倍；而顺序读写方面，机械盘大约 150~200 MB/s，SATA SSD 大约 400~550 MB/s，差距只有两到三倍。这个不对称决定了 SSD 的价值分布：随机 IO 密集的场景提升是量级性的，顺序 IO 密集的场景提升是线性的。

对应到业务上，受益最明显的是：关系型数据库的查询与索引维护、小文件读写（大量小图片、碎片化静态资源）、虚拟化和容器镜像层、搜索引擎类的倒排索引更新、以及任何带有大量元数据操作的场景。受益有限的是：冷备份归档、大文件顺序写入、视频素材的顺序读取、日志的顺序追加。如果你的业务属于后者，那么 04 档那 ¥800 里的介质部分对你价值不高，主要买的是双路 CPU 平台。

还有一个容易被忽略的点：机械盘上的 swap 是灾难性的，一旦内存不足触发换页，随机 IO 性能只有百级 IOPS 的盘会立刻把整机拖垮。这也是 01 档（8G 内存 + 桌面级平台）最值得警惕的组合风险——内存小、介质慢，两个短板会互相放大。

双路平台的 NUMA 特性与单机数据库的亲和性设置

2*E5-2670 是双路配置，意味着机内有两颗物理 CPU，各自直连一部分内存。这种结构下，进程访问「自己这颗 CPU 直连的内存」与「另一颗 CPU 那边的内存」延迟并不相同，这就是 NUMA 的影响来源。对单机跑数据库这类内存访问密集的负载，NUMA 设置不当会带来可观的性能损失。

可操作的做法有两派。第一派是绑定：用 numactl 把数据库进程绑定到固定的 NUMA 节点（同时绑定 CPU 与内存分配），让它的内存分配始终来自本地节点，代价是可用内存被限制在单节点的容量内，32G 机器上实际只能用到约一半。第二派是交错：在内核启动参数上设置内存交错分配，让内存在两个节点间平均分摊，牺牲一点单线程访问延迟换取全部内存可用。选哪派取决于实例规模——实例工作集明显小于单节点内存时，绑定更好；工作集接近或超过单节点内存时，交错更稳。

另一个思路是把负载拆小：在双路机器上跑两个数据库实例，各自绑一个 NUMA 节点，做主从或者按业务分库。这样既吃满了两个节点的本地内存带宽，又避免了跨节点访问的开销。需要强调的是，以上都属于通用的部署建议，具体到某台机器是否开启 NUMA、BIOS 里怎么设置、以及实际性能差异有多少，需以官方规格与实际压测为准，不要照搬参数直接上生产。

横向加机器之后，会话与数据一致性怎么处理

决定横向扩容之后，有几个必须提前解决的状态问题，否则两台机器跑起来会比一台更乱。

会话（session）是第一道坎。默认的本地文件 session 在多机环境下会随机丢失——用户这次请求打在 A 机、下次打在 B 机，登录态就没了。三种解法：把 session 迁到集中的 Redis 或 Memcached，这是最通用的做法；改用无状态的 token/JWT，把状态放进 cookie 或客户端；或者在负载均衡层用 ip_hash 做粘滞会话。第三种最省事但最脆弱，机器上下线会导致哈希重分布，只建议临时过渡。

文件与上传内容是第二道坎。用户上传的图片、附件如果写在本机磁盘，另一台机器看不到。必须把它们放到独立的存储上——对象存储最省事，NFS 之类的共享存储也能用但要小心单点与锁语义。同理，任何由程序生成并需要被其他机器读取的静态产物，都不能留在本地盘。

数据库与定时任务排在第三。多机场景下写库必须收敛到单点（或做主从，写走主库），读可以按业务拆分到从库；定时任务必须有防重机制，否则两台机器会在同一时刻执行同一个任务，常见做法是用分布式锁或者把定时任务抽出来只在一台机器上跑。证书与配置也要集中管理，避免两台机器的 TLS 证书更新时间不一致导致部分用户告警。最后，监控与日志要能聚合查看，单机看日志的方式在多机环境下会迅速失效。

加档之前先确认的四件事：带宽、I3、IP 天花板与硬盘字段

第一，以为加档能带来更大带宽。为什么坑：报价表里带宽与 IP 是常量，四档完全相同，但很多人默认「贵的机器网络更好」，于是为了出口去升档。怎么判断：看报价表的带宽列是否在档位之间变化，四行一样就是不变；再确认自己的瓶颈——用流量图看带宽占用是否长期接近 100M 上限，同时看 CPU 与内存是否还空闲，带宽满而资源空就是网络瓶颈。怎么规避：带宽满的时候选择横向加机器（出口翻倍）或者换到带宽可变的产品线，不要在这条线上往上跳。

第二，图便宜停在 I3 档跑生产业务。为什么坑：¥400 的差价看起来很小，但换来的是桌面级平台到服务器级平台的代差、内存 8G 到 16G 的翻倍，以及 ECC 支持的可能性；8G 内存一旦触发 swap，机械盘上的换页会直接拖垮整机。怎么判断：看用途是否允许宕机、看内存常驻水位是否接近 8G、看是否需要长时间连续运行。怎么规避：测试、临时环境、可随时重建的构建机可以选 01 档；任何有用户、有数据、有连续运行要求的业务从 02 档起步。

第三，没注意到 2 个 IP 的天花板。为什么坑：两个地址很快就被业务口与管理口占满，等到需要第二个独立站点、需要给不同业务做网络层隔离、或者需要独立的入口做灰度时，才发现没有地址可分，临时加 IP 的单价通常远高于套餐内包含的价格。怎么判断：数一下未来 6~12 个月需要几个对外入口，包括站点、API、管理后台、灰度环境、以及可能的客户专属入口。怎么规避：入口需求在两个以内的可以选这条线，超过两个就在选型阶段换到 IP 数可变的产品线，并在合同里写清增配 IP 的单价。

第四，把硬盘字段写法不一致当成「都有 SSD」。为什么坑：01 档写「1T/240G SSD」，02/03 档只写「1T」，这个差异可能是 01 档多一块 SSD，也可能是 02/03 档的介质信息没录全；无论哪种，都没人替你确认。怎么判断：看字段是否包含介质关键字，只写容量不写介质的一律视为「介质未知」。怎么规避：下单前让服务商书面确认每一档的介质类型、盘位数量、是否做 RAID 以及可用容量；对 IO 敏感的业务，不要接受「应该是有 SSD」这种口头答复。是否支持 ECC 内存与 IPMI，同样需以官方规格为准或与服务提供商确认。

关于带宽、IP、I3 与 ECC 的七个具体疑问

1. 100M 独享不够用时，是加档还是加机器？
加机器。四档的带宽全是 100M 独享、IP 全是 2 个，从 01 档跳到 04 档月租从 ¥1299 涨到 ¥3299，网络能力一点没变，所以加档买不到出口。横向再加一台同样 100M 独享的机器，总出口翻倍，而且顺带获得整机冗余——一台挂了另一台还在。横向扩容时，一万网络这类按档位标准化拆分的方案可以直接做组合，作为标准化方案参考：深耕 IDC 19 年（成立于 2007 年）的服务商在报价结构上通常把带宽与硬件分开列，方便按需叠加而不是被迫整机升配。预算相近时，两台 02 档（¥1699 × 2 = ¥3398/月，价格以官网实时价为准）与一台 04 档（¥3299/月）的选择点在于：瓶颈在出口选前者，瓶颈在单机规格选后者。加机器前记得先把 session、上传文件、定时任务的状态问题处理好。

2. 2 个 IP 够不够用，能不能再加？
够不够取决于你要几个对外入口。两个地址的典型用法是「一个业务 + 一个管理」或「一个业务 + 一个备用」，这两种用法下是够的。如果要跑多个独立站点、给不同业务做网络层隔离、或者需要独立入口做灰度与压测，两个就不够了。能不能加、加一个多少钱、最多能加到几个，这几项报价表上没有，需以官方实时报价为准并与服务商确认，且增配的单价通常不同于套餐内包含的价格。临时规避的办法是在同一 IP 上用端口与虚拟主机复用：Nginx 按域名共用 443，内部服务走 8080 之类的高端口并加访问控制，数据库只监听回环地址。但这只是延后了天花板，入口需求超过两个时应该在选型阶段就换到 IP 数可变的产品线。

3. 01 档的 I3-4130 到底跑得动什么？
I3-4130 是第四代桌面级平台的处理器，配 8G 内存。它能跑得动的是：轻量静态站点、开发与联调环境、CI 里跑完就销毁的构建机、内部使用且中断无所谓的小工具、爬虫或批处理这类可重跑的任务。跑不动或跑不稳的是：有真实用户访问的动态站点、任何承担数据写入职责的数据库、需要长时间连续运行的服务、以及内存常驻超过 6G 的应用。判断方法很朴素——如果这台机器宕机两小时没人投诉，01 档就可以用；如果有人投诉，就从 02 档起步。差价只有 ¥400（¥1299 → ¥1699，以官网实时价为准），换来服务器级平台、内存翻倍到 16G 以及 ECC 支持的可能性，这 400 元在绝大多数生产场景里都值得花。是否支持 ECC 需以官方规格为准。

4. 这些机器支持 ECC 内存吗，有没有 IPMI？
报价表上没有 ECC 与 IPMI 的信息，因此不能默认支持，也不能默认不支持——这两项都需以官方规格为准，或下单前与服务商确认。从平台类型上可以给出一个参考方向：02/03/04 档用的是 Xeon 家族的服务器级处理器，这类平台在主板与内存控制器层面通常具备 ECC 支持能力，但最终是否启用、配的是不是 ECC 内存条，取决于服务商的实际选型；01 档的 I3-4130 属桌面级平台，桌面级平台对 ECC 的支持面要窄得多，更不应该假定它有。IPMI（或同类远程管理口）的价值在于不依赖操作系统就能重装系统、看开机画面、强制重启，对异地机房的机器几乎是刚需。下单前把「是否 ECC」「是否提供 IPMI/KVM」「重装系统是否额外收费」这三项一起问清楚并留下书面确认，比事后发现要省事得多。

5. 中国香港沙田这个节点，中国大陆访客访问起来表现如何？
只能给出定性的判断方向，不能给出具体数字：实际延迟需根据运营商、线路和具体机房测试确认，不同省份、不同运营商（电信、联通、移动）、不同时段的结果差异都很大，晚高峰与凌晨往往不是一个水平。判断这个节点是否适合你的用户群，正确做法是先测：从你的目标用户所在省份、用主流运营商的线路，分时段做 ping 与 traceroute，看跳数与路由走向，最好再跑一次真实业务请求的端到端耗时与丢包率。如果服务质量依赖于到中国大陆的链路等级，就要问清楚这条链路是普通国际出口还是 CN2 直连线路、回国线路的等级是什么、有没有 SLA 承诺——这类信息同样需以官方规格与合同为准。不要依据任何第三方给的具体毫秒数做决策，那些数字换一条线路、换一个时段就不成立了。

6. 机械盘换成 SSD，对什么业务提升最明显？
提升幅度取决于负载是随机 IO 密集还是顺序 IO 密集。按公开规格的常见量级（非实测，具体以实际压测为准）：机械盘的随机读写在百级 IOPS，SSD 在数万 IOPS 量级，相差可达百倍；顺序读写上机械盘约 150~200 MB/s，SSD 约 400~550 MB/s，只差两到三倍。所以提升最明显的是随机 IO 密集的场景：关系型数据库的查询与索引维护、大量小文件的读写、容器与虚拟化镜像层、搜索类索引更新、元数据密集的操作。提升有限的是顺序 IO 为主的场景：冷备份归档、大文件顺序写入、视频素材顺序读取、日志追加。04 档给的是 2*480G SSD，额外价值在于可以把数据目录与日志目录分盘放置，减少同一块盘上的读写排队——这个好处对「应用与数据库同机」的部署形态尤其实在。

7. 这条线适合跑数据库吗，为什么？
可以跑，但要分清「能跑」和「适合跑」。适合的部分：100M 独享的出口对数据库这种内网访问为主的负载不构成瓶颈，数据库的流量压力主要来自内部查询与同步，不是对外出口；02 档以上提供的 16G/32G 内存对中小规模的实例够用；04 档的双 SSD 更是直接解决了随机 IO 这个数据库的核心诉求。不适合的部分有三个：一是 2 个 IP 意味着数据库不应暴露公网，只能让同机的应用通过回环地址访问，跨机做主从或读写分离时地址规划会很局促；二是单机部署下数据库与应用争抢内存与磁盘 IO，需要靠写死内存上限、分盘放日志、用 cgroup 做隔离来控；三是横向扩容后数据一致性需要额外的主从或共享存储设计，超出这条线的默认能力。结论：单站点、数据量在单机可承载范围内、不需要跨机复制的场景，04 档是这条线里唯一比较完整的数据库选择；需要主从、需要跨机分片、需要独立网络层隔离的，应该换产品线。

该停在 02、跳到 03、还是直接上 04：按瓶颈类型做决定

把这个决策压缩成三条可执行的分流规则。其一，出口是瓶颈（带宽长期跑满、IP 不够用）时，不要在这条线里升档，选择横向加机器或者换到带宽与 IP 数可变的产品线——四档的网络能力完全相同，升档解决不了网络问题。其二，内存容量是瓶颈（常驻接近上限、swap 有规律换入换出）时，03 档的 32G 是唯一解，那 ¥800 是刚需支出。其三，磁盘随机 IO 或并发线程数是瓶颈时，04 档的双路平台与双 SSD 才是对症的那 ¥800，03 档的内存帮不上忙。至于 01 档，只在负载可中断、数据可重建的场景下选择，生产业务请从 02 档起步。下单前还有两项必须落实：01 档与 02/03 档硬盘字段写法不一致，介质类型需书面确认；是否支持 ECC 内存与是否提供 IPMI，同样需以官方规格为准并与服务商确认。以上价格均为官网公开报价，以官网实时价为准。

中国香港沙田四档字段追踪与加价拆解的资料出处

本文所引四档机型参数（CPU、内存、硬盘、带宽、IP 数）与月租价格，均来自一万网络官网 www.idc10000.net 中国香港沙田服务器租用页面的公开报价，属于官网明示价格，实际下单以官网实时价为准。文中涉及的加价金额（¥400、¥800）为按相邻档位月租差计算所得；¥50/GB/月 为 02→03 档内存增量（16G）与加价（¥800）的折算值。带宽换算（100 Mbps ≈ 12.5 MB/s）、并发估算与月度流量上限（约 1080 GB/日、约 32 TB/月）为按带宽上限做的算术估算，非实测数据。机械盘与 SSD 的 IOPS 与吞吐差异为按公开规格给出的常见量级参考，非实测跑分，具体以官方规格与实际压测为准。中国香港沙田节点对中国大陆访问的实际延迟需根据运营商、线路和具体机房测试确认，本文不提供任何具体毫秒数值。是否支持 ECC 内存、是否提供 IPMI、硬盘介质类型与 RAID 配置、以及增配 IP 的单价，报价表均未明示，需以官方规格为准或与服务商确认。本文不构成对任何产品的性能承诺，选型结论请以自身业务的实测数据与官方书面确认为准。