摘要

  • Network LIGA HOSTING LTD 是 LIGA HOSTING LTD 公共托管业务的基础设施面向身份。Companies House 记录显示,公司编号 17069738 为一家活跃的英格兰和威尔士私人有限公司,于 2026 年 3 月 4 日注册成立,SIC 代码为 63110,而该公司自己的条款称其托管业务自 2019 年以来一直活跃,为 30 多个国家的客户提供服务。
  • 公共服务界面足够真实,可以进行测试:LigaHosting 在图尔恰和法兰克福宣传 VPS Standard,在法兰克福宣传 Ryzen 9 9950X 高性能 VPS,提供附带每日七次备份的 cPanel 网页托管,并以罗马尼亚品牌提供游戏托管。同一网站声明拥有 AS201131、DDoS 防护、10-40 Gbps 上行链路、60 秒内 VPS 配置以及 99.9% 的月度网络和核心基础设施 SLA。
  • AS201131 目前可见。RIPE RDAP 将 AS201131 标识为 LGH-Network,于 2026 年 3 月 3 日注册给 LIGA HOSTING LTD;RIPEstat 的最新路由状态视图显示三个 IPv4 /24 和两个 IPv6 /48,具有完全或接近完全的 RIS 可见性。经检查的三个 IPv4 路由源对通过了 RPKI 验证,而两个当前 IPv6 /48 在检查的 RIPEstat 视图中返回了未知验证结果。
  • 证据等级为中等。公开路由、产品、状态和合同证据支持一个运营中的托管足迹,但记录仍未证明机架所有权、设施运营商、双电源路径、备用硬件、每个站点内的路由多样性、经过测试的恢复或客户迁移权。

一家包裹着更早托管故事的英国新公司

第一个需要区分的事实是法律实体与运营历史。Companies House将 LIGA HOSTING LTD 记录为编号 17069738 的活跃公司,于 2026 年 3 月 4 日注册成立,注册地址为 3rd Floor, 86-90 Paul Street, London, EC2A 4NE,业务性质为 63110,即数据处理、托管及相关活动。高管页面将 Ionel-Florin Florin Moisa 列为活跃董事,于公司成立日任命。重要控制人记录记载 Ionel-Florin Moisa 拥有 75% 或以上的股份和投票权,并有权任命或罢免董事。

这使得公司可见,但尚年轻。其首次账目要到 2027 年 12 月才到期,首次确认声明则要到 2027 年 3 月才到期。因此,客户尚无法查阅完整的申报记录、账目历史或一系列公司事件。当买家需判断一家低成本服务器提供商是持久的交易对手,还是一个可能改变法律形式、地址资源安排或运营供应商的快速变动的托管品牌时,这一点至关重要。

公开网站讲述了一个更长的交易故事。LigaHosting 的条款最后更新于 2026 年 4 月 29 日,其中表示 LIGA HOSTING LTD 运营 ligahosting.com 品牌(用于国际 VPS 和 cPanel 网页托管)和 ligahosting.ro 品牌(用于游戏托管),自 2019 年起运营,为 30 多个国家的客户提供服务,并在罗马尼亚和德国运营 VPS 基础设施。这段更早的历史声明很可能描述了该品牌或贸易业务在英国公司成立之前的状况。不应将其解读为编号 17069738 公司的 Companies House 历史。

这种区分并非学究之论。如果一项服务拥有较老的客户、较旧的管控面板或较早的基础设施合同,一家新公司可以继承某些运营惯例,却无需继承长期的法律申报记录。如果该公司是围绕一个现有的罗马尼亚或欧洲托管业务而新组建的包装体,客户应询问当前合同由哪个法律实体签署,哪个实体拥有或租赁硬件,哪个实体持有供应商账户,以及当另一个品牌、经销商账户或旧管控面板仍存留在业务链中时,现有服务将受到何种影响。

同样,伦敦的注册地址并不代表数据中心。Companies House 的地址及网站的结构化组织数据标明的是公司地址,而非机架位置。这与一家销售罗马尼亚和德国基础设施的英国公司相符。但它并不能证明客户数据在英国处理、技术支持人员在伦敦,或该公司拥有任何英国设施。托管业务的情况必须通过产品页面、状态页面、路由表和条款来核实。

公开产品界面出售的是什么

