看得见路由，看不见设施路径：AS60077 勾勒出的 Cloud.ir 证据边界

Summary

截至本次取证时点，RIPE RDAP 与 RIPEstat 都支持 AS60077 正在运行：它宣告 18 个 IPv4 前缀、合计 14,080 个 IPv4 地址，并被 325 个 RIS IPv4 观察点中的 324 个看到。这个结果证明路由面的现实存在，却不等于证明客户流量、物理容量或服务可用性。
同一份公开路由视图只观察到 AS43754 这一个邻居；PeeringDB 对 AS60077 的记录则显示零个公开交换点和零个公开设施关联。两者都不能证明现实中不存在其他链路或设施，但也没有为独立上游冗余、机房分布或故障切换提供公开证据。
Cloud.ir 的官网、服务站点地图与产品页面显示了持续维护的客户服务面，范围包括云服务器、VPS、云数据中心、云交换、域名管理、CDN 与云存储；然而，资料没有把每项产品逐一映射到 AS60077、某座设施或一组可核验的容量指标。
Cloud.ir 的 SLA 对普通运行条件下的网络与云服务器可用性作出承诺，同时列出维护、关键补丁、DoS、客户配置、不可抗力及法律或安全命令等多类排除项。公开材料因此更能说明责任边界，而不能证明具体的恢复时间、数据恢复点或端到端业务连续性。

云服务研究最容易犯的错误，是把不同层次的证据压缩成一句“该公司拥有云基础设施”。域名可访问、产品页面存在、自治系统正在宣告地址、前缀通过 RPKI 验证、机房具备多路供电、业务可以跨站点恢复，这些命题并不处在同一条证据链上。前四项可以分别从网站、注册数据库与路由观测中得到不同程度的支持；后两项则需要设施、容量、运维和故障演练材料，不能由一个活跃的 ASN 反向推出。

AS60077 的价值，正是在于它让研究者看见了 Cloud.ir 相关网络身份的一部分。它把抽象的云品牌落到可检查的号码资源、地址前缀、路由邻接和验证状态上。与此同时，它也划出了一条清晰的停止线：公共互联网能看到哪些地址由谁发出，却通常看不到这些地址最终落在哪一排设备、经过哪一条城域线路、由多少个独立运营商承载，更看不到一次故障后客户工作负载如何恢复。

注册身份先回答“谁在宣告”

RIPE RDAP 把 AS60077 列为活跃自治系统，名称为 AT-CLOUD，登记组织为 ORG-ADA42-RIPE / Asre Dadeha Asiatech。记录显示其注册日期为 2022 年 6 月 27 日，最近一次变更日期为 2026 年 1 月 23 日。RIPEstat 的 AS 概览在 2026 年 7 月 20 日查询时把持有者写作“AT-CLOUD Asre Dadeha Asiatech”，并返回 announced=true。这两类记录相互补充：前者给出资源注册身份，后者确认在观测时点确有路由宣告。

这是一条有分量的身份链。它意味着 AS60077 不是只出现在营销页面上的编号，也不是一条已经沉寂、仅留在注册库中的历史记录。登记名称、组织标识与当前宣告状态能够在公共数据中对上。对于需要判断网络主体是否真实运行的客户、同行或研究者而言，这比单纯看到 cloud.ir 网站在线更接近底层控制面。

但注册身份仍有边界。自治系统记录说明谁被登记为号码资源的管理主体，不会自动说明设备产权、机柜位置、线路合同、值班团队、客户规模或每项 Cloud.ir 产品的交付路径。注册日期也不等于服务连续运行时间；最近变更日期只说明登记资料发生过更新，不能据此推断网络架构在那一天完成了升级。把这些字段按其原本含义使用，才能避免用准确数据支撑错误结论。

Cloud.ir 的官方页面又提供了另一层联系：运营方把服务描述为建立在伊朗境内的 Asiatech 数据中心之上，并以 Asre Dadeha Asiatech 的网络与服务身份面向客户。这让品牌、企业与网络号码之间具备合理关联，却依然不是逐项产品路径证明。公开资料没有给出一张清单，说明哪个云服务器套餐、哪个 VPS 网段、哪一项 CDN 或存储服务必然从 AS60077 发出。因此，本文讨论的是可见的相关控制面，不把 AS60077 写成 Cloud.ir 全部服务的唯一或完整网络边界。

十八个 IPv4 前缀构成了清楚但有限的外部轮廓

