Haruzakura Cloud 与云名称背后的中国记录

摘要

• Haruzakura Cloud 具有可追溯的中国公开身份：2023 年注册的域名、2024 年使用中文名称“春樱云计算”的存档店面，以及后来在 2024 年注册的 APNIC 记录，涉及 AS153458 和武汉的一个 IPv6 分配。
• 网络证据真实但有限。2026 年 7 月，公共路由收集器看到一个 RPKI 有效的 IPv6/48，没有发起的 IPv4 前缀和一个观察到的上游，正是赞助该 ASN 并持有父地址块的同一组织。
• 历史网站提供 VPS、虚拟主机、控制面板功能、备份或快照功能、DDoS 选项、多个国家和城市标签、工单和全天候支持。这些是卖家的声明，并非独立测量的服务结果。
• 在 2026 年 7 月的检查中，顶级域名没有公共 A、AAAA 或 MX 记录。这并不证明业务已停止，但它消除了获取当前产品、合同、状态和支持证据的最简单公开途径。
• 严肃的买家应将名称、网站、数字资源、路由和支持声明视为单独的证明。购买案例取决于当前的法律身份、工作负载层面的位置安排、支持升级条款、恢复测试、导出权限以及服务能够在单一可见网络路径之外运行的证据。

一个云名称带着两种不同的证明

Haruzakura Cloud 是对“云”这个词如何轻易超越其背后记录的有用检验。现存的公开材料有足够的特异性，可以排除该名称只是一个空目录标签的想法。但其中也有太多空白，不允许采购团队直接将该名称转化为运营保证。

第一种证明是商业性的。互联网档案馆 2024 年 8 月的快照保存了一个中文语言店面，名称为“春樱云计算”。它提供虚拟专用服务器、虚拟主机、标有 UCloud 的轻量主机产品、账户注册、客户控制台以及多个位置选择。该页面描述了启动、停止和重启服务器、重装操作系统、重置密码、查看资源使用以及进行备份或快照等操作。它显示了起价，并多次声称提供在线服务、工单支持和7*24协助。

第二种是基础设施性的。APNIC 的 AS153458 记录标识了HARUZAKURA-AS-AP，国家 CN，描述为 Haruzakura Cloud，地址在武汉。单独APNIC 关于2406:840:feac::/48的记录将该 IPv6 块分配给同一个名称。公共路由收集器可以看到该前缀。匹配的路由来源授权使得观察到的宣告为 RPKI 有效。

这些证明回答了不同的问题。存档页面说明使用该品牌的人在 2024 年提供什么。注册表说明谁对互联网号码资源负责。路由系统说明其他网络可以了解到该资源的路径。但它们本身都不能证明客户收到了承诺的虚拟机、备份已恢复、支持工程师在凌晨 3 点回应，或者数据停留在合同规定的管辖区内。

店面出现在自治系统之前

日期揭示了一个紧凑的故事。Verisign 的域名记录显示haruzakura.com于 2023 年 10 月 15 日通过阿里云计算的 HiChina 注册商注册。到 2024 年 8 月，存档的网站已经在销售产品。APNIC 于 2024 年 11 月 12 日注册了 Haruzakura 组织对象和 IPv6 块，两天后注册了 AS153458。因此，商业展示先于公开的自治系统身份几个月。

这个顺序本身并不可疑。托管卖家通常从另一家提供商的 infrastructure 开始，后来才获得号码资源。转售商可能永远不需要自己的 ASN。年轻运营商可能在成长过程中增加路由控制。但时间顺序防止了一个粗心的推断：8 月份展示的产品不能假定是在 AS153458 上运行的，因为该 ASN 当时还不存在于公共注册表中。该页面上的香港、洛杉矶、德国和成都标签也无法映射到后来的/48，因为没有服务器、设施或路由证据。