产品页面显示的服务面向中小型托管买家,而非超大规模云服务。LigaHosting 主站宣传“VPS Standard & Performance”、DDoS 防护、即时部署、优质网络连接、企业级硬件以及在罗马尼亚和德国的欧洲覆盖。它声称 AS201131 是公司自有骨干网,并称 VPS 配置时间在 60 秒以内。它还宣传 10-40 Gbps 上行链路以及 15 分钟内的支持响应。这些都是商业声明,但足够具体,可转化为具体的物理问题。

VPS Standard 页面列出了两个基础设施节点:罗马尼亚图尔恰,描述为基于双 Intel Xeon Gold 6254 硬件的 Standard;以及德国法兰克福,描述为基于 AMD EPYC 7702 的 Standard。计划卡片涵盖从小型 VPS 实例起步的多个选项,包含一个 IPv4 地址和 DDoS 防护。VPS Performance 页面则将其高频层级集中在法兰克福,采用 AMD Ryzen 9 9950X 处理器,计划从 1 vCPU、2 GB RAM 和 100 GB NVMe 扩展至 12 vCPU、64 GB RAM 和 1.6 TB NVMe。这是一个具体的计算方案,而非仅仅一个空泛的“云”标签。

网页托管页面提供了另一产品界面:cPanel 托管、SSD 存储、免费 SSL、邮箱账户和每日备份。Web Starter 宣传 20 GB SSD 存储和一个网站。Web Pro 扩展了存储和账户规模。Web Business 则宣传无限制 SSD 存储、无限制网站和一个免费的独立 IP。重要的依赖关系变化在于,cPanel 托管将多个账户集中在共享服务器和共享管理系统中,而 VPS 托管虽赋予买家根访问权限,但也将更多备份和配置责任转移给了买家。

罗马尼亚的游戏托管品牌提供了另一信号。LigaHosting.ro宣传在罗马尼亚和德国提供游戏服务器托管,目标是 99.9% 的正常运行时间,提供 24/7 支持,并展示一个基础设施面板,显示罗马尼亚为 5.180.33.0/24,德国为 163.5.26.0/24。它列出罗马尼亚计算平台为 Intel Core i9-14900K,配备 192 GB DDR5 和 2 TB NVMe,而德国平台为 AMD Ryzen 9 9950X,配备 128 GB DDR5 和 2 TB NVMe。这些页面声明与可见的两个 AS201131 IPv4 前缀相符,但仍未指明设施运营商或证明有备用容量。

状态页面也很有用,因为它用运营术语指明了服务位置:罗马尼亚图尔恰用于 VPS Standard,德国法兰克福用于 VPS Standard、VPS Performance 和网页托管。经检查,该页面显示“所有系统运行正常”且无活跃事件,两个位置均标记为运行中。一个显示绿色的当前状态页面并非正常运行时间档案,但它告诉客户提供商将其视为公共服务组件的内容。

这些证据足以说明 LigaHosting 不仅仅是一个空壳。它拥有公开的产品目录、活跃的服务位置、具体的处理器声明、客户状态页面、服务条款和一个活跃的网络。但这不足以说明该公司拥有机架、控制建筑物或能在区域间迁移所有工作负载。VPS 买家看到的是一个计划名称、一个 CPU 系列和一个 IP 地址。弹性决策取决于这些标签背后所隐藏的东西。

AS201131 可见,但可见性并不等于控制力无处不在

最有力的技术证据是网络。RIPE RDAP 中关于 AS201131 的信息将 AS201131 标识为 LGH-Network,于 2026 年 3 月 3 日注册,最后变更于 2026 年 6 月 15 日,注册组织为 LIGA HOSTING LTD,滥用联系邮箱为 [email protected]RIPEstat 的 AS 概览将持有者标识为“LGH-Network LIGA HOSTING LTD”,并将该 ASN 标记为已通告。这使网站声明与公开路由证据相一致。

当前路由集合较小巧。RIPEstat 的路由状态视图显示,在最近的 2026 年 7 月 12 日查询时间点,共有三个 IPv4 前缀,总计 768 个 IPv4 地址,以及两个 IPv6 /48 前缀。它报告在 RIS 对等点中具有完全 IPv4 可见性和近乎完全的 IPv6 可见性。RIPEstat 的已通告前缀视图还显示,几个 IPv6 /48 前缀曾在前两周窗口内出现,但截至 7 月 12 日已不再属于当前高可见性集合。这对于一个小型网络来说相当正常,但意味着买家应区分当前的生产路由与近期或实验性的路由可见性。