RIPEstat 的 routing-status 快照为 AS60077 记录了 18 个 IPv4 前缀和 14,080 个 IPv4 地址。可见宣告横跨 78.110.112.0/21，一组以 85.198 开头的 /22、/23 与 /24 网段，以及从 193.151.128.0/22 延伸到多个 193.151 网段的地址块。193.151.156.0/24 至 193.151.159.0/24 也在当时的活跃列表中。数字和前缀共同给出一个比“提供云服务”更具体的网络轮廓。

可见性同样广泛。在这次快照中，325 个 RIS IPv4 对等观察点里有 324 个能够看到 AS60077，最后记录到的前缀为 193.151.156.0/24，时间是 2026 年 7 月 20 日 16:00。广泛的观察点覆盖说明这些路由不是只在一个局部采集点短暂出现，而是在公共 BGP 视图中具有很高的传播可见度。bgp.tools 也把 AS60077 概括为活跃网络，记录 18 个起源 IPv4 前缀，并把 Server Hosting 列入标签。

然而，“很多观察点看得见”只回答了传播问题。RIS 观察点看到的是控制平面中的路由通告，不是客户请求成功率，也不是网络在高峰时段的吞吐、时延和丢包。14,080 个 IPv4 地址代表可见起源空间的地址规模，不代表其中每个地址都已分配给客户，更不代表可售计算、存储或带宽容量。相同的前缀数量可以对应完全不同的设备密度、超售策略和业务负载。

路由快照也不是永久保证。前缀可能被更具体地宣告、聚合、撤回，或在不同采集时间呈现不同状态。本文引用的数量和可见率应理解为 2026 年 7 月 20 日附近的公共观测结果，而不是一份面向未来的网络承诺。要把它用于持续监测，就需要重复采样，观察前缀集合、邻居、可见率和验证状态是否发生变化，而不能把一次快照固化为长期架构图。

IPv6 的正确表述是“当前未见起源”，不是“没有服务”

同一份 routing-status 数据显示，AS60077 当时没有可见的起源 IPv6 前缀：321 个 RIS IPv6 观察点中没有一个看到它。announced-prefixes 数据里确实出现过 2a05:1a30::/34，但只对应 2026 年 7 月 13 日的一个时间点，并未在当前 routing-status 中构成持续可见的 IPv6 起源空间。bgp.tools 的摘要也把起源 IPv6 前缀数列为零。

这些记录支持一个谨慎结论：在本次来源包所覆盖的观测窗口内，没有证据证明 AS60077 正在持续起源 IPv6 前缀。它们不支持“Cloud.ir 不提供任何 IPv6 服务”这种更大的判断。服务可以通过其他自治系统、代理、隧道或第三方交付；某些 IPv6 能力也可能不暴露为 AS60077 的直接起源。来源包没有检验这些可能性，因此不能替运营方作肯定或否定说明。

对客户而言，这个差异并非文字游戏。若工作负载需要原生双栈、固定 IPv6 地址、IPv6 入站过滤、反向解析或跨运营商可达性，就应要求产品级证据：分配策略、实际测试地址、起源 ASN、路由对象、故障切换方式和 SLA 适用范围。仅凭一次短暂出现的 /34 不能把 IPv6 写进已验证能力清单；仅凭当前为零，也不能把所有潜在交付路径一笔勾销。

RPKI 与地址登记加强了路由归属，却没有照亮机房

在 193.151.156.0/24 这个具体样本上，RIPEstat 的 RPKI 验证结果为 valid，验证用 ROA 覆盖了起源 AS60077。这说明该前缀与当前起源的组合符合可见的路由起源授权。它是重要的路由卫生信号：研究者不必只相信 BGP 中“有人这样宣告”，还可以检查资源持有者发布的授权是否允许这一宣告。

不过，一个样本有效不等于对全部 18 个前缀作出整体担保。来源包明确验证的是 AS60077 与 193.151.156.0/24 的组合。除非对每个前缀逐一核验，本文不能把样本结果扩写成“整个网络所有路由都通过 RPKI 验证”。同样，RPKI 验证的是起源授权，不验证路径长度、上游独立性、机房安全、硬件冗余或应用可用性。

RIPE RDAP 对该地址段的记录提供了进一步的行政背景。193.151.156.0/24 落在名为 IR-AT-20210316 的活跃 assigned PA 范围内，覆盖 193.151.128.0 至 193.151.158.255，国家代码为 IR，并列出 ASIATECH-MNT 与 Asiatech NOC 的管理和技术联系。这使号码资源、维护者与运营联系能够相互印证。它仍然没有给出服务器所在建筑、机柜归属或光纤入口，因此只能作为资源控制证据，而不是设施证明。