报价本身混合了几种可能的运营角色。起始价 2.40 元人民币的虚拟主机暗示一种共享服务层。起始价 15 元的 VPS 计划提到独立的 IPv4 支持、多个数据中心、SSD RAID 10 和带宽选项。起始价 34 元、标有 UCloud 的轻量主机计划描述了一个 IPv4 地址和全球数据中心。该页面还提到物理服务器产品即将推出。这是一个产品目录，而非统一的技术平台。它可能结合了 Haruzakura 直接运营的资源、从大型提供商转售的服务以及通过第三方面板配置的产品。公开页面没有在这些层面之间分配责任。

存档的控制台语言比形容词更有用。电源控制、重装、密码重置、资源视图、备份和快照描述了可以测试的客户操作。“优质网络”、“强大硬件”和“高稳定性”则没有。第一组可以成为验收标准：配置需要多长时间，哪些操作被记录，谁可以覆盖它们，以及快照能否导出？第二组仍然是广告，直到与测量和补救措施挂钩。

2024 年 12 月的快照使情况更加复杂。它仍然推广云服务器、root 访问、电源控制、配置更改和远程 VNC 控制台。但它也包含大段无关的英文模板文本、通用的移动应用下载计数器、示例推荐和应用计划价格。这些材料不应被用来指控欺骗；未完成的设计改版是更简单的解释。但这确实说明了为什么必须对页面内容进行分级。当一个可见的计数器周围是服务器托管页面上的 Android、iOS 和 Windows 应用下载标签时，它就不是客户指标。声明的记录得以保留；该声明的可信度取决于上下文。

身份是连接，而不是标签

公开材料中出现了三个名称。商业品牌是“春樱云计算”，自然地呈现为 Haruzakura Cloud。8 月页面在页脚显示了“湖北春樱云计算信息技术有限公司”。APNIC 使用英文组织标签 Haruzakura Cloud。这些名称看似有关联，但每个来自不同的系统，每个系统有不同的目的。

存档页面还显示了备案号“鄂 ICP 备 2024050251 号-1”。中国非经营性互联网信息服务规定要求在中国境内提供的相关服务进行备案，并确保备案信息准确。因此，页脚提供了一个具体的标识符，买家可以向主管机关核实。但它不应被夸大。网站备案不是云安全认证、所有服务的电信许可证、受益所有权证明，或者页脚上方展示的产品按描述运行的证据。

域名注册提供了另一个部分连接。Verisign 显示一个活跃的.com注册和 HiChina 名称服务器。HiChina 自己的 RDAP 响应将经过隐私编辑的注册人置于湖北。它没有披露公司名称或个人，因此域名记录不能独立证明注册人就是旧页面上命名的中国公司。然而，它与后来 APNIC 中使用的湖北身份和武汉地址在地理上一致。

APNIC 增加了更具可归属性的技术身份。ASN 记录列出了一个人类管理和技术联系人、一个武汉地址以及一个 2026 年 5 月经过验证的事件响应联系人邮箱。这很有意义。数字资源治理依赖于可联系的人员和维护者，最近验证的滥用联系人比废弃记录更强。但该邮箱的验证并不能说明商业支持队列、该人员签署客户合同的权力，或者诊断虚拟机监视器、存储或应用程序问题的人员配置。

对于采购，缺失的连接可以简单陈述。合同方应提供当前的中国工商登记摘录、统一社会信用代码、该实体与域名注册人之间的确切关系、其使用 Haruzakura 品牌的权力，以及每个分包商的服务角色。合同名称、发票名称、收款账户、网站备案身份和 APNIC 组织不必文本一致。它们之间需要有一条有文档记录的路径。

一条 IPv6 路由证明什么

Haruzakura 目前最有力的证据也是最容易被过度解读的。RIPEstat 路由状态快照在 2026 年 7 月 14 日 16:00 UTC 看到由 AS153458 发起的一条 IPv6/48，没有发起的 IPv4 空间和一个观察到的邻居。该路由对于 RIPE RIS 中 320 个全馈送 IPv6 对等体中的 321 个可见。这是广泛的控制平面传播：该宣告不仅仅是存在于注册表中而不被更广泛的互联网看到。