当前三个 IPv4 前缀与产品地理位置相符。5.180.33.0/24163.5.26.0/24146.19.215.0/24在 RIPEstat 检查的前缀概览视图中均可见,并以 AS201131 为源。罗马尼亚游戏网站明确将 5.180.33.0/24 映射至罗马尼亚,将 163.5.26.0/24 映射至德国。官方产品页面和状态页面将 VPS 和网页托管服务放在罗马尼亚和德国。这给出了一个合理的地理分布:罗马尼亚和德国是对客户的服务区域,英国公司则是法律上的交易对手。

对于 IPv4,路由源安全性是一个积极因素。RIPEstat 对 5.180.33.0/24 的 RPKI 验证163.5.26.0/24以及146.19.215.0/24均返回了对 AS201131 的“有效”结果。有效的 RPKI 并不能使服务器变得可靠,但它通过告知执行源验证的网络 AS201131 有权通告这些前缀,从而减少了一类路由故障。

IPv6 方面的状况则较弱。对2a06:9801:c2::/482a06:9801:22c::/48的当前前缀概览检查显示它们由 AS201131 通告,但检查的 RPKI 验证 URL 返回了“未知”而非“有效”。“未知”并非无效。这意味着在检查的视图中,未找到针对所查询的源-前缀对的验证路由源授权。对于需要原生 IPv6 及路由源保证的客户,这是采购前需要解决的问题。

上游证据需要注意措辞。RIPE 数据库的 aut-num 记录列出了涉及 AS209735、AS58061、AS58212、AS213323 和 AS207841 的导入和导出策略。RIPEstat 的 asn-neighbours 视图在最新检查时刻观察到了四个邻居:AS213323、AS397373、AS58061 和 AS58212。CAIDA AS Rank将 AS201131 视为一个拥有三家提供商的小型 AS,在其数据集中未观察到客户或对等体。确切的名称和角色在路由策略记录和观测数据集之间有所不同,这在 BGP 中是意料之中的。保守的结论是,在公开观测中 AS201131 是多宿主的,但公开记录并未证明哪些上游服务于每个位置,是否每个区域都有活跃的上游,或者光纤路径和路由器对在物理上是否具有多样性。

PeeringDB 则增加了另一项缺失。经检查,针对 AS201131 的 PeeringDB API 查询未返回任何网络对象。这并非缺陷;许多小型网络不维护 PeeringDB 配置文件。但这确实意味着客户无法使用 PeeringDB 来确认设施存在、交换 LAN、公开对等策略或流量水平。对于一家以“自有骨干网”为卖点的运营商而言,发布一个基本的互联配置文件将使控制界面更容易验证。

在最关键的地方,关于机架的情况却含糊不清

一台托管服务器作为软件对象出售,却可能作为物理对象而故障。网站之所以能在几秒内配置一个 VPS,仅仅是因为已经有一台真实的服务器通电、制冷、连线并放置在机架中。游戏服务器之所以能宣称低延迟,仅仅是因为数据包经由机架顶部交换、边缘路由器、传输提供商和 DDoS 缓解设备传输。cPanel 账户之所以能承诺备份,仅仅是因为在某个地方运行着存储和备份任务,拥有足够的磁盘、带宽和操作关注。

对于 LigaHosting 而言,可见的位置是图尔恰和法兰克福。这比一个模糊的“欧洲”声明要好。剩下的缺失是设施身份。为本文审查的公开来源未能确定图尔恰的数据中心运营商、法兰克福的设施、机架所有权、机柜数量、供电路由设计、远程支持提供商、灭火系统范围、制冷冗余、运营商互联机房或硬件更换流程。公开网站声称“欧洲云基础设施位于罗马尼亚和德国”;但它没有说明 LIGA HOSTING LTD 是在托管机架中拥有硬件、租赁专用服务器、转售平台,还是按产品混合使用这些模式。

这一点很重要,因为设施、机架和虚拟化集群是不同的层面。一个法兰克福数据中心可能拥有多路市电、UPS 系统和发电机,而租户仍可能将单线路服务器插入一个电源排插。一个机架可能位于良好的设施中,但其机架顶部交换机仍是单点故障。一台服务器可能有两块 NVMe 设备,而快照却存于同一节点。站点级的绿色指示灯可能与一台故障主机或一个过载的存储池共存。