路由一致性数据还展示了“登记意图”与“实际观测”的差别。AS60077 在 BGP 中可见的 IPv4 前缀也出现在 RIPE Whois；与此同时，Whois 中还存在若干更宽或组成性的范围，并未在当前 BGP 视图中出现。AS43754 同时出现在 BGP 与 Whois 的导入、导出关系中，而 AS212895 只出现在 Whois 导入资料里，没有出现在本次 BGP 观测中。配置文本可以记录允许或计划中的关系，观测数据则说明当时实际看见了什么。两者不一致并不必然意味着错误，却要求分析者降低推断强度。

唯一可见邻居揭示依赖，却不能独自定义全部拓扑

RIPEstat 的邻居数据把 AS43754 列为 AS60077 唯一观察到的邻居；routing-status 也报告一个邻居。RIPEstat 与 RIPE RDAP 都把 AS43754 识别为活跃自治系统，持有者是 Asiatech Data Transmission company。bgp.tools 则把它概括为 AS60077 的上游。不同公开来源在这一点上形成了较一致的图景：AS60077 的外部可见路径至少在本次观测里集中指向同一 Asiatech 体系内的 AS43754。

这条证据不能被包装成“独立冗余”。独立上游通常意味着故障域、商业控制和路由路径并非全部落在同一运营体系内，而来源包只观察到 AS43754。资料没有证明第二个独立运营商，也没有给出不同物理入口、不同城域管道或跨设施切换的测试结果。AS212895 出现在 Whois 导入资料而未出现在 BGP，不能被当作当时正在承载流量的备用上游。

反过来，唯一可见邻居也不等于证明 AS60077 在物理上只有一条线路。一个上游 ASN 可以通过多条电路、多个路由器或多个地点与客户互联；路由采集也可能看不到私有互联、备份链路或不向观察点传播的关系。公共数据没有足够粒度判断这些情况。严谨的说法应是：公开 BGP 证据没有展示独立多上游冗余，而不是宣判现实中绝对不存在任何冗余。

这一差别直接决定尽调问题。若买方关心上游故障，应该询问 AS60077 与 AS43754 之间有多少物理连接、是否跨不同设施和进线、备用链路如何触发、路由撤回需要多长时间，以及第二条路径是否仍依赖同一电力、传输或运营团队。若运营方主张独立承载，还需要能把“两个会话”“两条光纤”和“两个独立故障域”区分开的证据。BGP 邻居数本身无法替代这些回答。

PeeringDB 的零披露是一处证据空白，而不是否定性证明

PeeringDB 对 ASN 60077 的网络记录名称为 Asre Dadeha Asiatech，状态字段 status=ok、rir_status=ok。同一记录的 ix_count=0、fac_count=0，没有网站、looking glass、route server、互联政策链接，也没有披露流量等级或网络范围。对研究者来说，这个页面确认了一个当前网络条目，却几乎没有提供可用于绘制互联与设施地图的细节。

不能因为 fac_count=0 就断言 AS60077 没有机房，也不能因为 ix_count=0 就断言它不与任何网络互联。PeeringDB 的资料依赖网络参与者维护，缺失可能代表未填写、未更新、不公开或不适用。它不是全球设施和链路的强制登记册，更不是法律控制、客户流量或服务质量的证明系统。

但缺失仍然有分析意义。既然公开记录没有列出设施、交换点、政策或观察工具，外部读者便无法借此独立核对 Cloud.ir 所称数据中心与 AS60077 路由面的对应关系。路由可以非常可见，承载路由的物理路径却仍不可见。这里的结论不是“基础设施不存在”，而是“基础设施路径未被这组公开材料证明”。

这种证据空白也限制了地理判断。地址登记中的国家代码 IR、Cloud.ir 关于伊朗数据中心的自述，以及 PeeringDB 中缺少设施关联，不能组合成一张精确机房地图。国家代码是资源登记属性，不是服务器实时定位；运营方自述说明其服务叙事与部署主张；零设施记录则表示没有额外的公开映射。三者必须分别保留，不能通过相互拼接制造来源并未提供的精度。

客户服务面真实存在，但产品目录不是网络拓扑图

Cloud.ir 在本次检查中可通过 HTTPS 访问。其首页与服务站点地图列出云服务器、VPS、云数据中心、云交换、云域名管理、CDN 和云存储等服务页面，核心页面的 lastmod 时间分布在 2025 至 2026 年。官方关于页与服务页还称，云服务始于伊朗历 1399 年，产品数量超过 20 项，并运行在伊朗的 Asiatech 数据中心之上。

