DigitalOcean 新加坡 VPS 评测：电信回程偏慢，沪粤移动更快
DigitalOcean 新加坡 VPS 的三网表现差异明显：电信回程单线程为 1.4–2.4 Mbps，沪粤移动速度较高，联通则受高延迟影响。结合 2 核、3.8 GB 内存的硬件成绩，看看它适合哪些用途，以及大包重传、流媒体和 IP 风控方面有哪些限制。
适合
- 海外开发环境、轻量后端：所测新加坡及港日节点延迟较低，可列入试用候选。
- 上海、广东移动用户的文件访问：回程单线程分别为 566.5、775.9 Mbps，但还需留意大包重传。
限制
- 电信回程单线程仅 1.4–2.4 Mbps；联通回程延迟为 349–367 ms。
- 北京移动速度低于沪粤，部分移动大包回程存在高重传。
- Netflix 仅自制、Disney+ 屏蔽；IPQS 有风险提示，TCP 25 端口出站受阻。
- 实际套餐与订单总费用未确认；没有长期监控或持续应用压测结果。
先看结论
这台 DigitalOcean 新加坡 VPS 的国内访问表现，很大程度上取决于运营商和地区。电信回程单线程只有 1.4–2.4 Mbps，上海、广东移动分别达到 566.5 和 775.9 Mbps；联通速度高于电信，但回程延迟仍有 349–367 ms。 新加坡位置近，并不意味着大陆三网访问都快。[2]
如果用途是海外开发环境、轻量后端，或主要面向上海、广东移动用户，它可以列入试用候选。若主要访客来自大陆电信，或业务要求三网低延迟，这份结果不算理想。流媒体方面，Netflix 仅支持自制内容，Disney+ 被屏蔽；邮件方面，TCP 25 端口出站受阻。[1]
配置与测试环境
硬件报告使用 HardwareQuality v2026-05-21；IP 与网络数据来自 NodeQuality 和 TcpQuality。
| 项目 | 配置 |
|---|---|
| 服务商 / 产品 | DigitalOcean / Droplet |
| 地区 | 新加坡 |
| 虚拟化 / 架构 | KVM / x86_64 |
| CPU | DO-Regular，2 核心 / 2 线程，2494.140 MHz |
| 内存 | 系统可见 3.8 GB |
| 磁盘 | 总容量 24G，可用 20G；测试设备 vda1 |
| 网络 | IPv4；TCP 单线程、普通回程与大包回程；另有 TCP / UDP 路由探测 |
| 拥塞控制 / 队列 | bbr / fq |
| TCP 发送与接收缓存 | 均为 4K / 1M / 30.1M（最小 / 默认 / 最大值） |
网络报告中的窗口缩放、接收自调均为开启状态。这里列的是测试环境参数，不一定是新建实例的默认设置。本文没有 IPv6 或跨时段连续测试结果，因此主要讨论各方向的速度、延迟和访问限制，不评价长期稳定性。[1][2]
价格参考与额外费用
2026-10-18 查询时，官网 Basic Regular 的 2 vCPU、4 GiB 内存、80 GiB SSD、4,000 GiB 出站额度套餐为 24 USD/月，SGP1 地区列有 Basic 产品。[5][8]
这是购买时可参考的官方套餐，不是本实例的成交价。硬件报告的磁盘总容量为 24G，与该目录套餐不同；由于没有对应订单，具体 SKU、首购及续用总费用尚不能确认。税费、优惠、IPv4 费用和实际流量额度也应以订单为准。
计费时还要留意三点：
- 关机不会停止计费。 捆绑 CPU 套餐按秒计费，最低收费为 60 秒或 0.01 USD 中较高者，有月度封顶；销毁实例才结束该实例计费。v5 使用不同的封顶规则。[6]
- 流量超额另收费。 入站免费，额外出站为 0.01 USD/GiB；额度和用量按团队合并计算。[6]
- 备份不是免费附送。 比例备份计划每周为实例费用的 20%，每日为 30%，另有按数据量计费的计划。快照及其他附加资源也需单独核算。[5][7]
硬件性能
CPU 与内存
硬件报告识别到 DO-Regular，支持 AES-NI、AVX2、BMI1/2 等指令集。CPU 和内存成绩如下：[3][4]
| 指标 | 报告结果 |
|---|---|
| Sysbench CPU 单线程 | 925.03 |
| Sysbench CPU 多线程 | 1739.63 |
| Geekbench 5 单核 / 多核 | 556 / 995 |
| 内存总容量 | 3.8 GB |
| Sysbench 内存读取 | 18481.7 MB/s |
| Sysbench 内存写入 | 14855.8 MB/s |
| 内存延迟 | 197 ns |
这组数据可以作为轻量应用试部署的参考，但还不足以判断持续编译、数据库并发或高负载服务的表现：报告没有应用压测，也未列出 Sysbench 的完整参数与运行时长。DO-Regular 是虚拟机内识别到的名称，并不代表具体宿主机型号或独享核心。
磁盘：顺序吞吐与小块随机访问差异明显
fio 的四组结果如下，吞吐单位为 MB/s，IOPS 为每秒 I/O 次数。[3]
| 模式 | 读取 MB/s | 读取 IOPS | 写入 MB/s | 写入 IOPS |
|---|---|---|---|---|
| RND4K / Q1 | 11.5 | 2.9k | 34.7 | 8.9k |
| RND4K / Q32 | 232 | 59k | 180 | 46k |
| SEQ1M / Q1 | 983 | 983 | 1526 | 1.5k |
| SEQ1M / Q8 | 3860 | 3.9k | 2246 | 2.2k |
最醒目的数字是 Q8 下 3860 MB/s 的顺序读取，但与小文件访问更相关的 Q1 4K 随机读取为 11.5 MB/s、2.9k IOPS。两者对应不同块大小和队列深度：大块连续传输的高吞吐，不等于数据库的小块读写也有同样表现。
缓存策略、direct I/O、测试文件大小和运行时长没有列出，也没有同步落盘测试。对于数据库或频繁写入的业务，这些合成成绩只能作为初步参考。
国内网络：电信偏慢，联通延迟高，移动看地区
下表为 TcpQuality 的全部九个国内单线程节点。[2] 回程是实例向国内节点发送，去程是国内节点向实例发送；国内用户从 VPS 下载文件时，更需要关注回程速度。
| 节点 | 回程 Mbps | 去程 Mbps | 回程 ms | 去程 ms | 回程重传 |
|---|---|---|---|---|---|
| 北京电信 | 1.4 | 46.2 | 437 | 420 | 5.80% |
| 北京联通 | 220.8 | 83.2 | 349 | 357 | 0.00% |
| 北京移动 | 22.2 | 88.5 | 270 | 272 | 2.59% |
| 上海电信 | 2.4 | 45.4 | 349 | 864 | 11.61% |
| 上海联通 | 106.8 | 105.1 | 367 | 382 | 0.42% |
| 上海移动 | 566.5 | 437.6 | 166 | 154 | 1.11% |
| 广东电信 | 1.4 | 80.8 | 349 | 335 | 4.02% |
| 广东联通 | 215.0 | 49.9 | 358 | 419 | 0.00% |
| 广东移动 | 775.9 | 406.4 | 112 | 146 | 0.00% |
电信的瓶颈在回程。 三个节点只有 1.4–2.4 Mbps，去程则为 45.4–80.8 Mbps。如果用来向这些地区的电信用户分发文件，下载速度是明显短板。上海电信还出现 864 ms 的去程延迟，交互体验同样值得担心。
联通速度较高，但等待感未必小。 三地回程为 106.8–220.8 Mbps，延迟却有 349–367 ms。文件传输可以有一定吞吐，远程桌面、交互式管理和频繁小请求则更容易受到高延迟影响。
移动的地区差异很大。 上海、广东回程分别为 566.5、775.9 Mbps，北京只有 22.2 Mbps、270 ms。对沪粤移动用户而言，这组成绩比电信、联通更有吸引力，但不能照搬到北京或其他地区的宽带。
大包回程：高速度之外仍有重传
普通回程和大包回程各覆盖 31 个省份、三家运营商，共 93 个条目。[2]
| 模块 | 零值条目 | 1–20% | >20% |
|---|---|---|---|
| IPv4 回程 | 57，原称“零丢包” | 34 | 2 |
| IPv4 大包回程 | 45，原称“零重传” | 33 | 15 |
大包测试中，超过 20% 的条目更多。普通回程摘要用“丢包”、图例又用“重传”，两页统计口径不完全清楚，不能直接合并成整体丢包率。
广东移动是一个值得注意的例子：单线程速度达到 775.9 Mbps、回程重传为 0.00%，但大包回程出现 28% 重传。下面列出它与几项明显异常：[2]
| 节点 | 普通回程：延迟 / 百分比 | 大包回程：延迟 / 重传 | 表现 |
|---|---|---|---|
| 广东移动 | 99 ms / 0% | 79 ms / 28% | 普通回程与大包结果不同 |
| 吉林联通 | 346 ms / 74% | 340 ms / 76% | 两种模式均有高百分比值 |
| 江西移动 | 97 ms / 0% | 116 ms / 88% | 大包重传较高 |
| 云南移动 | 106 ms / 0% | 86 ms / 92% | 大包重传较高 |
| 贵州联通 | 354 ms / 0% | 359 ms / 0% | 两页线路标签均为 failed，仍返回延迟和百分比 |
黑龙江移动的大包结果也有异常：线路标签为 failed，延迟 222 ms，重传 88%。这些结果说明，单线程速度高或普通回程为零值，并不足以判断持续传输体验。异常原因尚不明确，单次探测也无法确定它会持续多久。
回程路由：电信、联通有绕行线索
NodeQuality 概览中，电信三地均为 TATA → 163；联通多处为 TATA → NoData；移动则随地区和协议出现 Level3 → CMI、TATA → CMI 等路径。[1]
- 北京电信： ASN 路径为
AS14061 → AS6453 → AS4134 → AS4847，地理标注经日本、美国回到北京。 - 三地联通： 北京、上海、广东的地理标注出现法国、德国，结合较高的端到端延迟，存在绕行线索。
- 广东移动： 路径为
AS14061 → AS6453 → AS58453 → AS9808 → AS56040，地理标注经香港进入广东，路由探测终点约 65.41 ms；单线程测速的回程延迟则为 112 ms。
路由定位可能有误，NoData 也只表示部分线路信息未识别。这些结果并不支持“大陆三网双向直连”的判断。
NodeQuality 的另一组国内测速中，上海联通发送 / 接收为 309 / 1655 Mbps，苏州移动为 310 / 0 Mbps；杭州电信、宁波电信、香港联通、深圳移动均为 ERROR。[1] 苏州移动接收为 0 的原因不明；这组测速的线程参数也未明确，不适合与上面的单线程成绩直接比较。
国际网络：港日新较快，远端方向有差异
TcpQuality 国际节点测试中，新加坡下载 / 上传延迟为 1 / 1 ms，香港为 34 / 34 ms，日本为 70 / 68 ms。作为远端参考，洛杉矶为 173 / 170 ms，法兰克福为 158 / 155 ms，里约热内卢为 353 / 350 ms；全部 12 个节点可见原报告。[2]
三个亚洲节点的延迟较低，适合优先评估需要访问这些地区服务的用途。新加坡节点的下载 / 上传重传原值为 1 / 0，该表未提供百分比口径。
NodeQuality 的十个国际节点结果如下。发送和接收以实例为视角，单位为 Mbps；重传列保留报告数值，不是百分比。[1]
| 节点 | 延迟 ms | 发送 Mbps | 发送重传 | 接收 Mbps | 接收重传 |
|---|---|---|---|---|---|
| 香港 | 36 | 1802 | 31k | 1232 | 7k |
| 东京 | 71 | 1605 | 6k | 1625 | 293 |
| 新加坡 | 1 | 2021 | 78k | 1909 | 9k |
| 悉尼 | 174 | 528 | 4k | 561 | 0 |
| 洛杉矶 | 171 | 691 | 0 | 607 | 0 |
| 纽约 | 217 | ERROR | Unknown（无独立值） | ERROR | Unknown（无独立值） |
| 法兰克福 | 155 | 64 | 0 | 25 | 139 |
| 伦敦 | 167 | 800 | 1 | 641 | 0 |
| 阿姆斯特丹 | 165 | 760 | 0 | 643 | 0 |
| 圣保罗 | 356 | 168 | 0 | 169 | 2 |
港日新方向有较高吞吐，法兰克福却只有发送 64、接收 25 Mbps，纽约测速失败。国际业务仍要看具体目的地，不能按新加坡节点的最高速度估计所有方向。
在 TcpQuality 单线程测试中，Apple IPv4 下载为 1320.8 Mbps、上传为 598.4 Mbps，延迟分别为 82 / 181 ms，下载重传 0.00%。[2] 这反映了该下载源的表现，不等于所有国际下载源都能达到同样速度。
常用服务入口
chatgpt.com、claude.ai、api.openai.com、api.github.com 均被测为可达，入口延迟分别为 3.470、3.433、4.454、4.280 ms。AWS STS 为 239.800 ms，Netflix API 为 191.916 ms，服务之间的差别同样明显。[2]
入口探测可能命中 CDN，并不包含账号登录、实际 API 请求或视频播放。Claude 在这里仅有域名可达结果，没有业务解锁验证；若用于 AI 应用，仍需确认自己的账号、模型和 API 调用是否正常。
IP 质量与服务限制
IP 归属与风控记录
IPQuality 将该地址识别为 AS14061 / DigitalOcean，使用地为新加坡、注册地为美国，多家数据库均归类为机房 IP。[1]
| 风险库 | 原始分值与标签 |
|---|---|
| IP2Location | 3 / 低风险 |
| Scamalytics | 51 / 中风险 |
| ipapi | 9.39% / 高风险 |
| AbuseIPDB | 0 / 低风险 |
| IPQS | 87 / 存在风险 |
AbuseIPDB、IP2Location 的结果较低，Scamalytics、ipapi 和 IPQS 则给出了不同程度的风险提示。其中 IPQS 还标记了代理、VPN 与滥用风险。
这对账号、支付等风控敏感业务是一个注意点。不过，风险库记录不等于某个平台一定封禁该 IP，各库的分值也不是同一套标准。是否出现验证码、登录限制或付款失败，要以实际平台的使用结果为准。
流媒体与 ChatGPT
| 服务 | 报告状态 | 地区 | 检测方式 |
|---|---|---|---|
| TikTok | 解锁 | SG | 原生 |
| Disney+ | 屏蔽 | Unknown（原字段空白） | Unknown（原字段空白） |
| Netflix | 仅自制 | SG | 原生 |
| YouTube | 解锁 | SG | 原生 |
| Amazon Prime Video | 解锁 | Unknown（解析异常） | 原生 |
| 解锁 | SG | 原生 | |
| ChatGPT | 解锁 | SG | 原生 |
如果主要为了看流媒体，这个结果不适合追求全平台解锁的用户：Netflix 仅自制，Disney+ 被屏蔽；Amazon Prime Video 虽显示解锁，地区却因解析异常无法确定。[1]
ChatGPT 显示 SG 解锁，但脚本检测不覆盖账号、付款、所有模型或 OpenAI API 的实际使用。表内“原生”是工具的检测标签，并不表示这是住宅 IP。
邮件发送
报告显示 TCP 25 端口出站阻断、远端 25 端口不可达。黑名单查询覆盖 423 项，其中正常 420、已标记 1、黑名单 2。[1]
因此，这份结果对应的实例不适合直接作为向外投递邮件的起点。其他邮件端口的可用性、最终投递率和阻断原因没有验证，使用 SMTP 中继也应先确认实际连接与投递情况。
适用场景与购买建议
| 场景 | 适用性 |
|---|---|
| 海外开发环境、轻量后端 | 可列入试用候选，所测新加坡及港日节点延迟较低 |
| 上海、广东移动用户的大文件访问 | 单线程速度有吸引力，但部分大包回程存在高重传 |
| 面向大陆电信用户分发文件 | 不优先考虑，所测回程吞吐明显偏低 |
| 大陆三网低延迟交互业务 | 不理想，电信和联通延迟较高，北京移动也不突出 |
| 流媒体全解锁、自建直投邮件 | 分别受片库 / 屏蔽和 25 端口限制 |
| 持续计算、重数据库和高可用生产服务 | 缺少相应负载与长期监控数据，暂无法判断 |
这台实例的看点是附近国际节点和沪粤移动方向，而不是大陆三网优化。 如果你的主要用户在中国大陆，购买前优先用他们实际使用的宽带试用，尤其要关注电信回程和移动的大包表现。对于需要持续低延迟、全天稳定传输的业务，仅凭这份成绩还不足以作出选择。