产品证据指向一个小巧的平台。VPS Standard 页面提到了图尔恰的双 Intel Xeon Gold 6254 和法兰克福的 AMD EPYC 7702 节点。Performance 页面提到了法兰克福的 Ryzen 9 9950X。游戏网站提到了罗马尼亚的 Core i9-14900K 和德国的 Ryzen 9 9950X 平台。这些都是常见的托管服务器类别,可以为小型工作负载提供出色的性价比。但它们本身并不能证明集群故障转移、实时迁移、分布式存储或备用服务器。

NIST 的云计算定义在这里很有用,因为它将真正的弹性资源池与普通的托管虚拟机区分开来。一个 VPS 产品可以提供广泛的网络接入和一些自助配置功能,而不必证明快速的弹性、可计量的服务、跨主机池或多位置弹性。托管网站页脚的“云”字并不能决定架构。真正的考验在于,客户能否在丢失一个节点、机架或站点后,在已知的时间窗口内恢复。

对于小型提供商而言,这种缺失并不罕见。许多真实的托管业务并不公布设施合同或机架图表。问题不在于主页上缺少这些信息。问题在于,购买生产工作负载的客户需要询问,因为这些证据无法推断。哪些产品是单节点的?哪些使用复制存储?哪些有快照?罗马尼亚和德国是独立的故障域,还是仅仅是不同的产品地点?客户的虚拟机能否在它们之间迁移?IP 地址是否随之移动?这些答案决定了产品是廉价的容量,还是有弹性的容量。

装机容量不等于可恢复容量

路由表给出了某些网络资源的上限,而非计算资源的上限。三个 IPv4 /24 在当前公开源集合中提供 768 个 IPv4 地址。为每个 VPS 分配一个 IPv4 的计划可以快速消耗这些地址,但地址数量并不能说明有多少台物理主机。一台服务器可以支持许多低端 VPS 实例。一个客户可以消耗多个地址。有些地址是为基础设施、滥用替换、路由测试或未来增长而预留的。因此,IPv4 数量是一个约束条件,而非容量登记册。

宣传的处理器也是如此。对于高频游戏和性能 VPS 工作负载,一个 Ryzen 9 9950X 主机可能很有吸引力。但如果多个对延迟敏感的服务器共享一台物理机器,它也可能成为一个严重的故障域。一个 AMD EPYC 或双 Xeon 节点可以承载许多标准 VPS 实例,但备用容量取决于内存余量、存储余量、CPU 超配比以及是否有另一台兼容节点可用。公开页面陈述的是计划规格,而非超配比或热备池。

存储是另一个隐藏边界。NVMe 可能意味着一台主机上的高速本地驱动器,也可能是镜像本地存储,或者是一个单独的存储服务器,甚至是一个分布式存储系统。每种设计都有不同的故障行为。本地 NVMe 可以极快,直到硬盘、控制器或主机发生故障。镜像本地存储可以承受单个驱动器故障,但无法承受所有主机故障。只有当副本位于独立机器上、法定人数得以维持且重建流量不致压垮网络时,分布式存储才能容忍节点丢失。LigaHosting 的公开页面宣传 NVMe 和 SSD 存储,但并未描述 VPS 计划的耐久性架构。

网页托管产品则较为清晰,因为条款规定 cPanel 网页托管计划可享受保留七天的每日自动备份。这很有用,但并不等同于持续复制或不可变的异地备份。只要备份完成、保持可读且存储位置不在导致主服务器损坏的故障范围内,它就能保护部分客户免受服务器丢失和普通错误的影响。但条款明确指出,内部备份仅用于服务器级别的灾难恢复,提供商不保证其完整性或可用性。这是一个谨慎的限制,客户应将其理解为一种警告,即应自行保留副本。

VPS 产品则相反地更加清晰:默认情况下不包含备份。条款规定,VPS 客户负责自己的备份,快照或额外备份可能需要额外付费。这是一个诚实的边界,但它将产品从“主机将恢复我的服务器”转变为“主机可能保持虚拟机运行,但除非我购买并测试更多选项,否则可恢复性由我自己负责。”任何将默认 VPS 视为已备份基础设施的买家都误解了运营安排。