这些材料足以支持“存在一个持续维护、面向客户的服务表面”。它们比一张多年未更新的宣传页更能说明运营方仍在组织产品、说明功能并提供联系入口。联系页面也保留了销售与支持界面。可是，页面在线和站点地图更新不能证明订单量、活跃客户数、资源余量或后台系统状态；lastmod 更不是设施维护日志。

产品目录与网络控制面之间也没有一一对应关系。一个云服务器页面可能描述计算实例，但不告诉读者实例地址是否全部来自 AS60077；CDN 可能使用多个边缘或合作网络；域名管理服务甚至不必由同一数据平面承载。来源包把企业身份、Cloud.ir 服务面与 AS60077 的路由记录联系起来，却没有为每个产品提供地址样本、流量路径或起源 ASN 清单。因此，不能写成“Cloud.ir 的所有服务均由 AS60077 交付”。

这种映射缺口会影响风险归因。假如一项服务确实使用 AS60077，AS43754 的可见邻接和当前无持续 IPv6 起源便与该服务更直接相关；假如另一项服务依赖第三方 CDN、其他 ASN 或不同设施，风险面可能完全不同。在没有产品级映射前，把公司层面的路由证据平均分配给每个产品，只会制造一种虚假的统一架构。

买方需要的是能够缩小这段距离的材料：实例分配的地址范围、产品对应的起源 ASN、区域与设施代码、跨区复制路径、公共或私有出口说明，以及变更时的通知机制。运营方不必公开会增加安全风险的细节，但至少应给出足以验证故障域是否独立的抽象结构。否则，产品数量越多，外部观察者越难判断它们究竟共享哪些底层依赖。

标准与数据中心描述仍属于运营方自述

Cloud.ir 的页面使用了 ISO27001、TIA-942 以及 Tier 2/3 风格的数据中心描述，也谈到高可用、连接连续性和数据持久性。这些说法可以准确记录为运营方公开主张，因为它们确实出现在官方服务材料中。来源包却没有包含可独立核验的证书、认证范围、审计机构、有效期、具体设施名单、供电与制冷拓扑、发电机运行时长或客户可用容量数据。

因此，本文既不把这些说法判为虚假，也不把它们升级为已独立证实的事实。标准名称尤其需要范围信息：信息安全管理体系可能覆盖特定组织或流程，不等同于每座设施的物理等级；数据中心等级描述也需要明确评估对象、版本和认证主体。没有这些附件，只能说运营方采用了相应表述，不能说本次取证已经验证其认证状态。

容量同样不能由产品页反推。页面可以展示多种实例、存储和网络产品，却不披露当前可售 CPU、内存、存储、出口带宽或各站点余量。地址规模也无法替代这些指标：IPv4 地址可以被保留、复用、做 NAT、分配给基础设施或尚未启用。对“云数据中心”的研究若停在地址数量，很容易把号码资源误当成计算与电力资源。

设施路径还需要回答“服务从何处出发，又在哪里终止”。即便服务确实运行于 Asiatech 数据中心，也仍需区分是单站点还是多站点、各站点是否属于同一城市故障域、出口是否最终汇聚到同一上游、备份是否与主数据共享电力或传输依赖。本次来源没有这些答案，因而不能以 Tier 2/3 风格措辞填补。

SLA 比营销页更清楚地划出了责任边界

Cloud.ir 的 SLA 页面把可用性保证限定在普通运行条件下的网络和云服务器可用性，同时列出多类排除情形：客户软件、操作系统与配置问题，DoS 攻击，服务暂停，计划维护，关键补丁，不可抗力，客户设备故障，客户要求的停机，未付款，以及法律或安全命令。排除项并不意味着运营方在这些事件中必然不采取行动，但它们说明哪些情形可能不落入常规可用性承诺。

这使 SLA 成为理解服务经济关系的关键材料。营销页面强调可获得的能力，SLA 则说明发生问题时哪些责任被纳入计算，哪些风险仍由客户承担或需要另行约定。一个系统可以在合同定义内满足网络可用性，同时因为客户操作系统、应用配置或遭受 DoS 而无法提供业务功能。对买方来说，“网络在线”“虚拟机在线”和“业务可用”必须分别衡量。

维护与关键补丁排除项尤其提醒读者，不应把宣传中的连续性表述直接当作全年每一分钟都受同一补偿规则保护。来源包没有给出维护通知提前量、最长维护窗口、紧急变更流程或补偿计算细节的完整操作证据。它也没有证明维护期间是否存在跨设施迁移。因而可以确认合同边界存在，却不能从边界反推出恢复机制。

