摘要
- Geeky Cloud 作为一家孟加拉国提供商公开可见，业务覆盖库尔纳。其公开网站推广家庭互联网、企业互联网、专线互联网、闭路电视、网络设置和网络安全，列出在库尔纳的 Nirala、Gollamari 和 Bagmara 的办公室，并将其描述为经 BTRC 批准的 ISP。
- 最强的网络证据真实但有限。APNIC RDAP 记录 AS148974和APNIC whois 视图将 GEEKY-AS-AP 标识为孟加拉国的 Geeky Cloud，而RIPEstat 宣布前缀数据显示在审查窗口期间，可见的宣布资源为 103.175.17.0/24 和 2001:df7:e680::/48。
- 路由卫生状况优于公开的弹性故事。RIPEstat RPKI 验证 103.175.17.0/24和RIPEstat RPKI 验证 2001:df7:e680::/48均将当前来源标记为有效，然而AS148974 的 RIPEstat 路由状态数据报告了一个 IPv4 前缀、一个 IPv6 /48 和一个观察到的邻居。
- 实际风险是依赖集中。Geeky Cloud 理论上可以为本地接入用户和小型托管或媒体邻近用例提供服务，但公开记录未证明命名的数据中心站点、自有机架、备用服务器库存、多运营商故障切换、公开事件历史、可移植客户备份或如果上游、接入设备、计费联系人或维修队列失败时的记录化退出路径。
为什么 Geeky Cloud 需要审慎解读
名称 Geeky Cloud 容易让人联想到云服务，但公开证据要求更谨慎的解读。一家公司可以使用云语言，而其可见业务是本地接入、管理连接、媒体交付或混合在社区 ISP 品牌背后的小型托管服务。在这种情况下，公开记录首先指向库尔纳的互联网接入。Geeky Cloud 自己的孟加拉国网站主要面向本地客户：它销售家庭互联网、企业互联网和专线互联网，提供住宅套餐速度，宣传 BDIX 和 CDN 速度，列出支持与支付的联系渠道，并将公司置于库尔纳而非命名的数据中心市场。
这并不使公司与托管容量无关。本地 ISP 通常承载的不仅仅是零售宽带。他们可能托管客户网站、运行缓存和媒体服务、提供办公网络、放置客户设备、销售管理链路、支持闭路电视回传、维护本地机柜，或通过自己的自治系统传输业务流量。对于库尔纳的小型企业而言，“互联网提供商”和“云依赖”之间的实际区别可能很模糊。如果接入提供商还托管媒体服务器、维护地址空间、运行客户 DNS 或提供唯一经济的高速办公室链路，那么客户的数字服务仍然依赖于机架、电源、上游传输和维修人员。
因此，正确的问题不在于 Geeky Cloud 是否应与超大规模云平台比较。不应该。问题在于买家能否理解 Geeky Cloud 所销售容量背后的物理和合同层。公开答案是部分的。APNIC 记录显示 Geeky Cloud 拥有自己的 AS 号码和可移植地址资源。RIPEstat 显示这些资源在全球路由中可见。公司网站显示了一个活跃的零售和支持界面。但同一记录并未显示公共设施名称、机架所有权、除了一个观察到的邻居之外的多余上游、状态页面、维修目标、客户导出保证或透明的容量限制。
这种分裂是本文的核心发现。Geeky Cloud 并非空壳。它有一个可见的服务网站、可联系的联系页面和一个活跃的路由身份。它也不是公开记录为深度托管计算运营商。该公司应被视为一个真实的本地网络，具有有限的路由集合和围绕托管容量声明的薄保证层。这是一个有用但降级的类别：可信到可以调查，但证据太轻，无法在没有备份路径的情况下依赖。
公开网站指向库尔纳的接入，而非通用云控制台
可见的客户主张始于geekycloud.com.bd。该网站将 Geeky Cloud 呈现为库尔纳市的互联网提供商，提供家庭和办公室套餐、支持渠道、支付联系人和联系表单。其服务部分涵盖家庭互联网、企业互联网、专线互联网、闭路电视、网络设置和网络安全。套餐卡列出高达 40、50、70 和 100 Mbps 的速度，价格以孟加拉塔卡显示，使用光纤网络语言，宣传 BDIX 和 CDN 速度，按需 IPv6 和快速专用支持。这是本地接入和管理网络提供商的语言。
主页还提供了一些运营线索。首先，它强调账单支付和连接的责任使用，这是常见的零售 ISP 领域。其次，它突出 4K 流媒体、游戏、Facebook、BDIX 和 CDN 速度，这些对家庭或小型办公接入客户都很重要。第三，它列出了热线、呼叫中心和支持号码，Bkash-Nagad 商户支付详情和 WhatsApp 联系。第四，它列出了办公地点：总部位于库尔纳 Nirala 住宅区 2 号交叉路 4 路 10 号，邮编 9100，以及在 Gollamari 和 Bagmara 的分支办公室。这些细节很有用，因为它们将服务扎根于本地维修地理。
该网站确实包含一个“媒体服务器”条目，并且媒体服务器页面返回一个活动页面。这对于本地内容交付和客户体验很重要，特别是在孟加拉国，BDIX 链路流量和本地缓存性能可以塑造感知质量。但媒体服务器链接不等于公共云产品目录。公开网站没有显示 VPS 计划、裸机服务器库存、命名的数据中心区域、存储快照、虚拟网络控制、API 文档、实例系列、备份导出条款或自助云面板。它首先销售连接。
联系界面也是活跃的。联系页面返回客户表单和支持上下文。相比之下，常见的路由猜测如支付、关于和套餐页面在此次审查中返回了 404 错误，尽管套餐内容在主页上可见。这本身不是重大缺陷。小型 ISP 网站通常将大部分内容保持在一个页面上。但这确实显示了买家为何应避免将菜单标签视为成熟服务资产的证据。重要的页面是实际存在且解释服务的页面。
geekycloud.net域名增加了另一层。它重定向到 geekycloud.com.bd 并通过 Cloudflare 前端，而最终的.com.bd 页面直接来自 Apache Web 服务器，位于 Geeky Cloud 自身可见的 103.175.17.0/24 前缀之外的单独地址。因此，网站路由与客户接入网络路由不同。访客可以通过一个路径访问公开网站，而订阅者的互联网接入、媒体服务器会话或路由地址空间依赖于不同的路径。这种区别对于故障分析很重要。
最简单的解读是，Geeky Cloud 的公开面孔是一个服务于库尔纳客户的 ISP 和管理连接品牌。托管容量可能存在于媒体、本地服务、客户网络设备或商业连接周围，但公开页面并未将其验证为广泛的云平台。因此，本文将“云”名称视为需要通过路由和依赖证据检验的主张，而不是云风格弹性的保证。
注册记录赋予 Geeky Cloud 真实的网络身份
最强硬的证据在 APNIC。APNIC RDAP 记录 AS148974将注册人标识为 Geeky Cloud 并将 AS 置于孟加拉国。APNIC whois 查询 AS148974给出 aut-num 为 AS148974，AS 名称为 GEEKY-AS-AP，描述为 Geeky Cloud，国家 BD，组织为 ORG-GC26-AP，维护者为 MAINT-GEEKY-BD。它还列出了与 Geeky Cloud 的 ipabu 邮箱关联的滥用联系人，并显示 aut-num 最后修改于 2022 年。
组织记录同样具体。同一 AS 查询下的 APNIC 输出将 ORG-GC26-AP 标识为 Geeky Cloud，组织类型为 LIR，国家 BD，并提供库尔纳地址。单独的APNIC 维护者查询 MAINT-GEEKY-BD将维护者与孟加拉国的 Geeky Cloud 关联，并指向同一管理联系人系列。APNIC RDAP IPv4 记录和APNIC IPv4 whois 查询标识 103.175.17.0/24 为 GEEKY-BD，描述为 Geeky Cloud，国家 BD，状态为已分配可移植。APNIC RDAP IPv6 记录和APNIC IPv6 whois 查询标识 2001:df7:e680::/48 为 GEEKY-BD，描述为 Geeky Cloud，国家 BD，状态为已分配可移植。
这些都是有意义的事实。AS 号码和可移植地址记录本身并不能证明客户数量、机柜位置或服务质量，但它们确实显示了通过 APNIC 记录而非仅营销网站控制的网络身份。对于 ISP 来说，这很重要。这意味着存在一个可观察、可测量并绑定到公共注册联系人的路由身份。它还为客户和同行提供了一个可以发送滥用、故障排除和路由问题的地址。
注册日期对成熟度背景有用。IPv4 和 IPv6 资源记录可追溯到 2021 年 10 月，而组织和联系人记录有后续更改，包括 2026 年的组织更新和滥用验证。这表明运营记录比新着陆页更老。它没有告诉我们网络如何变化、多少客户活跃，或者公司是否已扩展到本地接入之外，但它确实建立了公共互联网号码记录的连续性。
警告是规模。一个 IPv4 /24 包含 256 个地址。一个 IPv6 /48 对于接入网络来说是为客户和基础设施编号的正常大小，但它仍然是一个单一的可见 IPv6 分配。一个提供商可以用这个足迹服务真实客户。从公开数据来看，不能将其描述为具有许多可路由块、多个边缘位置或多个独立地址池的广泛托管平台。注册记录赋予 Geeky Cloud 实质内容。它也框定了外部人员可验证的上限。
路由数据显示同时的可达性和集中性
RIPEstat 确认 Geeky Cloud AS 是活跃的。AS148974 的 AS 概览报告该资源已被宣布并将持有者标识为 GEEKY-AS-AP - Geeky Cloud。宣布前缀视图显示在观察窗口期间有两个当前资源：103.175.17.0/24 和 2001:df7:e680::/48。AS 路由状态视图报告一个 IPv4 前缀、256 个 IPv4 地址、一个 IPv6 /48 和一个观察到的邻居。
这种组合是档案中最重要的技术事实。网络是可见的。路由集合很小。邻居计数是集中的。本地接入网络可以在单上游交接点稳定、容量充足且本地适当时工作得很好。但买家不应将“全球可见”与“独立弹性”混淆。如果观察到的唯一上游路径发生故障、被过滤、拥塞、出现电源问题、政策争议或撤回路由，Geeky Cloud 客户需要要么此数据中不可见的隐藏备份路径，要么手动恢复计划。公开记录没有证明任何一种。
前缀级数据支持相同的解读。RIPEstat 前缀概览 103.175.17.0/24报告该前缀由 AS148974 宣布并绑定到 Geeky Cloud。103.175.17.0/24 的路由状态视图显示来源 AS148974、APNIC 路由对象覆盖范围和查询时对该视图中完整 IPv4 对等集的可达性。2001:df7:e680::/48 的前缀概览类似地报告该 IPv6 前缀由 AS148974 宣布，而IPv6 路由状态视图显示来源 AS148974 和报告集中的完整 IPv6 可达性。
路由来源安全是一个积极信号。103.175.17.0/24 的 RPKI 验证结果报告 AS148974 的有效来源，最大长度 24。2001:df7:e680::/48 的 RPKI 验证结果报告有效来源，最大长度 48。这减少了路由来源歧义。它不证明正常运行时间、备用容量、干净地址声誉、DDoS 容忍度或快速修复。这是卫生，不是弹性。
观察路径数据指向上游边界。103.175.17.0/24 的 RIPEstat looking-glass 视图显示收集器路径以 AS139901 结束，然后到 AS148974。2001:df7:e680::/48 的 looking-glass 视图在 IPv6 样本中显示相同的有效交接。AS139901 的 RIPEstat whois 视图和APNIC 查询 AS139901将该上游 AS 标识为孟加拉国的 Apple Communication Ltd.。AS139901 可能是库尔纳接入提供商的合理上游，但公共视图仍然集中了维修问题：当该上游交接受损时会发生什么？
RIPEstat AS 路由一致性视图增加了另一个有用线索。它报告两个前缀在 BGP 和 whois 中都存在，并将 AS139901 标识为在 BGP 中看到但未在 whois 策略视图中列为导入/导出对等体的对等体。这在 APNIC 地区记录中并不罕见，注册策略可能稀疏。这确实意味着买家应依赖观察数据和直接提供商答案，而不是假设注册策略列出所有实时连接。
机架和传输是套餐卡背后的产品
Geeky Cloud 的零售套餐卡销售速度和支持，但交付的服务依赖于物理资产。库尔纳的家庭或办公室连接需要最后一英里光纤、接入交换机、分路器或机柜、汇聚设备、回传、电源、监控、备用光模块、现场技术人员以及连接更广泛互联网的途径。如果公司还支持媒体服务、闭路电视网络或托管客户设备，那么机架、服务器、存储、本地缓存容量和设施冷却成为服务的一部分，即使客户从未看到它们。
公开网站说光纤网络、BDIX 和 CDN 速度、按需 IPv6 以及专线服务的多条上游或备份。这些对用户是有价值的声明。它们也需要谨慎解读。“BDIX 和 CDN 速度”告诉客户本地或缓存内容可能表现良好，而不是每条国际路由都不拥塞。“按需 IPv6”令人鼓舞，因为 IPv6 前缀可见，但它不证明每个接入计划默认接收 IPv6 或客户路由器配置正确。“多条上游和备份”是一个服务声明，而公共 BGP 视图目前显示 AS148974 有一个观察到的邻居。这两个事实可以共存，如果备份路径是私有的、休眠的、手动的、仅下游的或不在观察窗口内，但公开证据不证明活动多样性。
物理地理很重要。Geeky Cloud 列出库尔纳办公室，APNIC 记录将其联系人放在库尔纳。这对于本地支持很有用：现场团队可以到达客户站点、修复光纤断裂、更换客户设备和收款。它也造成了本地集中。服务区域的电源事件、光缆切断、道路工作问题、汇聚故障或恶劣天气事件可能同时影响许多客户。记录没有命名主要存在点、离开库尔纳的回传路由、电源备份安排、发电机运行时间或路由设备所安置的设施。
网站本身不是接入网络的可靠代理。最终的.com.bd 网站在本地 DNS 检查期间解析为 5.77.50.137，而.net 域名由 Cloudflare 前端并重定向到.com.bd 网站。这意味着营销和支持页面可能位于 Geeky Cloud 自身可见地址空间之外的托管栈上。这很常见，通常也是合理的。这也意味着网站正常运行时间不证明用户网络健康。用户可能失去访问，而公共页面在其他地方保持在线，或者公共页面可能失败而用户仍然正常路由。
对于托管容量买家，关键问题是安装容量与可用容量。提供商可能有足够的接入带宽应对普通峰值模式，但没有足够的备用容量应对异常重的客户。它可能有本地媒体容量但有限的服务器库存。它可能有一个公共 IPv4 /24 并需要仔细分配公共地址。它可能支持 IPv6 但仍依赖于客户设备、上游策略和支持实践来使 IPv6 有用。这些限制都不是不合格的。它们只是意味着套餐卡是邀请提出运营问题，而不是完整的可靠性合同。
上游故障路径是需要测试的首要风险
第一个要测试的故障路径是上游可达性。公共 BGP 视图指向 AS139901 作为 Geeky Cloud 的观察邻居。如果 AS139901 有维护事件、路由过滤器问题、拥塞、商业纠纷或电源问题，Geeky Cloud 的公共前缀可能受到影响，除非另一条路径已就绪。将 Geeky Cloud 用作唯一办公室连接、唯一媒体路径或唯一托管访问依赖的客户应询问是否存在另一条传输路由，故障切换是否自动，以及恢复通常需要多长时间。
第二个故障路径是本地汇聚。本地 ISP 可以有干净的全球路由，而邻居交换机、机柜、接头、OLT、无线回传或办公室汇聚链路故障。Geeky Cloud 的网站强调家庭、企业和专线互联网，这意味着现场维修与路由同等重要。客户需要知道故障单如何优先处理，热线在正常时间外是否有人值守，业务链路如何升级，以及专线计划是否获得与家庭计划不同的维修目标。
第三个故障路径是电源。小型网络的最弱点通常不是路由器配置。而是办公室、存在点、机柜、客户楼宇或上游交接处的电力。公共页面没有公布发电机、电池或双路馈送信息。它也没有按服务层分离正常运行时间声明。公共套餐卡上的 90%正常运行时间声明不是托管服务的正式高可用性目标。事实上，如果严格解释，90%可用性将允许比大多数企业客户预期多得多的停机时间。买家应询问每个服务正常运行时间意味着什么以及测量周期。
第四个故障路径是地址稀缺。一个 IPv4 /24 可以通过 NAT、共享地址计划和谨慎分配支持本地接入网络，但公共 IPv4 是有限的。如果客户需要静态公共寻址、反向 DNS、邮件投递、服务器托管或入站访问，提供商必须分配稀缺地址并管理声誉。单个受损地址块可能影响邮件、支付、登录风险检查以及内容访问。RPKI 有效性有助于保护来源合法性；它不保护声誉或保证替代地址。
第五个故障路径是客户退出路径。接入客户有时可以切换 ISP，但业务迁移很少是即时的。公司可能依赖 Geeky Cloud 公共 IP、闭路电视回传路由、本地媒体依赖、DNS 条目、客户路由器配置或支付时机。如果服务持续多天失败，客户能带走什么？公共页面没有发布可移植性或配置导出承诺。谨慎的买家保留提供商外的配置笔记、备用接入、独立 DNS 以及当前绑定到链路的任何服务器或应用的备份。
第六个故障路径是服务前门。联系和媒体页面是活跃的，而一些路由猜测返回 404。这提醒客户沟通不应依赖单一网页路由。如果客户无法访问网站，电话、WhatsApp、电子邮件和实体办公室渠道成为弹性的一部分。相反，如果电话渠道在本地故障期间过载，缺少公共状态页面可能让客户猜测。本地提供商可以通过发布简单的状态页面和故障历史快速提升信任。
接入套餐对托管经济学说什么
Geeky Cloud 的公开价格按企业连接标准是低的，但对本地零售市场有意义。主页列出每月家庭套餐约为 630、735、1050 和 1575 塔卡，对应可见速度档次，套餐卡中包含 5%增值税。承诺的价值不是深度云自动化；而是实惠的接入、本地性能、支持和一系列使家庭和办公室互联网感觉可用的邻近服务。
这个价格阶梯塑造了客户应期待的内容。一个低月费接入计划不能包括无限定制工程、自定义路由、专用支持人员、每个边缘案例的备用硬件和企业风格服务信用，除非这些功能单独定价。提供商必须标准化。它必须重用接入设备、支持脚本、路由器模板、计费流程和现场访问。这是正常的 ISP 经济学。只有当客户将基本接入产品用作托管高可用性平台时，它才变得有风险。
专线互联网部分与业务依赖更相关。Geeky Cloud 说专线高速互联网附带多条上游和备份语言以及 90%正常运行时间参考。企业买家应书面澄清该声明。“专线”是指承诺带宽还是仅计划类型？备份是指来自同一位置的第二条上游、第二条物理路径、无线备份还是支持承诺？备份是活动的、热备用还是手动的？正常运行时间数字适用于客户链路、提供商核心、上游、网站还是整个服务？页面没有回答这些问题。
BDIX 和 CDN 速度声明也属于托管经济学。本地交换和缓存内容可以改善流媒体、软件下载、社交媒体和流行内容。它们不保证对每个远程目的地的性能。托管服务于孟加拉国以外用户或依赖国际 SaaS 的客户需要测试对该工作负载重要的路径。RIPEstat AS 路径长度视图显示来自许多收集器位置的路由观察，但路径长度不是客户性能保证。这是一个路由可见性线索。
APNIC Labs 市场信号也应谨慎使用。APNIC Labs 孟加拉国 AS 人口表在 2026 年 7 月 1 日将 AS148974 置于孟加拉国表，估计有 5,089 用户和很小的全国份额。这是一个测量估计，不是用户申报。它表明 Geeky Cloud 在 APNIC Labs 数据中有可见用户流量，但不能确定客户数量、收入、容量或业务健康。它作为 AS 并非纯粹装饰的信号是有用的。
公开经济图像因此是适度且连贯的。Geeky Cloud 似乎是一个真实的本地接入提供商，具有路由资源、零售套餐阶梯、媒体服务界面和本地办公室。这可以支持实际的客户价值。它不支持 Geeky Cloud 拥有大量云库存、广泛的多区域弹性或丰富的托管计算资产的说法。买家应将工作负载风险与价格和公开证据对齐。
数据本地性既是卖点也是问题
数据主权和本地性不仅是国家法律问题。对于本地 ISP，本地性意味着流量在哪里交换、客户记录在哪里、托管内容在哪里存储、支持员工在哪里工作以及哪些方可以影响服务。Geeky Cloud 的服务区域在呈现上明显是本地性的。办公室、套餐价格、支持联系人和库尔纳语言指向孟加拉国客户。APNIC 资源在 BD 注册。可见上游是一个孟加拉国 AS。这些事实支持本地连接解读。
同时，网站路径使本地性复杂化。.net 域名在 Cloudflare 后面并重定向到 geekycloud.com.bd。最终的.com.bd 网站托管在 Geeky Cloud 可见 APNIC 分配之外的地址上。geekycloud.com.bd 的 TLS 证书由 Let's Encrypt 颁发。这些都不罕见。许多本地提供商在其他地方托管网站，使用全球 DNS 和证书服务，并将客户流量与公共营销页面分开。但如果客户关心账户数据、联系表单消息、支持日志或支付引用存储在哪里，公共页面没有提供完整答案。
同样的问题适用于媒体和托管容量。媒体服务器可以是本地 ISP 网络、第三方数据中心、合作伙伴缓存后面，或者从另一个网络提供服务而通过 ISP 网站链接。公共媒体服务器页面证明了一个可见界面，而不是其位置、所有权或存储实践。客户应询问媒体内容存储在哪里、谁运行服务器、用户数据如何记录以及媒体系统不可用时会发生什么。
对于企业客户，本地性还包括法律和运营责任。Geeky Cloud 的公开网站使用孟加拉国域名、库尔纳地址和 BTRC 批准的 ISP 语言。APNIC 列出孟加拉国组织和孟加拉国联系人。这给客户提供了本地责任路径。但公开记录没有显示完整合同、隐私政策、数据保留声明、备份政策、子提供商列表或正式服务级别条款。如果客户将链路用于敏感业务系统、闭路电视回传、健康数据、支付或公共服务，则这些差距很重要。
IPv6 是一个带有警告的亮点。Geeky Cloud 有一个可见的 IPv6 /48 并在套餐卡中宣传按需 IPv6。许多小型接入提供商在 IPv6 上落后，因此可见 IPv6 是积极信号。但“按需”意味着客户可能必须要求，支持实践将决定它是否干净地工作。客户应验证前缀大小、路由器配置、防火墙默认值、如果需要则反向 DNS，以及 IPv6 支持在套餐更改后是否持续。
本地数据结论是平衡的。Geeky Cloud 有足够孟加拉国和库尔纳证据被视为本地接入提供商，而不是匿名的海外云品牌。但本地性在托管或客户数据层未完全文档化。关心本地性的客户需要询问主页之外的问题：机架在哪里、备份在哪里、日志在哪里、上游交接在哪里、谁能恢复服务？
客户在依赖 Geeky Cloud 之前应验证什么
低风险家庭用户可能不需要长时间尽职调查。如果服务便宜、足够快且本地支持，实际测试是它在地址是否有效。但这里的任务是托管容量和依赖，所以买家画像更严格：小型企业、学校、诊所、开发者、商店、媒体用户或办公室，可能依赖 Geeky Cloud 不仅仅用于随意浏览。
第一个验证项目是确切的服务边界。客户只购买互联网接入，还是也包括托管存储、媒体服务、静态 IP、管理路由器、防火墙、闭路电视回传或服务器放置？每一层有不同的故障模式。公开网站将多个服务捆绑在一个品牌下，因此买家应请求所购买服务的书面描述以及排除的部分。
第二个验证项目是上游多样性。请求 Geeky Cloud 识别业务和专线计划的实时上游安排，解释 AS139901 是否是全球表中唯一的生产交接点，并说明在上游故障期间会发生什么。如果提供商有备份连接，询问它是否在 BGP 中活动、手动启用、仅对某些客户可用或仅用于办公室运营。答案应是运营性的，而非仅仅商业性的。
第三个验证项目是电源和设施弹性。询问服务客户的主要设备位于何处、电池能维持多长时间、发电机是否可用、现场机柜是否有备用电源以及上游交接是否共享相同电源域。提供商可以有有效的路由，但仍然在电源层失败。
第四个验证项目是维修人员。Geeky Cloud 宣传快速支持并提供热线、WhatsApp 和办公室联系路径。客户应在关键迁移前测试响应。开一个非紧急工单、打热线、询问故障如何升级，并确认企业客户是否获得与住宅计划不同的处理。本地提供商的力量可以是现场响应能力；学习它的唯一方法是测试它。
第五个验证项目是地址处理。如果客户需要公共 IPv4 地址，询问它是否专用、共享、静态、在计划更改间可移植、不受声誉问题影响并附带反向 DNS（如果需要）。对于 IPv6，询问委托的前缀大小以及它在路由器更换后是否持续。如果服务将托管入站应用，在依赖之前从外部网络测试。
第六个验证项目是备份和退出。如果 Geeky Cloud 托管任何客户服务，客户应维护独立备份和文档化的重建步骤。如果 Geeky Cloud 仅是接入提供商，客户仍应为关键工作保留移动或第二个固定线路备用。依赖风险不会通过本地提供商关系消除；它通过在第一路径失败时有第二条路径来管理。
什么会改善公开证据等级
Geeky Cloud 可以在不透露敏感细节的情况下显著改善公开保证。一个命名当前上游、对等状态、IPv4 和 IPv6 资源以及广泛服务区域的网络页面会有帮助。一个公共状态页面会有更大帮助。即使是一个将计划维护、接入事件、上游事件和媒体服务事件分开的简单页面，也能让客户区分网站问题和网络问题。
SLA 页面也有帮助，只要它定义测量。当前的公开套餐语言对于业务依赖来说太宽泛。一个更强大的页面会说哪些计划有正常运行时间目标、什么构成停机、如何宣布维护、适用什么信用以及哪些事件被排除。它将家庭接入与专线业务链路和任何托管服务分开。
设施和电源声明会有帮助。Geeky Cloud 不需要发布精确机架坐标。它可以说核心网络是否托管在自有场所、租赁托管、上游设施还是混合体。它可以说明主要站点是否有电源备份，以及分支办公室是仅面向客户还是也是网络运营的一部分。这将减少围绕维修窗口的不确定性。
数据和可移植性声明会有帮助。对于任何媒体、托管或客户设备服务，公司可以说谁拥有数据、日志保留多久、如何处理备份、客户是否可以导出配置以及服务如何终止。这样的声明对于将 Geeky Cloud 视为不仅仅是宽带线路的企业客户很重要。
最后，路由透明度页面会有帮助。Geeky Cloud 已经有公共 APNIC 记录、有效 RPKI 和可见 IPv6。发布一个简短的路由说明可以让客户理解为什么公共表显示一个观察到的邻居、是否存在备份以及提供商如何处理路由事件。对于这种规模的网络，透明度可能比规模更有价值。
结论
Geeky Cloud 应被解读为一个真实的、以库尔纳为中心的网络提供商，拥有公共互联网号码资源、实时路由和面向客户的地方服务网站。证据比仅名称的目录条目更强。APNIC 标识了 AS148974 和 GEEKY-BD 资源。RIPEstat 显示该 AS 宣布了一个 IPv4 /24 和一个 IPv6 /48。两个可见前缀的 RPKI 验证均有效。公开网站销售家庭、企业和专线互联网，宣传 BDIX/CDN 性能以及按需 IPv6，并提供本地支持和办公室详情。
证据仍然不足以将 Geeky Cloud 称为已证明的云基础设施运营商。公共路由集合很小，观察到的邻居计数为一，PeeringDB 在PeeringDB API 查询中没有 AS148974 的公共网络配置文件，并且网站没有发布 VPS、裸机、存储、备份、设施、事件或传输多样性细节。公开网站和路由客户网络似乎也是分开的路径，这是正常但重要的。
这使得当前等级为中等而非强。Geeky Cloud 有真实的网络证据、活跃的服务界面以及孟加拉国本地运营信号。降级来自薄弱的公开托管容量记录和集中的路由视图。客户可以将 Geeky Cloud 用于适当的本地接入和低风险的托管邻近需求，但不应在没有独立备份、备用连接、经过测试的 IPv6 和 IP 分配、支持升级细节以及清晰迁移计划的情况下使其成为业务系统的单点故障。