伴随的已宣告前缀视图将其两周窗口内唯一足够可见的前缀标识为2406:840:feac::/48。BGP.Tools和Hurricane Electric BGP Toolkit独立显示了相同的基本形状：零个 IPv4 前缀，一个 IPv6 前缀，一个观察到的外部 ASN。收集器之间的一致性很有用，因为路由视图依赖于时间且不完整。

/48在数值上是很大的地址空间，但地址数量是衡量云容量的错误标准。IPv6 分配故意很大。一个/48可以支持许多子网，同时不承载任何客户负载，或者它可以服务于一个适度的平台。公共路由不揭示有多少地址活跃，有多少服务器存在，哪些端口在应答，机器位于何处，存储如何复制，或者客户流量是否使用该块。

没有发起的 IPv4 前缀同样值得谨慎对待。旧的店面在多项报价中推广了 IPv4，但这些报价在 ASN 之前。Haruzakura 可能使用了由另一提供商供应和发起的地址，可能停止了这些产品，或者可能在其他安排下为客户提供服务。公开证据只支持一个更狭窄的陈述：AS153458 本身在观察点没有明显发起 IPv4。它不支持称 Haruzakura 从未有过 IPv4 服务。

RPKI 改善了图景的一部分。RIPEstat 验证结果报告 AS153458 和确切/48存在匹配的路由来源授权。正如APNIC 所解释的，有效的 ROA 允许网络验证地址持有者已授权该 ASN 发起该前缀。它有助于减少意外或恶意的来源劫持。

它不签署申请，不验证销售虚拟机的公司的真实性，不验证完整的 AS 路径，也不确保所有上游都拒绝错误路由。它不显示 DDoS 容量、加密、补丁、访问控制或恢复。RPKI 有效是一个精确且有价值的陈述。“安全云”则要大得多。

赞助商和单条可见路径

前缀记录将2406:840:feac::/48分类为ASSIGNED NON-PORTABLE。父级2406:840::/32由宁波大猫吗信息技术有限公司持有，根据APNIC 的赞助商记录。该组织也被列为 ASN 赞助商。公共路由收集器看到其 AS139317 与 Haruzakura 相邻，并且RIPEstat 邻居视图在观察点没有报告第二个邻居。

这是一个连贯的技术关系。赞助商持有父地址空间；Haruzakura 获得一个非便携式委派；赞助商的 ASN 是可见的提供商端路径。这比自由格式的网站徽章更有力，因为注册表委派和全局路由一致。它也描述了依赖性。

依赖不等于弱点。许多有能力的小网络使用一家传输提供商，赞助商可以提供有价值的注册、路由和运营支持。商业问题是服务承诺是否承认这种依赖。如果当 AS139317 遇到故障、配置错误或商业纠纷时，Haruzakura 唯一的公共路由消失，那么有什么替代路径？服务是否有另一个在上游不可见？前缀能否移动？谁控制 ROA、路由对象和紧急更改？如果赞助商关系结束，非便携式块会发生什么？

答案在异常运行期间最为关键。对于其所有者接受停机时间的低成本开发主机来说，单一提供商可能完全足够。但对于被推销为高可用性的工作负载、在事件期间需要的支持门户，或者其恢复依赖于通过同一条路径访问备份的系统来说，则更难证明合理。买家应将拓扑与业务影响匹配，而不是根据超大规模架构对每项服务进行评级。

AS153458 的 PeeringDB 记录说明了为什么必须核实声明。该档案创建于 2026 年 3 月，将网络标记为教育/研究，称流量在 1-5 Gbps 范围内，并包含用于 24 个 IPv4 和 42 个 IPv6 前缀的容量字段。它没有列出交换点、设施、Looking Glass 或公共状态仪表板。PeeringDB 档案是自行填写的。容量字段不是观察到的路由表（显示零个 IPv4 和一个 IPv6 前缀）。教育/研究的选择也不能证明运营者是一所大学或研究机构。

域名已注册但服务表面安静

在 2026 年 7 月的审查期间，该域名在注册表中活跃，使用 HiChina 名称服务器，到期日期为 2026 年 10 月。DNS 讲述了一个更有限的故事。Google 公共 DNS A 查询和AAAA 查询返回了成功的 DNS 状态和权威起始授权机构记录，但顶级域名没有地址答案。MX 查询同样没有找到入站邮件目标。该区域确实发布了一个指向阿里云邮件服务的 SPF TXT 策略，但 SPF 如果没有 MX 记录，无法使顶级域名的正常入站地址可达。