提供商的 99.9% SLA 也应理解为一种信用机制,而非恢复保证。条款定义了每月网络和核心基础设施 99.9% 的可用性,每月非计划停机时间约 43 分钟,但排除了计划维护、超出缓解容量的 DDoS 攻击、不可抗力、客户代码和第三方软件。如果未达到 SLA,客户的补救措施是与其月度付款挂钩、上限为 50% 的账户信用。这并不能重建数据库、恢复丢失的 IP 声誉或补偿超出服务费用的业务中断。

这在托管经济模型中属于正常现象。低月费取决于有限的责任、共享系统、自动化和客户责任。实际问题是,客户是否已将自己的风险与这种交易相匹配。一个业余游戏服务器可能接受几小时的停机并从本地副本恢复。而托管客户网站的代理机构、面向支付的应用程序或带有 IP 白名单的邮件服务器,则应将默认产品仅视为更广泛恢复计划中的一个组成部分。

传输多样性必须在每个服务位置内部进行测试

AS201131 的公开路由是记录中较好的部分之一。它是活跃、紧凑且可见的。三个 IPv4 路由通过验证,RIPEstat 观察到多个邻居。该网站声称拥有 10-40 Gbps 上行链路、优质欧洲连接和网络边缘的 DDoS 防护。这些事实支持了一个真实的网络运营。但它们并不能证明每个位置都有独立的物理路径。

在故障期间,这种差异至关重要。一台罗马尼亚服务器可以拥有一个 AS201131 地址,但同时依赖一条本地上行链路、一个交换机或一个设施交叉连接。一个法兰克福性能节点可能位于更强的传输组合之后,但仍然只有一个面向客户的路由器对。DDoS 过滤可能表现良好,直到攻击规模超过合同容量,或者过滤以增加游戏服务器延迟的方式转移流量。BGP 表显示的是从路由收集器可到达,而非穿过一栋建筑的电缆路径。

RFC 7454描述了诸如前缀过滤、AS-Path 控制、最大前缀限制和路由策略卫生等运营控制措施。RPKI 验证在此基础上回答了路由源是否经过授权的问题。LigaHosting 经检查的 IPv4 路由源状态是积极的,但 BGP 卫生并不等同于可用性工程。一条有效路由仍可能被意外撤回、被上游过滤、在缓解期间被黑洞化,或滞留在故障交叉连接之后。

路由策略记录也表明了客户为什么应该直接提问。RIPE aut-num 列出了来自多个 ASN 的导入,而 RIPEstat 观察到的是不同的活跃集合。这本身并不可疑。这正是路由注册表和实时 BGP 经常存在差异的方式。然而,对于生产采购而言,相关的问题不是“策略对象中有多少个名称?”,而是“这项服务的每个站点有哪些活跃的上游负责承载该客户的前缀,当其中一个失败时会发生什么?”

最有用的披露将是一个简单的逐站点连接声明:罗马尼亚有以下上游,法兰克福有以下上游,两者均受监控,DDoS 缓解位于此处,计划维护通过这些渠道公告,紧急路由更改由这些人员授权。设施名称和路由器地址无需公开。重点在于展示广告中称为骨干网的网络,在客户服务器实际运行的位置是否具有独立路径。

对于游戏托管,路由质量不仅关乎正常运行时间。延迟和抖动至关重要。一条保持正常运行但绕道另一国家的路由,可能让服务器在玩家眼中感觉已损坏。游戏网站根据用户设备测量延迟并显示区域探测,这在购买时很有用。但它并不能替代历史延迟数据、丢包报告或事件记录。具有竞争性或社区工作负载的客户应从对自己重要的玩家地理位置运行自己的探测。

计费和账户控制是停机表面的一部分

条款异常明确地揭示了一条故障路径。服务按预付费计费。如果发票逾期未付,在到期后第一天和第二天会发送提醒邮件,服务将在第三天自动暂停,第七天出现最终终止警告,而在第十四天,服务将被终止且所有数据被永久删除。条款称,已删除的数据无法恢复,终止后的重新激活需下新订单,且不保证相同的 IP、主机名或数据。

这不仅仅是财务语言。这是一个运营依赖。一个在线的服务器可能因为信用卡故障、PayPal 账户被锁、加密货币确认延迟、发票邮件落入垃圾箱、代理机构员工离职或客户方账户被盗而变得不可用。从外部看,服务是中断了,尽管机架、电源和路由可能完好无损。即使最快的技术团队也无法恢复一个其数据已根据计费规则被故意删除的停止运行的虚拟机。