DoS、不可抗力和法律或安全命令则把外部事件带入服务模型。AS60077 的广泛路由可见性不会自动证明攻击缓解能力；有效的 RPKI 起源授权也不能阻止容量耗尽或应用层攻击。类似地，线路在 BGP 中仍然可见，不代表某个客户实例未被暂停或因法律命令受到限制。控制平面的“可达”与合同、资源和应用层面的“可用”并非同义词。

最重要的缺口是恢复行为。当前材料没有证明恢复时间目标、恢复点目标、备份保存位置、跨站复制一致性、故障演练频率或客户数据恢复流程。SLA 说明部分停机何时被排除，并不等同于灾难恢复手册。若业务需要明确的 RTO 或 RPO，客户应取得产品和区域层面的书面条款，而不是从“高可用”三个字中自行推导。

公开证据可以分成三层，而不必强求一个总分

对 CLOUD Asre Dadeha Asiatech 的判断，更适合采用证据分层，而不是给出笼统的“可信”或“不可信”标签。

证据层	本次材料支持的结论	本次材料不支持的延伸
已独立观察	AS60077 登记为活跃并在查询时宣告；18 个 IPv4 前缀具有广泛 RIS 可见性；`193.151.156.0/24` 样本通过 RPKI 验证；只观察到 AS43754 一个邻居	客户流量规模、端到端性能、物理线路数量、全部前缀的 RPKI 状态
运营方公开面	Cloud.ir 网站和多项服务页面在线；运营方描述了产品范围、伊朗境内 Asiatech 数据中心依赖以及 SLA 排除项	活跃客户数、可售容量、每项产品到 AS60077 的映射、标准认证的独立有效性
尚未解决	PeeringDB 未披露设施或交换点；当前没有持续可见的 AS60077 IPv6 起源；没有独立多上游或恢复资料	不能据此断言现实中没有设施、IPv6、备用链路或恢复能力，只能说公开证据未证明

这种分层有两个好处。第一，它保留了已经得到验证的运营事实，不会因为设施资料不完整就否定一个确实活跃的网络。第二，它阻止分析者用强证据替弱命题背书。RPKI 有效是强路由证据，却是零设施证据；官网在线是强服务入口证据，却是弱容量证据；SLA 排除项是强合同边界证据，却不能单独说明事故中的实际处置质量。

证据分层也允许后续更新。当 AS60077 增加新的可见邻居、持续起源 IPv6、在 PeeringDB 披露设施，或 Cloud.ir 发布可核验认证和恢复文件时，研究者可以只升级对应一层，而不必重写全部判断。相反，如果前缀撤回或页面停止维护，也应记录时点变化，而不是把 2026 年 7 月的快照继续当作当前事实。

把证据放进故障链，才能看见每种记录的盲区

上述限制可以通过几个假设情景看得更清楚。它们不是对 Cloud.ir 已发生事故的描述，而是用来检验公开证据能够回答哪些问题。

第一种情景是客户虚拟机或存储服务发生故障，但 AS60077 的 18 个 IPv4 前缀仍然正常宣告。外部路由观察点可能继续看到完整路径，RPKI 结果也仍然有效，因为故障发生在路由起源之后的计算、存储、虚拟化或内部交换层。此时，324 个 RIS 观察点看见网络，并不能帮助客户判断某台实例能否启动、某个卷能否挂载，或某个控制台能否执行恢复操作。

第二种情景是某座设施或一条接入线路出现问题，而边界路由器没有立即撤回前缀。BGP 可见性可能在一段时间内保持，流量却无法到达实际工作负载；也可能出现相反情况，即运营方迅速把路由切换到备用路径，外部只看到路径属性变化，却不知道背后经历了怎样的物理故障。没有设施映射、健康检查逻辑和切换记录，控制平面只能显示结果的一部分。

第三种情景涉及上游。公开视图里只有 AS43754。如果这一可见关系发生波动，研究者可以观察前缀是否撤回、路径是否改变、可见率是否下降，却无法预先知道是否存在未被当前采集看到的备用会话或物理电路。即使路径恢复，也不能仅凭恢复速度判断它经过了独立运营商，还是同一 Asiatech 体系内的另一条连接。要回答独立性问题，仍需运营方提供故障域层面的说明。

第四种情景发生在合同边界而非网络边界。客户配置错误、操作系统失效、DoS、计划维护、关键补丁、欠费或法律与安全命令，都可能使服务不可用或受限，同时不必引起 AS60077 路由变化。Cloud.ir 的 SLA 把这些情形列入排除范围，说明路由监测无法代替账户、应用、合规和维护监测。客户若只盯着 BGP，就可能错过对自身业务更直接的中断原因。