这个观察有狭隘的含义：浏览器或邮件发送者使用裸域名在那些记录类型中当时没有普通的公共目的地。这并不证明每个子域名都不存在，所有客户系统离线，支持使用其他域名，或者公司已经解散。DNS 可以快速变化，服务可以私有或单独命名。

然而，在所宣传的域名上的沉默带来了运营成本。历史页面是买家可以看到产品、条款、账户入口点和支持语言的地方。没有当前网站，更难识别实时目录、检查价格、查找事件通知、审查隐私政策、验证证书或确定哪些旧声明仍然有效。当前路由不能弥补这一损失，因为路由不标识应用程序端点。

PeeringDB 中没有公共状态仪表板加剧了问题。小型提供商不需要复杂的通信运营，但它确实需要一种带外方式告诉客户控制面板、网络、存储和支持队列是否健康。如果同一域名和路由既承载生产流量又承载事件通信，那么网络故障可能会连同服务一起移除解释。

报价是否符合云的含义？

旧店面广泛使用了云语言。NIST 的定义为这种语言提供了一个有用的操作测试：按需自助服务、广泛网络访问、资源池化、快速弹性和可测量服务。它还将软件、平台和基础设施服务模型分开。这些不是品牌要求。它们帮助客户理解什么是自动化的、什么是共享的以及什么仍然是提供商的责任。

Haruzakura 的存档控制面板声明指向按需基础设施。客户显然可以启动、停止、重启和重装服务器，重置凭据并查看资源使用。配置被描述为可调整，几个计划有明确的 CPU、内存、存储、带宽和流量数量。这些比单纯的租用机器的承诺更接近云。

其他特征不清楚。该页面没有显示配置时间分布、API、自动缩放机制、具有来源的镜像目录、计量方法或与资源事件相关的账单账本。它没有解释 CPU 和内存是预留的、突发的还是争用的，即使使用了诸如“专用资源”和“完整 CPU 性能”之类的语言。它没有定义资源池或确定哪些产品是 Haruzakura 运营而非转售的。它提供了位置但没有发布区域架构。

这种区别改变了自动化风险。在成熟的基础设施服务中，控制台操作应经过认证 API、策略检查、作业状态、审计事件和回滚或恢复路径。在轻度集成的托管服务中，同一个按钮可能调用第三方面板或创建手动支持任务。客户体验在常规重启时可能相似，但在作业停滞、密码重置针对错误实例或重装销毁数据时会出现深刻差异。

这是演示比幻灯片更有价值的地方。买家应配置一个可丢弃实例，测量就绪状态的时间，执行控制台操作，轮换凭据，创建并恢复快照，导出数据，检查事件历史，触发账单更改并关闭账户。每个操作应有可归属的结果。失败的操作应暴露一个支持可以诊断的状态。隐藏不确定性的自动化只是将工作转移给买方的审核者。

数据本地性是工作负载地图，不是国家代码

Haruzakura 的记录包含几个地理信号：域名记录中的湖北，APNIC 中的武汉，赞助商的宁波，ASN 和前缀上的国家 CN，以及 8 月店面中的位置标签包括香港、洛杉矶、德国和成都。没有一个是“我的数据在哪里？”的完整答案。

互联网注册表中的国家字段是行政性的。路由可以从别处的设备发起，经过几个国家，终止于其存储具有不同复制路径的服务器。店面位置可以描述虚拟机，而其账单数据、控制台元数据、滥用日志和备份位于其他系统中。支持工程师可以从更远的管辖区访问工作负载。第三方面板可以在所订购设施之外处理凭据。

因此，买家需要按数据类别的数据位置计划。至少应包括客户内容、附加卷、快照、备份、对象存储、网络流数据、控制台日志、支持附件、身份记录、账单记录、监控遥测、安全日志和已删除数据残留。对于每个类别，计划应确定主要位置、副本、支持访问位置、子处理器、保留时间、加密密钥控制和删除过程。“中国”、“香港”或“全球”过于粗糙。