第十四天删除规则也影响迁移。如果客户等到争议或未付款窗口已开启后才行动,那么用于导出数据、降低 DNS 生存时间值、复制数据库并测试另一提供商所剩的时间可能很短。如果账户持有人不在,服务所有者甚至可能收不到提醒。因此,多人账户访问、受监控的计费联系人和独立的备份是正常运行时间的控制措施,而非行政上的繁文缛节。

退款条款强化了相同的经济逻辑。30 天退款保证适用于首次托管服务订单的新客户,但不适用于域名、标记为不可退款的设置费、专用服务器或定制硬件、续费、因违反条款而被终止的账户或某些加密货币退款情况。这在托管行业中很常见。这也意味着客户不应将可退款性当作测试的替代品。工作负载应在第一个月内进行基准测试、备份并在其他地方恢复,此时退出摩擦最小。

账户控制还可能影响 IP 连续性。条款并未承诺恢复或重新激活的服务在终止后能保留相同的 IP 地址。如果客户控制 DNS 区域,许多托管工作负载可以通过 DNS 迁移。但有些则不能。支付集成、安全白名单、邮件声誉、游戏服务器社区和合作伙伴 API 通常依赖稳定的 IP。使用 LigaHosting 的客户应记录哪些依赖项能容忍 IP 变化,哪些需要提前通知或备选提供商。

维护窗口和恢复测试决定产品的真正面貌

公开条款承诺计划维护至少提前 48 小时通知,并排除在 SLA 之外。这是一个合理的客户通知标准,但仍留下实际问题。通知通过什么渠道发布?是出现在状态页面、电子邮件、客户端区域还是 Discord 上?通知是否指明受影响的位置、节点或产品?客户能否推迟重启?紧急维护是否以不同方式处理?当前状态页面显示实时状态,而非维护档案,因此买家尚无法检查以往工作的沟通方式。

对于小型托管提供商而言,维修窗口尤其重要,因为故障往往跨越供应商边界。如果图尔恰的一个节点发生故障,提供商可能需要本地协助。如果法兰克福的交叉连接失败,设施或运营商必须采取行动。如果 DDoS 提供商对某一目的地采取黑洞操作,网络运营商必须协调过滤。如果 Ryzen 性能节点出现主板故障,更换取决于有兼容的库存。客户无需知道每个供应商的名称,但需要知道谁能采取行动以及行动有多快。

CISA 的勒索软件指南建议实施离线加密备份、定期进行可用性和完整性测试、保留黄金镜像并考虑使用第二家云提供商。该指南是为网络事件编写的,但同样的恢复原则也适用于存储丢失、账户暂停和硬件故障。一个从未被恢复过的备份只是一种希望,而非一项控制措施。

NIST 的应急规划材料将恢复框架构建在备用设备、备用位置、备用存储和电信服务之上。对于 LigaHosting 的客户,实用版本很简单:导出应用程序,在另一家提供商上恢复,将一个测试主机名指向它,确认身份验证和电子邮件,并计时演练。如果恢复需要原始 VPS 在线,那么恢复计划就过于依赖已故障的系统。

对于 cPanel 用户,提供商提供的七天备份窗口虽然有用但短暂。它可以防止快速发现的更新破坏,但可能无法涵盖缓慢损坏、数周隐藏的入侵,或在账户被终止后才请求恢复的客户。对于 VPS 用户,默认情况更为鲜明:不包含备份。快照有助于即时回滚,但同一提供商账户下的快照无法防止账户关闭、提供商侧的删除或区域性服务事件。

因此,清晰的客户模式是分层的。在价格可承受且经测试的情况下保留提供商的快照。在账户之外保留独立备份。将 DNS 和域名注册置于客户自主控制之下。在单独的系统中存储部署说明、凭据和配置。在另一个位置的小型虚拟机上测试恢复。对于 IP 地址本身就是服务一部分的工作负载,维护一份更改白名单的沟通计划,并通过另一家提供商准备一条备用路由。

地域性在英国注册和欧盟基础设施之间分裂

公司在英格兰和威尔士注册成立。公共服务位置是罗马尼亚和德国。游戏托管品牌面向罗马尼亚,产品文案在整个公开界面上是双语言或多语言的。这是一种可行的欧洲托管安排,但意味着“本地”取决于买家的问题。一个英国客户可能拥有一个英国的法律交易对手和位于欧盟的计算资源。一个罗马尼亚游戏社区可能位于罗马尼亚服务区域,但合同却与一家英国公司签订。一个德国性能 VPS 客户可能更关心法兰克福的路由和数据处理,而非公司注册地。