这四种情景共同说明，网络资源证据适合回答“谁在何时宣告什么”，不适合独自回答“客户为何不可用、多久恢复、损失由谁承担”。设施资料回答物理承载，产品遥测回答服务状态，SLA 回答责任与补偿边界，恢复演练回答事故后的动作。只有把这些记录放在同一条故障链上，才可能从一个可见 ASN 走到一个可审计的云服务。

对于研究者，这也意味着不能把“没有看到”一概当成“没有”。没有看到第二个 BGP 邻居，表示当前公开观测没有提供第二个邻居；没有看到 PeeringDB 设施，表示该目录没有披露设施；没有看到持续 IPv6 起源，表示 AS60077 当前没有可见的持续起源。每项缺失都对应特定观测工具的边界，不能越界成为关于整个现实系统的绝对判断。

客户可用容量需要一套不同于地址数量的证据

本次资料给出的 14,080 个 IPv4 地址很具体，因而也最容易造成一种错误的精确感。地址是编号资源，计算容量则由处理器、内存、存储、虚拟化调度、电力、制冷与运维策略共同决定。一个拥有大量地址的网络可能只向少量客户提供高密度服务，也可能通过共享地址承载大量实例；两者无法从前缀表中区分。

“已安装容量”“可销售容量”和“故障后仍可使用的容量”也不是同一个数字。已安装设备可能已有预留或被现有客户占用；可销售资源可能受到电力、存储性能或上游带宽约束；为了在设备或站点故障时继续运行，运营方还需要保留不参与日常销售的余量。Cloud.ir 的产品目录说明它提供哪些类别，却没有给出这些容量层次。

网络容量同样不能由前缀规模代替。前缀可从全球路由表中广泛看到，只说明到达路径被传播，不说明出口端口速率、峰值利用率、拥塞管理、DDoS 清洗能力或客户带宽承诺。PeeringDB 没有披露流量等级，来源包也没有独立性能测量。因此，本文不能把“18 个前缀”转换成任何吞吐或客户规模估计。

存储与恢复容量还多一层约束。数据副本如果位于同一设施、同一电力域或同一控制面，名义上的副本数量未必带来站点级韧性。反之，跨站复制会消耗网络、存储和一致性预算，能够承载正常负载的系统未必能在故障切换时承载全部工作负载。来源包没有备份位置、复制模式或恢复演练，因此不能评价这些能力。

运营方若要证明客户可用容量，并不一定需要公布敏感的设备清单。它可以按产品和区域提供可验证的最小指标：资源池是否跨故障域、预留余量的计算原则、容量告警阈值、典型扩容时间、出口承诺、存储性能范围，以及在单设备或单站点失效后仍维持的服务等级。第三方审计或带日期的演练摘要，也比没有范围说明的“高可用”更能降低不确定性。

对客户来说，容量尽调还应与自身负载模型相连。可水平扩展、能够从镜像重建的服务，对单实例恢复的依赖较低；状态密集型数据库、长期存档或低延迟业务则更需要明确的存储、复制和网络保证。同一家供应商可以适合前一种工作负载，而对后一种仍需要额外证据。研究文章不应把公司层面的一个判断强加给所有应用场景。

最低披露集可以提高透明度，而不必公开敏感拓扑

AS60077 当前的公开资料并非毫无价值，问题在于不同证据之间缺少桥梁。一个实用的最低披露集，可以在不公布精确机柜、设备地址或安全配置的前提下，把网络身份、产品和责任边界连接起来。

第一项是产品到网络资源的映射。运营方可以说明哪些服务主要使用 AS60077，哪些服务依赖其他 ASN 或第三方，并为测试提供有限的地址样本。若产品路径会随区域或服务层级变化，也应说明变化规则。这样，客户看到路由事件时才知道哪些工作负载可能相关。

第二项是上游与故障域声明。与其只写“冗余网络”，不如说明上游是否属于独立公司、连接是否跨不同物理进线、边界设备是否共享电力，以及最近一次切换演练覆盖了什么。公开摘要无需暴露线路编号，却可以回答 AS43754 之外是否存在真正独立的路径。本次资料没有这样的证明，所以独立冗余仍是开放问题。