这既是运营要求也是法律要求。中国网络数据安全管理条例自 2025 年起生效，要求相关处理者建立数据安全管理措施，包括加密、备份、访问控制和认证，同时处理安全事件并对处理的数据承担责任。个人信息保护法规定了关于个人信息、敏感信息和跨境提供的义务。修订后的网络安全法于 2026 年生效，强化了网络安全运行安全与责任。

这些法律不允许局外人从 ASN 页面宣布 Haruzakura 合规或不合规。适用的角色取决于客户、数据、服务、合同和访问路径。它们确实使模糊的位置语言代价高昂。如果买家无法确定谁在何处处理哪些数据，则无法自信地分类传输、设置保留、响应数据主体请求、调查事件或设计出口。

历史产品目录使其特别重要，因为它似乎结合了来自不同供应链的产品。Haruzakura VPS、虚拟主机账户和标有 UCloud 的轻量主机可能具有不同的基础设施所有者、面板、备份系统和合同条款。数据主权必须跟随实际的产品链。提供商应在上线前披露这些差异，而不是在支持案例暴露它们之后。

支持是一个劳动系统

8 月页面将支持作为报价的核心。它宣传一对一售后服务、24x7工单投递、在线客服、专业技术支持、免费技术支持和重复的7*24可用性。对于小型提供商，本地语言协助和灵活的人工干预可能是购买的最强理由。它也可能成为最大的隐藏不确定性。

可用性表述不定义劳动。一个队列可以全天候接受工单而工程师只在有限时间工作。一个人可以同时处理销售、滥用、网络和系统运营，直到两个事件碰撞。在线聊天可以解答账户问题，但无权更改路由或恢复存储。“一对一”可能意味着指定联系人、轮换账户或只是直接聊天。公开页面没有提供人员配置模型、严重性矩阵、首次响应目标、恢复目标或升级树。

APNIC 联系表面不应与客户支持混淆。经过验证的事件响应邮箱是良好的资源管理。其目的是接收网络滥用和安全报告，而不是保证对失败的备份或锁定的控制台做出响应。域名在 2026 年 7 月缺少 MX 答案使得识别当前商业渠道更加重要。

支持计划应指明所涵盖的语言、时间和时区；区分首次响应与诊断、解决、恢复和最终解决；根据业务影响定义严重性；并说明客户在门户不可用时如何升级。应确定谁可以执行账户恢复、路由更改、虚拟机监视器工作、存储恢复和设施远程处理。维护通知、紧急更改和安全事件需要单独承诺。同样，滥用投诉可能导致暂停，需要不同的证据链。

客户应在关键迁移之前测试系统。在正常办公时间之外提交一个常规技术问题。请求可追溯的升级。执行授权的恢复演练。验证员工在重置管理员账户前进行的身份检查。请求示例事件通知和事后报告。结果不仅仅是响应时间分数；它揭示了提供商是否拥有能够承受压力的角色、交接和记录。

本地支持劳动也影响价格。较低的月度服务器费用可能与高客户方监督并存：翻译工单、重复诊断、监控服务健康、检查手动更改以及通过个人联系人升级。好的支持减少这种负担。不透明的支持将其转移给买方。因此，相关的商业指标不是“工单 24/7 可用”，而是每个接受的变更或解决的事件所需的客户努力分钟数，以及重复事件和稳定恢复的时间。

控制面板既集中便利也集中风险

历史控制表面包含了托管服务中一些最重要的操作：电源操作、密码重置、操作系统重装、远程 VNC、备份和快照管理以及资源变更。这些功能取代了人工劳动，可以缩短恢复时间。它们也集中了权限。

被盗的控制台账户可能比泄露的客户密码更具破坏性。攻击者可以重置凭据、附加恢复介质、重装系统、删除快照或查看暴露机密的控制台。错误的自动化作业可能针对错误的客户资源。拥有广泛覆盖权限的支持工作人员可以绕过正常批准。安全问题不在于控制面板是否存在；而在于身份、策略和证据是否围绕着每个强大操作。