个人数据使这成为一个合同和映射问题。ICO 的国际传输指南解释称,组织需要了解个人数据何时被跨境传输或访问。ICO 的控制者和处理者指南解释了为什么各方的角色会影响义务。托管客户无法仅凭 IP 国家代码回答这些问题。

欧盟与英国的关系也不同于“任何欧洲地区都一样”。欧洲委员会的充分性认定信息解释了委员会可据此决定某非欧盟国家提供充分保护的机制,且委员会于 2026 年 1 月宣布续期了英国的充分性认定。这有利于欧盟-英国数据流动,但并不能解决所有后续传输、远程支持访问、分包商访问、备份或日志问题。

欧盟网络安全法增加了另一个视角。NIS 2 指令涵盖了包括云计算和数据中心服务在内的重要数字基础设施类别,但须遵守国家转化以及规模或角色门槛。一家小型托管公司可能属于或不属于某个特定的国家范围,本文并非法律评估。运营上的要点是,客户应识别提供服务的实体、数据和备份的存储位置以及哪些分包商可以访问系统。

数据主权也包括故障处理。如果备份被复制到另一个国家,如果支持人员可以从另一个司法管辖区访问控制台,如果 DDoS 缓解通过另一个网络转移流量,或者如果日志保留在第三方 SaaS 服务中,实际的数据地图比广告中的 VPS 位置更广泛。LigaHosting 的公开条款规定,客户内容仍然是客户的财产,并授予提供商有限的权利,为提供服务而存储、为备份和冗余进行复制以及传输内容。条款并未公布逐国的分包商或备份位置地图。

对于普通低风险工作负载,如果客户理解,英国-罗马尼亚-德国结构可能足够。但对于受监管的个人数据、敏感社区、公共部门工作负载或具有严格地域性承诺的客户,买家应要求书面的数据处理协议、生产和备份数据的位置地图、支持访问控制、删除规则和分包商详细信息。公开网站提供了一个起点,但并非完整的主权答案。

当系统故障时谁会受到影响

可能暴露的用户不仅仅是发票上的具名人。一家小型代理机构可能在一个 cPanel 计划或数个 VPS 实例上托管众多客户网站。游戏服务器所有者可能支持一个仅知道域名和 Discord 频道的大型社区。开发者可能为付费用户运行一个 API。企业可能在共享计划上托管电子邮件,并在中断期间发现密码重置、发票和支持通信都依赖于同一家提供商。

对于 VPS 客户,直接的故障模式是熟悉的:主机节点崩溃、存储设备故障、DDoS 过滤器反应过度、上游策略变更或计费事件导致访问暂停。间接故障通常更糟。客户没有当前的异地备份。DNS 由同一账户持有。唯一的管理员使用的是位于故障服务器上的邮箱。应用程序依赖硬编码的 IP。存在快照但无法下载或在其他地方恢复。在这些情况下,提供商的恢复窗口只构成中断的一部分。

对于网页托管客户,共享服务器的风险有所不同。一个滥用或受感染的账户可能影响服务器声誉、邮件送达率或资源限制。条款保留限制、要求升级或暂停影响同一物理服务器上其他客户服务的权利。这对于共享托管是必要的,但意味着客户不能完全控制性能环境。“无限制”带宽和存储语言受到正常使用的限制,并排除了在共享托管上进行大文件分发、媒体流、下载服务器或类似 CDN 的使用。

对于游戏托管,影响既是技术性的,也是社会性的。玩家社区会立即注意到延迟、丢包、重启和区域变更。一个技术上线但拥堵的节点仍可使服务器清空。更改 IP 可能破坏服务器列表、保存的收藏夹和社区指导。罗马尼亚网站提供了有用的区域和硬件信息,但运营严肃社区的客户应询问游戏面板、数据目录、模组包和数据库如何备份,以及在罗马尼亚和德国之间移动服务器的速度有多快。

对于所有三个产品家族,最强的客户控制是可移植性。保持域名独立。保持支付和支持联系人由多人监控。保持应用程序配置在服务器之外。在另一个账户和另一家提供商处保留备份。在第一次严重事件之前测试恢复。这些并非不信任的表现。它们是预算和中端托管中正常的责任分工。