第三项是设施范围说明。Cloud.ir 可以为每个服务区域给出经过抽象处理的设施数量、城市级位置、运营或租用关系、主要认证的适用范围与有效期。若引用 ISO27001、TIA-942 或 Tier 2/3 风格描述，应同时给出评估对象和证据边界。这样既能保护物理安全，也能避免读者把企业级认证误解为所有站点和产品的统一属性。

第四项是完整的路由卫生摘要。当前 193.151.156.0/24 样本通过 RPKI 验证，是积极证据；更有用的披露会说明全部活跃前缀的 ROA 覆盖、无效路由处置、过滤政策和变更流程。对于 IPv6，则应明确当前是未提供、试运行、通过其他 ASN 交付，还是计划部署，而不是让一个短暂出现的 2a05:1a30::/34 承担过多解释。

第五项是 SLA 与恢复附件。普通可用性、维护窗口、DoS 处置、备份、恢复、客户责任和法律限制应分别说明。若不同产品的 RTO、RPO 或补偿方式不同，就不应只用一份概括性页面覆盖全部服务。版本号、生效日期和历史变更记录能够让客户知道自己接受的是哪一组承诺。

第六项是可验证的运行记录。经过脱敏的事故复盘、定期切换演练摘要、状态历史和支持响应统计，可以展示系统在压力下如何工作。这类材料与营销页面的区别，在于它记录实际行为，而不仅是设计目标。来源包没有提供这些材料，本文因此只把它们列为缩小证据缺口的方向，不暗示运营方从未进行内部演练。

第七项是保持公共目录一致。RIPE 注册、RIPEstat 观测、PeeringDB 条目、官网产品说明与 SLA 若由不同团队维护，很容易出现时间和范围漂移。定期核对名称、联系渠道、前缀、邻居、设施披露和政策链接，可以减少外界将“未更新”误解为“没有”的概率。对一个以网络资源承载云服务的运营方而言，公开资料维护本身就是运营成熟度的一部分，但它仍不能替代底层能力验证。

四组时间戳不能被混成一个“当前状态”

本次来源中至少存在四种时间。AS60077 的注册记录有 2022 年的登记日期和 2026 年 1 月的最近变更日期；RIPEstat 的路由数据反映 2026 年 7 月 20 日附近的查询与观测；2a05:1a30::/34 只在 7 月 13 日留下一个时间点；Cloud.ir 服务站点地图的核心页面更新时间则分布在 2025 至 2026 年。每个日期描述的对象不同。

注册资料最近更新，不代表产品页面同日更新；产品页面更新，也不代表网络架构在同一时刻发生变化。路由快照足够新，可以支持观测时点的网络结论，却无法追溯 2022 年以来的连续运行。一次 IPv6 记录则可能是测试、短暂宣告或采集现象，来源不足以判定原因。把这些日期并排保留，比把它们压缩成“截至 2026 年都正常”更准确。

时间差还影响合同判断。SLA 页面在检查时可访问，但客户实际适用的可能是签约时版本、订单附件或单独约定。研究者可以描述公开页面内容，不能替代对具体合同的法律解释。采购团队应保存签约版本及后续变更通知，并把网络与产品监测时间线和合同时间线分开。

持续监测因此应采用不同频率。BGP 前缀、邻居和 RPKI 状态可以较高频率检查；PeeringDB 与注册资料适合在变更或定期审查时核对；产品页面、SLA 和认证材料则应在采购、续约与重大变更前复查。只有维持各自的时间轴，才能判断一个新差异是实际架构变化、公开资料延迟，还是观测窗口造成的假象。

托管经济的关键，在于谁承担不可见部分的成本

Cloud.ir 以超过 20 项产品构成一个宽广服务目录，这种产品化可以让客户用统一入口采购计算、存储、网络和域名相关能力。对运营方而言，复用底层平台与销售界面可能带来规模效率；对客户而言，统一服务面可以减少供应商管理成本。但来源没有证明这些产品实际共享何种基础设施，因此这里只能讨论经济机制，不能断言具体的内部资源池结构。

当设施、上游和恢复路径缺少公开映射时，验证成本会转移给买方。客户需要通过问卷、合同附件、试用测试、路由监测和故障演练来确定服务边界。价格较低的套餐可能仍适合可重建、可迁移的工作负载；关键业务则需要为独立备份、第二供应商、额外出口或应用层容灾付费。真正需要比较的不是产品名称，而是把未被供应商保证的风险重新纳入后的总成本。

SLA 排除项进一步决定风险如何分配。若客户软件、操作系统、配置、DoS 或维护不在普通可用性保证内，客户就需要投入自己的运维、缓解和连续性方案。这里不能简单说风险被“甩给”客户，因为具体责任仍取决于合同全文和事件事实；可以确认的是，单一可用率数字不足以覆盖这些场景。采购评估应把排除项逐条转化为控制措施和预算，而不是只比较百分比。