买家应预期多因素认证、会话控制、角色分离、限定范围的支持访问、对破坏性操作的重新认证、不可变或受保护的审计事件以及敏感变更通知。密码重置和账户恢复应使用攻击者不易重定向的已验证渠道。如果提供 API 令牌，则需要范围、过期和轮换。重装和快照删除需要明确警告和可行的可恢复状态。控制台访问应记录操作者、目标、时间、来源和结果。

NIST 当前的事件响应指南将准备、检测、响应、恢复和改进视为风险管理的一部分，而不是妥协后的帮助台事件。应用于小型云提供商，这意味着面板、网络、支持台和客户必须共享一个事件模型。谁检测可疑账户恢复？谁可以在不销毁证据的情况下隔离实例？如果租户被重装，哪些日志会保留？客户何时被通知？误报如何撤销？

存档页面还提供 DDoS 保护（某些产品或作为附加）。该表述不揭示受保护协议、自动阈值、清洗位置、干净流量容量、空路由策略、误报处理或客户控制。买家应询问确切受保护路径和测试程序。重要的结果不是名义缓解数字，而是合法流量是否保持可用、警报是否到达、支持能否解释操作以及服务是否恢复而不会造成隐藏配置漂移。

RPKI 验证路由是这个更广泛系统中的一项积极控制。它有助于授权前缀来源。它应该与前缀监控、路由过滤、变更批准、访问日志、事件通信和恢复并存。将有效的 ROA 视为整体安全的证据会忽略账户、面板、客户、存储、支持和依赖关系中远更大的攻击面。

备份声明仅在恢复时才有价值

8 月页面提到了月度备份、备份和快照以及免费技术支持。这些是有吸引力的功能，因为低成本主机可能在客户必须重建服务器时变得昂贵。然而，“备份”是基础设施购买中最不具信息量的词语之一，除非提供商定义对象、计划、边界和恢复结果。

“月度”可能描述提供商的节奏、包含的层级或营销摘要。它没有说明备份是否应用一致、加密、不可变、异地、跨故障域复制或在取消后保留。快照可以完美保存损坏的文件系统或泄露的凭据。存储在相同账户和路由后面的备份可以随它所救援的服务一起消失。

NIST 的应急计划指南将恢复与业务影响分析、预防控制、策略、文档化计划、测试、培训和维护联系起来。实际转换是与工作负载相关的恢复目标。买家应定义数据丢失容忍度、恢复所需时间、必须首先返回的依赖关系以及谁有权调用该计划。

应向 Haruzakura 询问备份位置、故障域分离、加密和密钥所有权、保留期、恢复费用、预期恢复时间、删除策略以及近期测试的证据。客户应恢复到隔离环境并验证内容、权限、启动状态、网络配置和应用程序完整性。成功的作业条目不够。当服务可用且可信时，恢复才算结束。

退出是最终的恢复场景。客户能否以文档化的格式导出磁盘镜像、快照、数据库、DNS 数据、防火墙规则和审计历史？出口速率是否受限或收费？提供商在关闭后保留副本多长时间？能否发出删除确认？如果地址依赖提供商，迁移期间哪些配置必须更改？非便携式 IPv6 委派使最后一个问题具体化：客户应假定提供商地址不随他们移动，除非合同和路由设计明确另有说明。

小型提供商无需发布敏感架构即可回答这些问题。一个简洁的服务计划、一个示例恢复结果和一个经过测试的导出足以将模糊功能转化为证据。没有这些，买家应保持独立备份并从第一个月开始演练迁移。

廉价计算可能产生昂贵监督

旧价格引人注目：虚拟主机从 2.40 元起，VPS 从 15 元起，标有 UCloud 的轻量主机从 34 元起。它们是历史价格，不是当前报价，但它们揭示了可能的商业吸引力。对于爱好项目、临时开发环境和一次性服务，低成本进入可以证明较窄的证据基础合理。

