摘要
- Cloud.ir 为 CLOUD Asre Dadeha Asiatech 提供了一个真实的零售界面：该网站提供云服务器、VPS 方案、云存储、CDN、云交换、云数据中心服务、客户面板、公布的价格和 SLA，其页脚声明网站属于 Asre Dadeha Asiatech。
- 物理锚点比产品语言更窄。Cloud.ir 表示其基础设施位于伊朗的 ASIATECH 数据中心，关于页面称 Cloud.ir 自伊朗历 1399 年开始运营，拥有超过 20 种云产品，但公开页面未明确标识每个客户工作负载背后的具体机架、城市布点、电源拓扑或恢复测试结果。
- 网络证据在控制平面层面很强。RIPE RDAP 将 AS60077 标识为 AT-CLOUD，属于 Asre Dadeha Asiatech，RIPEstat 在 2026 年 7 月 12 日显示 AS60077 公布了 18 个 IPv4 前缀和 14,080 个 IPv4 地址，cloud.ir 的 DNS 映射到 AS60077 前缀。同一 RIPE 视图显示 AS60077 有一个左侧邻居：AS43754，即 ASIATECH Asiatech Data Transmission company。
- 因此，购买问题不在于云产品是否存在，而在于客户能否在机架、上游、硬件库存或账户事件将虚拟服务器转变为物理依赖之前，验证放置、容量余量、独立路由、备份位置、支持升级、维护排除、计费连续性和退出权利。
店面公开，但基础设施承诺仍有层次
Cloud.ir 并非一个闲置的品牌页面。Cloud.ir 首页展示了云服务器、云数据中心服务、云交换、CDN、云存储、云域名管理、服务价格页面、支持页面和客户登录路径。同一页面还包含电话号码、电子邮件地址、德黑兰办公室地址以及页脚声明：网站的物质和知识产权属于 Asre Dadeha Asiatech。对本档案而言，这一点很重要，因为公司身份与一个实时服务界面相关联，而不仅仅是一个路由记录。
关于页面增加了服务历史。它表示 Cloud.ir 于伊朗历 1399 年开始运营，已成为伊朗领先的云服务提供商之一，拥有超过 20 种云产品。列出的产品组包括内容分发、云计算、云安全、云存储、云网络和云市场。这些声明是公司陈述，并非对容量的独立测量，但它们明确了基本的商业姿态：CLOUD Asre Dadeha Asiatech 向不想自己购买和运营物理基础设施的客户出售托管容量。
零售报价也足够具体以供检查。云服务器页面称，客户可以快速创建云服务器，按使用资源付费，更改资源，配置网络，添加或更改 IP 地址，监控资源和网络使用，使用云防火墙，并安排备份。同一页面描述了 Linux、Windows 和 MikroTik 服务器选项，并称云服务器客户可通过全天候工单提交获得支持。买家应将这些视为需要合同和测试确认的产品承诺，但它们仍比泛泛的“云”语言更具体。
Cloud.ir 的价格页面使产品更加可检查。它列出了 VPS 套餐名称，如 AT-VPS-B2、AT-VPS-G1 和 AT-VPS-A2，并在套餐卡上显示内存、CPU、磁盘、一个免费 IP 地址、基本流量、附加 IP 支持、重建支持和 IPv6。它还显示了云服务器资源的按小时计量，如内存、CPU、磁盘、IP、接收流量和备份层级。价格页面不是工程图表，但它们展示了服务的打包方式：客户购买的是有限的计算、存储、地址和流量单位，这些必须存在于某处，然后控制面板才能分配它们。
该公司还描述了基于相同基础设施的高级服务。云数据中心页面宣传安全且易于管理的数据管理、扩展、监控、虚拟化、容器化和定期备份。云存储页面提供可扩展存储、受控共享和访问级别管理。CDN 页面描述了通过国内、集中和国际模式进行内容分发，用户请求通过地理上更近的数据中心位置得到响应。云交换页面提供云服务器和数据中心之间的托管虚拟网络连接。每个产品都减少了客户对自有设备的需求；每个产品也引入了对提供商放置、网络设计和支持决策的依赖。
这就是本文其余部分的有用框架。CLOUD Asre Dadeha Asiatech 并非一个神秘的空壳，但可见的服务表面并不能消除对底层进行测试的必要。只有当提供商已经具备合适的主机容量、存储、公网地址、网络可达性和计费授权时，云服务器才能在几秒钟内配置完成。CDN 只有在边缘存在、拥有新鲜内容、足够的缓存和传输容量、并且在客户自身服务器出现问题时仍能到达源站时，才能将请求路由到更近的边缘。备份只有在能够修复导致主工作负载故障的故障之外进行恢复时才有效。公开页面显示了报价；它们本身并不能证明生产买家所需的每一个弹性声明。
物理锚点是伊朗的 ASIATECH 数据中心容量
Cloud.ir 最强烈的物理声明是明确的：其云基础设施位于 ASIATECH 数据中心。云服务器页面称 Cloud.ir 云服务的基础设施部署在 ASIATECH 数据中心，并将其描述为伊朗最大的数据中心网络。它列出了现代技术、ISO27001 和 TIA-942 Tier 2 和 Tier 3 认证、安全系统、稳定的网络连接、伊朗的高带宽消耗以及交直流电源支持。云数据中心页面重复了相同的 ASIATECH 数据中心框架，并表示 Cloud.ir 在伊朗各地的数据中心为开始云迁移的客户提供基础设施。
关于页面类似。它表示 Cloud.ir 的数据中心遍布伊朗，其基础设施基于 ASIATECH 数据中心，覆盖大型且功能强大的设施，符合全球标准。它还列出了交直流电源支持。这些声明很重要，因为它们将服务从纯粹的零售抽象转移到命名设施运营商边界：云品牌依赖于 ASIATECH 的数据中心资产和网络，而不是一个未命名的海外超大规模区域。
在公司页面之外，公开记录提供了更旧但有用的背景信息。数据中心 Dynamics 在 2017 年 7 月报道称，AsiaTech 在德黑兰西部开设了一个 700 平方米的数据中心。该报道将 AsiaTech 描述为一家成立于 2003 年的私营公司，称其于 2013 年获得了托管、专用和共享服务器以及主机代管的许可证，并称其运营着五个数据中心，连接了伊朗超过 430 个城镇。DataCenterMap 目前列出了德黑兰的Asiatech Milad Tower 数据中心和Asiatech Azadegan 数据中心，而其 Milad Tower 规格页面称，Asiatech 未提供容量、电力、合规、安全或建筑数据。
这些外部引用应谨慎对待。它们证实 ASIATECH 曾与德黑兰的命名设施以及更广泛的数据中心业务相关联。它们并不能证明 2026 年 7 月哪个设施服务于特定的 Cloud.ir 虚拟机、CDN 边缘、存储桶或备份副本。它们也不能证明 2017 年的设施状况、机架数量、电源设计或客户数量保持不变。设施历史是真实基础设施公司的有用证据；但它不是当前的放置地图。
这种区别对客户很重要。买家可能听到“伊朗各地的数据中心”，并假设从同一账户订购的两台服务器位于不同的建筑中。但它们可能不会。它们可能位于同一台主机、同一机架中的两台主机、同一电源单元后的两个机架、同一建筑中的两个机房，或者不同的建筑，但其城域光纤或上游边缘仍然汇聚。相反，提供商可能具有比公开页面所披露的更好的分离性。公开页面没有解决这一点。客户必须询问放置控制、反亲和性规则、命名站点或站点代码、备份位置，以及 Cloud.ir 对每个服务层级的“数据中心”含义。
电力和维修劳动力是相同问题的一部分。Cloud.ir 可以公平地说，使用云避免了客户购买设备和维护服务器机房的负担。但这并不消除物理维护。仍然需要有人更换磁盘、电源、线卡和内存；仍然需要有人安排电气工作；仍然需要有人测试发电机、电池、冷却和消防系统；仍然需要有人接收警报并到达机架。客户不需要知道 ASIATECH 设施设计的每个私人细节，但需要知道哪些可用性承诺能在机架事件、电源维护窗口、存储故障和替换硬件短缺中存活下来。
AS60077 可见，父网络是明显的依赖
网络记录为 CLOUD Asre Dadeha Asiatech 提供了第二个具体锚点。RIPE RDAP 将AS60077标识为 AT-CLOUD，并通过 ORG-ADA42-RIPE 将其与 Asre Dadeha Asiatech 关联。同一 RDAP 响应包括 Asiatech NOC 位于德黑兰 Miremad 街地址的管理和技术联系人，以及一个 Asiatech 滥用角色。这是真实自治系统和运营联系人链的注册证据。它不描述单个服务器、客户或正常运行时间，但它确认云服务有其自己的网络标识符。
RIPEstat 的AS60077 的 AS 概览报告持有者为“AT-CLOUD Asre Dadeha Asiatech”，并显示其在 2026 年 7 月 12 日查询时间被公布。其路由状态视图显示 18 个 IPv4 前缀和 14,080 个 IPv4 地址从 AS60077 可见，首次发现前缀可追溯到 2014 年，最新发现为查询时间。同一 RIPE 视图显示 IPv4 收集器可见性高，且该特定状态响应中无可见 IPv6 空间。
活跃服务也指向 AS60077。RIPEstat 的cloud.ir 的 DNS 链视图返回 apex 域名为193.151.157.174，而该地址的网络信息视图将其映射到193.151.157.0/24和 AS60077。这并不证明每个客户工作负载都在同一前缀内；但它显示公司自身的公共网络存在是从云 ASN 提供的。
依赖存在于邻居数据中。RIPEstat 的AS60077 的 ASN 邻居视图显示一个观察到的左侧邻居：AS43754。RIPEstat 的AS43754 的 AS 概览将该网络命名为“ASIATECH Asiatech Data Transmission company”。其路由状态视图在同一查询时间显示了更大的网络足迹：316 个 IPv4 前缀、209,920 个 IPv4 地址和 86 个观察到的邻居。图片很直接：云 ASN 可见，但其公共上游边界似乎是更大的 ASIATECH 网络。
Looking-glass 样本使这种关系在真实路径中可见。RIPEstat 的193.151.128.0/22 的 looking-glass 数据（AS60077 公布的前缀之一）包括以 AS43754 AS60077 结尾的路径。一些全球样本也显示了 AS43754 之前的早期上游，但一致的近源依赖仍然是 AS43754。这对于附着在同一企业基础设施组的云业务来说并不意外，但这一点很重要，因为该边界的故障可能同时影响许多服务。
这并不意味着 AS60077 是脆弱的。当父网络具有运营商覆盖范围、运营纪律和幕后足够的冗余时，单一可见的上游关系完全合理。这也不意味着 AS43754 只有一条外部路径；RIPEstat 显示 AS43754 有许多邻居。重要的点更窄：公共 BGP 证据并不能证明 AS60077 本身拥有多个独立上游、分离的物理入口、分离的边缘路由器或 AS43754 之外的独立故障切换。客户应将 AS43754 视为可见的上游运营边界，除非 Cloud.ir 提供进一步分离的产品特定证据。
RPKI 回答了不同的问题。RIPEstat 的由 AS60077 发起的 193.151.128.0/22 的 RPKI 验证返回有效状态，包含覆盖 AS60077 的路由源授权。这是积极的路由卫生：它支持路由来源的合法性。它并不证明流量容量、路由多样性、电力连续性、客户隔离质量、备份可恢复性或支持响应。RPKI 有效的路由仍然可能因错误而被撤销、被上游过滤、因交叉连接故障而隔离或因服务器端故障而变得无用。
已安装容量不等于可用云容量
云买家倾向于看到资源滑块。运营商看到的是库存。CPU、内存、磁盘、备份空间、公共地址、防火墙状态、监控、端口容量、主机功耗和员工时间都必须在资源滑块变成工作服务器之前对得上。Cloud.ir 的公开页面很有用，因为它们揭示了一些要素，但它们没有揭示库存水平。
价格页面列出了具有固定内存、处理器、磁盘和流量数量的套餐。它还列出了云基础设施的单独按小时组件，包括备份计划。这足以表明 Cloud.ir 以定价资源池的形式销售服务。但不足以显示池中有多少主机，有多少预留给故障切换，在争用下磁盘性能如何，备份空间是否位于独立站点，损坏实例重建的速度有多快，或者提供商在硬件短缺期间是否能满足大额订单。
网络数字提供了外部边界，而非服务器数量。RIPEstat 的AS60077 的公布前缀列表在最近查询期间显示了 18 个 IPv4 前缀，包括多个/22、/23和/24范围。路由状态视图中看到的 14,080 个 IPv4 地址是真实的公共地址容量，但地址不等于虚拟机。一些地址服务于路由器、负载均衡器、防火墙、名称服务器、客户实例、管理功能或备用池。一个服务器可以使用多个地址；许多服务可以位于一个地址后面；未使用的地址可以与满载的计算集群共存。
同样的谨慎也适用于 Cloud.ir 的 IPv6 引用。价格页面在 VPS 套餐卡上显示 IPv6。此处使用的 RIPE 路由状态查询在查询时未显示 AS60077 的可见 IPv6 空间。这并不证明产品中缺少 IPv6：IPv6 可能通过不同的安排提供，仅在特定计划中暴露，在其他收集器中可见，或在第三方路由站点上以不同方式呈现。但它意味着需要原生 IPv6 的客户应测试实际分配、路由、防火墙行为、反向 DNS、备份可达性和支持升级，而不是仅仅依赖套餐标签。
Cloud.ir 自己的产品语言也将容量与弹性分开。云服务器页面称资源可以即时增加或减少，当一台服务器不可用时，数据会自动从另一台服务器提供。云数据中心页面称存储的数据保存在多个数据中心，如果其中一个出现问题，其他数据中心会保持连接。这些都是重要的声明。它们也需要精确性。哪些服务被覆盖？所有服务器类型都自动转移，还是仅受特定存储层保护的数据？默认使用两个数据中心，还是仅在客户配置时才使用？备份是热备份、温备份还是冷备份？有经过测试的恢复时间吗？如果自动化失败，是否有信用额度可用？
如果没有这些答案，买家应保持“已安装”和“可用”的区分。已安装容量是提供商拥有或租赁的主机、机架、存储阵列、链路和地址的集合。可用容量是客户现在可以分配的内容，而不会使主机过载、耗尽地址池、违反放置规则或依赖于午夜后疲惫的技术人员更换零件。Cloud.ir 的公开页面证明了定价云产品和可见网络。它们没有披露足够的信息来将其转换为容量储备。
SLA 在故障将考验的点上收窄了承诺
Cloud.ir 发布了一个SLA 页面，这对客户来说是好事，因为它将部分风险对话转移到了公共文本中。页面最重要的部分不是较大的正常运行时间数字，而是限制。页面称正常运行时间保证仅适用于正常运行期间的网络和云服务器可用性。它排除了客户的服务器软件、操作系统、配置问题、针对云服务器的拒绝服务攻击、暂停或停止的服务器、除网络或主机服务器以外的中断，以及提前宣布的维护或关键补丁。
同一页面定义了平均维修或恢复时间，即基于提供商与客户之间协议恢复服务的平均时间。然后列出了不产生罚金的情况，包括不可抗力、客户设备、计划停机、客户请求的中断、违反法律或 SLA、未付款以及司法或安全机构的命令。这些排除在托管中并不罕见，但对衡量风险的客户来说是决定性的。它们将许多实际中断移出了简单的正常运行时间标题。
考虑软件故障。如果客户更新后客户操作系统崩溃，SLA 文本表明该问题超出提供商的正常运行时间保证，即使客户经历完全服务损失。如果 Cloud.ir 销售的是非托管计算，这是合理的，但买家需要单独的恢复权利：控制台访问、救援启动、快照、镜像导出、回滚、重建和清晰的支持边界。“云服务器”不是托管的应用程序连续性，除非合同如此规定。
考虑拒绝服务事件。云服务器页面宣传云防火墙控制和攻击报告。SLA 页面将针对云服务器的拒绝服务攻击排除在正常运行时间保证之外。产品仍可能有助于缓解流量，但客户不应假设每次攻击引发的中断都会产生补偿。问题变得实际：防火墙能处理多少流量，云边缘过滤了什么，什么到达了实例，谁能在攻击期间更改过滤器，以及 Cloud.ir 何时可以暂停或限速目标以保护其他客户？
考虑计费。未付款的 SLA 排除很普通，但运营风险不小。预付费钱包、失败的国内支付、公司银行卡问题或争议发票都可能在运营商解决账户之前变成基础设施事件。使用 Cloud.ir 进行生产的公司应询问发送多少提醒，适用什么宽限期，暂停后数据保留多久，快照是否仍然可访问，以及支持是否能在审查计费证据时暂时保留服务。
考虑公共当局命令。SLA 称由司法或安全机构引起的停机在处罚框架之外。这是一个本地性问题，而非对提供商的判断。如果工作负载、备份和支持账户位于一个司法管辖区内，客户需要了解法律或政策命令如何影响可用性、数据访问、域名服务和客户通信。答案对于伊朗国内网站可能是可接受的，但对于具有冲突合规义务的跨境服务可能是不可接受的。相同的物理本地性可能是延迟的优势，也是治理的约束。
因此，SLA 强化了买家的问题。它并没有使 Cloud.ir 更弱；它使服务形态更可知。客户应区分网络可用性、主机可用性、客户健康、存储完整性、备份可恢复性、CDN 行为、账户状态和法律约束。公共 SLA 并没有将这些层折叠成一个承诺。生产买家也不应这样做。
CDN、存储和云交换扩展了功能集也扩展了爆炸半径
Cloud.ir 的 CDN、存储和虚拟网络服务很有用，因为它们可以减少单一源服务器的负载，并给客户更多架构选择。它们也使依赖图更广泛。CDN 页面称国内分发可以通过本地数据中心响应请求，并为国内用户创建半价流量；它还描述了将用户路由到更近的服务器、压缩和缓存内容、监控请求和响应、按国家限制访问以及防御攻击。这是一个真实的产品故事，但它将站点变成了一个链：DNS、CDN 边缘、缓存状态、源可达性、证书处理、账户配置和支持都必须协同工作。
如果源服务器故障，CDN 可能继续提供缓存的静态内容。它也可能提供过时的内容，在动态路由上失败，或当缓存未命中命中不健康的源时增加错误率。如果 CDN 边缘失去上游可达性，一个地区的用户可能看到错误而其他地区没有。如果访问规则配置错误，本地性功能可能变成可用性问题。客户需要缓存清除控制、源屏蔽行为、日志、开启或关闭规则、证书续订可见性以及在 CDN 服务成为故障时转移 DNS 的方法。
存储产品有不同的风险形态。云存储页面称服务让客户扩展容量、管理文件、管理访问密钥、将存储连接到域、共享文件和定义访问级别。它还称数据通过分布在多个服务器上得到保护。这很有价值，但存储持久性从外部不可见。客户需要知道服务是对象存储、块存储、文件存储还是混合；复制意味着什么；副本是放在一个房间还是多个站点；删除如何保护；版本控制是否存在；密钥如何轮换；恢复如何测试；以及完整导出的速度。
云交换服务同样重要。云交换页面描述了云服务器和数据中心之间的托管网络连接、路由流量和创建私有网络。它还称该服务可以识别可用的替代资源，并在中断期间自动切换。如果实现良好，这类功能可以减少手动恢复。但如果私有网络配置错误隔离了一组原本健康的服务器，它也可能成为单一的变更点。
更深的模式是，功能既可以是弹性层，也可以是新的依赖。备份只有在存储在故障边界之外并能快速恢复时才保护数据。CDN 只有在源站弱时能正确提供内容时才保护源站。虚拟网络只有在控制平面和交换结构保持健康时才保护东西向流量。云防火墙只有在压力下能安全更改过滤器时才保护客户。客户不应抽象地问这些功能是否存在。他们应问当主机、机架、路由、存储集群、账户或支持队列已经出现故障时，每个功能的表现如何。
本地性是产品属性，而非口号
数据本地性是购买 Cloud.ir 的最强理由之一。公司页面将云基础设施放在伊朗的 ASIATECH 数据中心，CDN 页面强调国内分发选项，网络证据显示公共云站点在 AS60077 上，父网络是伊朗的 ASIATECH。对于伊朗用户和企业，这可能意味着更低的延迟、国内支付对齐、熟悉的支持语言、本地流量经济以及物理资产靠近目标受众的提供商。
但本地性必须按服务定义。虚拟服务器可能在伊朗运行，而电子邮件中继、管理控制台、分析服务、备份副本或支持附件可能走另一条路径。CDN 产品可能提供国内和国际分发模式。存储服务可能跨多个服务器复制，但不说这些服务器是否在独立建筑中。客户不能从公司地址、顶级域名、自治系统名称或“伊朗各地的数据中心”短语中推断每个数据副本的确切位置。
Cloud.ir 自身在买家档案中的区域行可以是全球，因为 IP 可达性是全球的，云客户可以在任何有工作账户和网络路径的地方。这不同于说公司运营全球区域。这里审查的公开产品证据最强烈地指向伊朗基础设施和 ASIATECH 的国内数据中心资产。如果客户需要仅限伊朗的服务，他们应要求关于计算、存储、备份、日志和支持访问本地性的书面声明。如果客户需要多国连续性，他们应询问 Cloud.ir 自身是否提供，还是客户必须用其他提供商构建。
本地性也改变事件响应。一个伊朗国内的内容站点可能更喜欢 Cloud.ir 的国内 CDN 行为和 ASIATECH 设施，因为大多数用户靠近这些路径。一个国际 SaaS 供应商可能担心支付访问、制裁风险、外国用户延迟、路由过滤、争议解决以及在压力下导出数据的能力。一个公共部门或受监管用户可能重视本地设施控制，但需要更严格的数据访问声明、快照位置以及当局命令的处理方式。相同的基础设施可能非常适合一个客户，而不适合另一个。
实际测试是证据。询问客户面板中可用的区域和站点选择。询问两个实例是否可以放置在独立设施中。询问预定备份存储在哪里。询问 CDN 日志和存储元数据保存在哪里。询问支持工程师是否可以访问客户磁盘、快照、密钥或控制台，以及从何处访问。询问是否可以在不保持账户活跃另一个长计费周期的情况下完成完整导出。一个能冷静回答这些问题的提供商比仅依赖宽泛本地性语言的提供商更容易信任。
主要故障路径贯穿机架、路由、硬件库存、账户状态和迁移
客户应为 Cloud.ir 计划的最可能的故障不是戏剧性的完全中断。而是位于合同层之间的部分故障。虚拟机可能正常，而上游路由降级。路由可能正常，而存储性能崩溃。备份可能存在，而恢复吞吐量太慢。CDN 可能响应静态内容，而动态功能失败。客户面板可能可达，而支付阻止重建。这些中间状态正是客户了解服务是否具有足够运营细节的地方。
机架路径从物理硬件开始。主机故障可以将设计良好的虚拟机移动到另一台主机，如果有共享存储、备用主机容量和正常工作的编排。如果涉及本地存储、裸机分配或非冗余组件，也可能让客户等待零件。公开的 Cloud.ir 页面未披露管理程序平台、主机类别、本地与共享存储的选择或备用硬件政策。客户应询问物理服务器故障时会发生什么，哪些服务自动重启，哪些需要工单，以及是否有在等效硬件上重建的最长时间保证。
上游路径开始于 AS60077 对 AS43754 的可见依赖。如果 AS43754 过滤路由、有边缘问题、更改策略或遭受更广泛的事件，即使客户虚拟机通电，AS60077 客户服务也可能受影响。由于公共数据显示 AS43754 是 AS60077 观察到的上游边界，客户应询问云 ASN 是否有独立的物理边缘路由器、到 AS43754 的多个交接点、任何直接外部传输以及最近的故障切换测试。说父网络有很多邻居是不够的；相关问题是在云边缘发生什么。
硬件库存路径关乎增长和维修。按小时云定价和即时扩展仅在备用 CPU 核心、内存、磁盘、地址和交换机端口时才有用。计划活动、事件、启动或迁移的买家应询问容量是否可以预留，大额增加是否需要通知，以及提供商能否将额外容量放置在独立的故障域中。较小的买家应问一个更简单的问题：如果我当前的主机故障，是否有足够的闲置空间在其他地方重启我的服务器？
支持路径关乎时间和权限。Cloud.ir 称云服务器客户可以随时提交工单。这比狭窄的工作时间渠道好，但客户仍需要升级目标。谁能更改 BGP 路由？谁能授权机架访问？谁能恢复已删除的备份？谁能逆转账户暂停？谁能解释法律或安全命令？如果一线支持团队只能转发请求，修复时间包括每次交接。
迁移路径是最后的安全网。如果客户可以快速离开，他们可以容忍较弱的证据。这需要当前备份、可导出的镜像或文件、文档化的 IP 和 DNS 变更流程、已知的 TTL、在计费争议期间保持可用的账户访问，以及足够的数据移动带宽。还需要避免隐藏的锁定：无法复制的私有网络地址、没有导出路径的存储功能、无法在其他地方重建的 CDN 规则，或无法下载的快照。公开的 Cloud.ir 页面描述了重建、备份和账户操作，但它们没有披露完整的可移植性条款。生产用户应在需要之前获取它们。
买家在依赖 Cloud.ir 前应验证的内容
第一个验证任务是放置。Cloud.ir 应能说明哪些服务可以放置在哪些伊朗位置，位置是独立建筑、机房还是逻辑标签，以及两个实例是否可以保持分离。如果答案是“我们的云处理”，客户应要求用简单的语言描述故障域。小型提供商不需要超大规模术语就能可靠，但它需要诚实的边界。
第二个任务是网络多样性。AS60077 可见且合法，AS43754 是相当大的父网络。这是一个好的起点。但它不等于证明客户流量能在 AS43754 边缘事件中存活。询问正常路径、备份路径、边缘路由器设计、DDoS 处理边界、RPKI 和路由过滤实践，以及 Cloud.ir 是否能在事件期间临时公布客户前缀或移动公网地址。对于大多数 VPS 客户，答案将是否，但问题澄清了依赖。
第三个任务是恢复证据。备份被列为产品特性，价格页面区分了每周、三天和每日备份组件。客户应询问快照的调度方式、捕获内容、未捕获内容、备份副本存储位置、保留时间、典型恢复时间、恢复能否针对其他站点，以及提供商是否有最近的恢复测试结果。不能离开故障边界的备份只是针对狭窄故障类别的保险。
第四个任务是维护和排除。SLA 将已宣布的维护和关键补丁排除在正常运行时间计算之外。询问维护如何宣布，提前多少通知，紧急工作是否可以在没有正常通知的情况下进行，客户是否可以选择窗口，以及多个客户资源是否一起维护。维护窗口并不坏；不清晰的窗口是坏的。
第五个任务是账户连续性。由于未付款在 SLA 处罚框架之外，生产买家应了解钱包资金、发票时间、暂停阈值、申诉路径和暂停后的数据保留。这对于伊朗以外的团队、有采购延迟的团队以及支付访问依赖一个人的团队尤其重要。计费失败可能成为可避免的中断。
第六个任务是退出。导出一个小型服务器镜像，将备份恢复到干净实例，将一个 DNS 记录移出 CDN，在其他地方重建一个防火墙策略，并记录时间。这些测试不需要很大就能揭示问题。它们显示提供商的抽象是帮助客户恢复，还是主要帮助客户留下。
运营论点：真实服务，强网络可见性，不完整的物理证据
CLOUD Asre Dadeha Asiatech 值得比只有过期路由条目的公司更高的置信水平。Cloud.ir 活跃，服务目录具体，价格页面暴露了具体的资源包，SLA 公开，RIPE 记录将 AS60077 作为 AT-CLOUD Asre Dadeha Asiatech 放在公共路由表中。公司站点的 DNS 指向 AS60077。AS60077 有可见的地址资产，其对父网络 AS43754 的依赖是可观察的而非隐藏的。
但这并不意味着服务完全透明。公开记录没有显示客户工作负载的确切数据中心放置、可用主机数量、备用硬件数量、真实世界的恢复时间、每个备份的位置、路由的物理多样性、云边缘的路由故障切换设计，或客户在争议期间会依赖的账户和迁移条款。Cloud.ir 自有营销对可用性和数据持久性做了强烈声明，而其 SLA 画出了实际边界。
因此，正确的解读是平衡的。产品存在。网络可见。物理依赖真实。买家可以合理考虑 Cloud.ir 用于受益于伊朗数据中心接近性、ASIATECH 国内基础设施和本地云控制面板的工作负载。同一买家应避免将云标签视为多站点弹性、路由多样性或无缝退出的证明。这些是工程和合同事实，必须获取、测试并记录。
对于小型网站，如果备份独立且 DNS 能快速移动，剩余的不确定性可能是可接受的。对于高流量伊朗媒体资产，CDN 和国内托管可能很有价值，但运营者应在发布前测试源站故障、缓存行为和支持升级。对于受监管或跨境数据，关键问题是本地性、当局接触、支持访问和导出权利。对于任何生产客户，最终纪律是相同的：购买云服务，但审计其背后的机架、路由、维修和迁移故事。