网络集中度也有经济后果。公开视图只显示 AS43754，一个同属 Asiatech 体系的上游身份。如果产品确实依赖这条可见路径，客户就需要评估同一运营体系内故障是否会同时影响接入、传输和云资源。若现实中存在多地点、多电路或第三方备用路径，运营方可以用适度脱敏的证明降低这种不确定性。没有证明时，买方只能为未知相关性保留更高的风险余量。

一份可执行的尽调清单应从证据缺口出发

第一，要求产品级网络映射。客户不一定需要设备级拓扑，但应知道所购云服务器、VPS、CDN 或存储服务使用哪些地址池与起源 ASN，是否经过 AS60077，以及不同区域是否共享 AS43754。测试地址和只读 looking glass 可以让客户自行验证，而不必完全依赖文字承诺。

第二，区分逻辑冗余与物理独立。两个 BGP 会话可能落在同一光缆，两条光缆可能进入同一建筑，两个站点也可能共用同一城域传输或运营团队。应询问线路运营商、进线、设施、电力和控制面的独立程度，并要求最近一次切换演练的日期、范围与结果。来源包没有这些事实，所以问题本身不能被写成既成能力。

第三，单独核查 IPv6。当前证据显示 AS60077 没有持续可见的起源 IPv6，而 2a05:1a30::/34 只出现于一个时间点。需要 IPv6 的客户应测试实际产品，不应把品牌层面的任何概括替代地址分配和路由验证。若 IPv6 经由其他 ASN 提供，也应明确其上游、过滤和故障边界。

第四，把容量问题从地址问题中拆开。应分别询问计算、内存、存储 IOPS、出口带宽、超售政策、扩容交付时间和区域余量。18 个前缀与 14,080 个地址能够说明路由规模，却无法回答一场大客户迁移后还剩多少可用资源，也不能说明网络拥塞时的优先级。

第五，把恢复承诺写成可测量条款。高可用需要明确故障检测、重启、迁移和数据复制机制；灾难恢复需要明确 RTO、RPO、备份隔离与恢复测试；业务连续性还需要覆盖身份、控制面、支持和法律限制。Cloud.ir 的 SLA 排除项可以作为谈判起点，但不能替代这些产品级指标。

第六，保存证据时点。RIPEstat、RIPE RDAP、PeeringDB、bgp.tools 和官网内容都可能变化。采购前检查应记录查询时间、前缀集合、邻居、RPKI 状态、SLA 版本和产品页面版本。持续监测的价值，不仅在于发现网络是否下线，也在于发现披露和依赖是否发生结构性变化。

可见的网络，仍需要一条被证明的服务路径

AS60077 给出的并不是一片空白。公共记录把它连接到 AT-CLOUD、ORG-ADA42-RIPE 与 Asre Dadeha Asiatech；路由观测显示 18 个 IPv4 前缀具有广泛可见性；一个当前前缀样本拥有有效的 RPKI 起源授权；Cloud.ir 则展示了仍在维护的客户服务面与一份可读取的 SLA。把这些事实全部忽略，同样会低估该网络的现实运营基础。

但证据的丰富程度在到达设施层之前迅速下降。唯一观察到的邻居 AS43754 与 Asiatech Data Transmission company 相关，不能作为独立上游冗余证明；PeeringDB 的零设施、零交换点披露不能证明没有设施，却无法帮助核验设施路径；官方标准、容量与数据中心说法尚未在本次资料中获得独立支持；当前无可见 IPv6 起源，也不能扩大成“绝无 IPv6 服务”。

因此，最稳妥的结论不是给 Cloud.ir 贴上“可靠”或“不可靠”的标签，而是准确陈述已知边界：公开证据支持一个活跃的 IPv4 路由面、明确的资源身份和现实存在的客户服务入口；它不支持一条已经完全证明的机房路径、独立多上游、客户可用容量或恢复机制。对于普通工作负载，这种不确定性可以通过架构和合同管理；对于关键业务，它就是在采购之前必须补齐的证据。

云服务的抽象价值，在于让客户不必看到每一台设备。基础设施研究的价值，则在于确保抽象没有抹去责任、依赖和故障域。AS60077 已经让 Cloud.ir 的外部路由边界变得可见。下一步所缺的，不是更多产品名称，而是能够把这些路由可靠地连接到设施、容量、冗余与恢复承诺的证据。