当工作负载承载客户数据、收入、监管职责或硬性恢复截止日期时，决策就会改变。月度费用旁边是集成、迁移、监控、安全审查、双语支持、法律分析、备份存储和员工时间。买家可能节省计算费用，同时支付工程师验证每次更改、维护外部状态检查、保留独立备份以及通过未定义的升级路径追查事件的费用。

最佳比较单位是受支持的工作负载，而不是虚拟机。为实例、存储、流量、地址、保护、备份、恢复、支持层级、数据导出和预期客户劳动定价。如果单条可见路由不足，添加第二提供商成本。如果面板使用专有镜像格式，添加迁移成本。如果服务积分、通知义务和删除条款缺失，添加风险准备金。

小型提供商仍然可以在这种比较中胜出。他们可能提供灵敏的本地帮助、灵活的配置、更少的官僚作风和使实验成为可能的价格。所需证据是相称的。临时服务器不需要银行那样的治理。但买家应提前声明可接受的故障模式。如果服务消失一天，如果支持无法联系，如果快照失败或提供商关系结束，哪些工作和数据面临风险？

Haruzakura 的公开足迹不支持关于可靠性、客户数量或价值的有测量声明。它支持一个尽职调查假设：存在一个低成本的中国托管报价；后来的网络身份仍然可见；当前商业表面难以检查。因此，举证责任在于当前的卖方，在买家将历史价格视为便宜货之前缩小证据差距。

实际证据测试

以下问题将公开空白转化为验收计划。它们特意足够具体，以产生文档、配置、演示或测量结果。

这个表格不是要求公开披露每个敏感细节。大多数证明可以在保密协议下共享或在试用中演示。买家也不应接受一摞政策而不测试控制措施。一份当前的法律文件仍然可以命名错误的服务；架构图可以省略支持渠道；备份报告可以记录作业成功而没有恢复。

最有力的评估结合了文档、观察和演练。解析服务端点。配置并删除一个可丢弃租户。检查审计历史。在正常和困难时间提交工单。恢复备份。模拟主要管理员丢失。导出工作负载。要求提供商解释路由变更以及可见的 AS139317 依赖。证据应在这些活动中一致。

结果应针对工作负载的实际影响进行评分。如果价格和退出路径合适，可丢弃测试环境中的失败可能可以接受。在身份服务或客户数据库中的相同失败则不可接受。当采购对不确定性定价而不是假装其不存在时，采购变得更加理性。

运营结论

Haruzakura Cloud 比其薄弱的现今网络表面所暗示的拥有更多实质内容。历史店面将名称与一个中国的商业报价和更正式的中国公司名称联系起来。APNIC 后来将英文名称与一个可归属的组织、ASN 和 IPv6 块联系起来。公共收集器显示路由广泛传播，RPKI 显示来源已授权。这些是有意义的证据。

它们与云购买所暗示的保证还有差距。公共路由在观察的来源是纯 IPv6，依赖一家可见提供商，并且与当前的产品公共端点没有连接。旧的位置、支持、备份、DDoS 和硬件陈述没有相应的公共测量或当前合同。后来的网站捕获受到通用模板材料的污染，无法支持客户或使用声明。当前顶级域名没有暴露买家期望用于验证的普通 Web 和入站邮件路由。

这留下了一个有条件判断。如果当前运营商能够证明身份链、演示服务、解释供应商层、通过支持和恢复测试并为客户提供干净退出，那么 Haruzakura 可能适合有限、可逆的工作负载。可见的 ASN 和有效 ROA 是评估的积极输入。它们不能替代评估本身。

对于关键工作负载，证据门槛应更高。在迁移之前要求当前服务和数据位置计划、明确的事件和支持职责、经过测试的恢复、独立监控、路由依赖计划和导出权。保留外部备份和转向其他提供商的路径。将低价格视为模型中的一行，而不是结论。

更广泛的教训很简单。一个云名称可以同时指代品牌、卖家、法律实体、控制面板、一套上游产品和自治系统。运营保证仅当这些角色被可见化且责任在它们之间的交接中存活时才开始。Haruzakura 的中国公开记录为买家提供了一个可信的起点。它还没有允许停止。