需要什么样的证据才能获得更强评级

Network LIGA HOSTING LTD 可以从中等证据转向强证据,而无需暴露敏感内部信息。第一个改进是提供一份简洁的基础设施声明:哪些城市是活跃的,公司在每个城市是拥有硬件还是租赁专用容量,每个站点运行哪些产品家族,每个站点是否至少有两条上游路径,以及在供应商故障期间客户 IP 空间能否移动。一个公开的 PeeringDB 记录会有帮助,但即使只是一个纯文本的网络页面,也能让骨干网声明更容易验证。

第二个改进是设施和电源背景。客户不需要机架编号。他们需要知道服务器是否位于专业数据中心,电源是否双路供给,主机是单线还是双线供电,是否签订了远程协助合同,替换部件是否在当地储备,以及计划设施维护是否具有零停机设计或客户重启窗口。Uptime Institute 的等级材料提醒我们,设施能力和租户拓扑并不相同;一个获得认证的建筑物不会自动认证每个托管节点。

第三个改进是备份和恢复证据。条款已经清晰地划分了 cPanel 备份和默认 VPS 责任的界限。更强的下一步是产品特定的恢复目标:cPanel 恢复请求时间、快照保留选项、异地备份位置选择、下载/导出格式,以及提供商上次恢复演练的结果。对于 VPS,付费备份产品应说明它是否存储在节点外、机架外或场外。

第四个改进是状态历史。一个时刻的绿色页面很有用;事故和维护的历史更有用。客户应能看到图尔恰和法兰克福进行过多少次计划工作,是否有任何事故跨区域发生,恢复用了多长时间,以及事后做出了哪些改变。这不仅仅是透明度作秀。它让买家能够将声称的 99.9% 月度目标与实际运营行为进行比较。

第五个改进是退出权利。条款已经说明,终止的服务可能不会保留 IP、主机名或数据。一项生产友好的提供商仍可以公开客户如何导出 VPS 镜像、检索 cPanel 备份、降低 DNS 依赖、转移域名以及在删除前请求紧急数据访问。托管锁定往往出现在故障期间,而非购买时。

裁决:可见的托管容量,未经验证的深层弹性

Network LIGA HOSTING LTD 相较于最初稀疏的目录快照所显示的,是一个证据更充分的托管对象。这家英国公司存在并且符合托管 SIC 代码。公开网站和条款描述了具体的 VPS、cPanel 和游戏托管服务。状态页面列出了图尔恰和法兰克福服务位置。AS201131 注册给 LIGA HOSTING LTD,在公开路由中处于活跃状态,当前始发三个 IPv4 /24 加上两个可见的 IPv6 /48。经检查的 IPv4 路由源状态是有效的。这些要点支持了一个真实的运营足迹。

同样重要的是上限。这家公司是新注册的。公开记录未指明设施、机架所有权、远程支持提供商、交叉连接、硬件备件库存、每个位置确切的上游组合、DDoS 容量、存储复制设计、恢复测试历史或客户迁移权。SLA 主要是一项服务信用承诺。VPS 备份默认不包含在内。计费规则可以在第三天暂停服务,并在第十四天删除数据。这些本身不是缺陷;它们是依赖关系的实际形态。

对于实验性的 VPS 使用、自有备份的游戏社区、小型网站和可通过 DNS 移动的工作负载,如果价格、延迟和支持合适,LigaHosting 的公开证据可能足够。对于受监管的数据、客户生产托管、收入关键型应用程序或具有严格恢复目标的服务,买家应将平台视为托管容量,并仍需设计独立的恢复方案。索取站点、备份和路由证据。在账户外测试恢复。拥有 DNS 和域名注册。了解当账单、机架、节点、上游或提供商合同出现问题时会发生什么。

核心事实不是 AS201131 存在,也不是图尔恰和法兰克福出现在状态页面上。而是,在该表面之下出售的每台虚拟服务器,都解析为一系列小型物理和合同依赖关系:一台服务器、一个机架、电源、制冷、传输、DDoS 缓解、支持劳动力、计费状态和一条退出路径。Network LIGA HOSTING LTD 已有足够的公开证据,可被认真对待为一个运营中的托管商。但它尚未公布足够的证据,让客户能将恢复弹性外包给提供商。