随着商业 VPN 市场日趋成熟，大多数 VPN 提供商都拥有完善的、可追踪的基础设施，我们开始看到一些新颖的方法来构建和维护 VPN 服务器群，从而挫败传统的检测方法。

#@#One of these approaches is known as a quantumult下载 or dVPN for short. These are where quantumult下载 company doesn't own and operate quantumult下载 servers they sell access to and instead, they act as a broker between consumers seeking to use quantumult下载 and "node operators" who make available their internet connections for rent.#@#

对于绝大多数 dVPN 服务来说，它们的去中心化基础设施仍然可以像其他 VPN 服务一样被发现并添加到我们的数据库中，但其中一些服务却增加了难度。 我们今天重点关注的 MysteriumVPN 就是这样一种服务，它有一个复杂的代理系统，利用令牌地址来掩盖节点操作员。

更具体地说，在MysteriumVPN'的情况下，在你向Mysterium'的经纪人支付一些名为Myst的加密货币之前，你无法获得其VPN节点的IP地址，而Mysterium'的经纪人会将你连接到单个节点运营商。 从本质上讲，这意味着你必须向每个节点操作员支付少量加密货币，才能获得 Mysterium 经纪人提供的节点 IP 地址。

这种独特的方法意味着，一段时间以来，Mysterium 节点一直未被发现，其在互联网上的滥用已达到严重程度。 从绕过流媒体网站的地理位置限制，到盗取网站内容，再到利用窃取的支付信息进行欺诈交易，这些节点都能提供便利。

正因为如此，我们对 dVPN's 特别感兴趣，整个七月，我们都在开发新的工具来更好地处理它们。 这就是今天的主题，我们希望与大家分享我们在 dVPN 方面的工作，特别是与大家分享 Mysterium，因为它是该领域最大的公司。

上图是新的 Mysterium 操作员卡的样子，你会发现通过我们的 API 显示的该 VPN 服务的地址，风险分数从 73% 开始提高。 风险分数的升高反映了我们认为这些地址所带来的危险，因为 Mysterium 不仅是一项完全匿名的服务，而且由于难以发现这些地址，我们的服务（如我们自己的服务）也无法检测到它们，而且大多数地址都是通过住宅地址范围托管的，因此它已成为吸引犯罪分子的磁铁。

目前，我们每天索引数千个节点，预计到本月底将检测到排名前 10 的 dVPN 提供商所提供的 95% 的节点。 我们还想借此机会感谢在过去几个月中提供了他们确信属于代理或 VPN 网络的 IP 地址的客户，我们能够将其中许多地址与 dVPN 运营商匹配，从而扩大了我们的检测能力。

感谢您的阅读，祝您周末愉快！

今天，我们为以下功能推出了几项新功能仪表板使您更容易管理自定义规则和自定义列表，尤其是当您像我们的一些客户一样拥有大量自定义规则和自定义列表时。

首先，我们缩小了条目之间的空间，这样就可以在垂直堆叠中同时查看更多条目。 这只是一个小改动，但同样有益。 你可以从下面的截图中看到这一点。

其次，我们在规则和列表的顶部添加了一个新按钮，它将在堆栈顶部而不是底部插入新条目。 因此，您现在可以添加新条目，而无需滚动到堆栈底部，然后再将规则拖到顶部。

第三，我们添加了一个新按钮，可以隐藏任何已禁用的规则或列表。 我们知道，许多用户喜欢创建情景规则或列表，并在需要时才将其禁用，因此，您的规则或列表界面可能会变得杂乱无章。 昨天才有一位客户要求使用这项功能，我们很高兴将其纳入今天的 "超级用户 "更新中。

第四项也是最后一项功能是过滤字段，您不仅可以根据规则和列表的名称，还可以根据它们的内容进行搜索。 因此，如果您创建了针对特定国家的规则或包含特定地址的列表，您就不再需要仔细检查仪表板中的每条规则或列表来查找它们，而只需根据其中的信息进行搜索即可。 下面是我们根据规则中包含的 ISP 沃达丰过滤特定规则的示例。

如今，所有新的强大用户功能都完全使用客户端 Javascript，这意味着它们不仅无需刷新页面即可实时运行，而且速度快得令人难以置信，在适当的地方还能以动画的形式流畅地传达出某些内容已被隐藏但未被删除等信息。

希望您喜欢今天的更新，感谢您的阅读，祝您本周愉快！

这是一篇简短的文章，让您知道在 6 月 6 日至 15 日期间，我们的北美服务区出现了间歇性的性能回归。

造成这一问题的原因是我们代码中的一个回归，当应用程序接口处于高负载条件下时，该回归会显著增加数据库排队时间。 我们是在 6 月 8 日从一位客户那里首次了解到这个问题的，但当我们进行调查时，高负载情况已经停止，因此很难复制和诊断问题的原因。

不过，今天我们能够实时查看性能下降情况，这使我们能够正确诊断并解决代码问题。 截至发稿时，一切问题都已解决，API 再次以稳定的低延迟回答所有查询。 我们要感谢给我们发送信息的客户，如果没有你们的帮助，我们不会这么快就发现问题：)

感谢您的阅读，祝您度过愉快的一周！

今天，我们发布了位置数据的大型更新，不仅提高了所有位置数据的准确性和精确度，还增加了以前没有的 IP 地址数据。

这包括地区、城市和邮编数据。 我们已经为此努力了一段时间，任何使用我们开发分支的人都可能注意到，直到今天早上，一些地址提供的位置数据与我们的稳定版本不同，而且更加完整。

我们希望向尽可能多的用户提供新数据，因此我们从 2020 年 8 月开始，将新代码移植到 v2 API 的每个版本。 如果您使用的是之前的版本，则需要在客户仪表板中更改所选的 API 版本。

在这次更新中，我们还重写了 IP 地址元数据的存储和访问方式，这样我们就能消除一个额外的数据库读取操作，从而提高 API 性能，即使只是略微提高。

以上就是今天的更新内容，感谢您的阅读，祝您本周愉快！

在计算机领域，完全重写有很大的阻力，原因有很多，包括成本、时间、可能出现的新错误和功能倒退。

相反，软件行业更喜欢我们所说的 "重构"（refactoring），即对现有代码进行改进，在很长一段时间内做出许多微小的改动，这样每次改动都可以更容易地实施，并以可控的方式衡量这些改动的结果。 简而言之，这种方法速度快、成本低、见效快，而且降低了出现问题的可能性。

但有时可能需要完全重新架构一个系统，原因可能有很多。 你需要更高的性能，你需要将代码更好地扩展到更多的计算资源，新硬件的出现导致旧代码运行不佳或根本无法运行，新的程序库、操作系统或执行环境与你的旧代码不兼容等等。

而上述许多情况都可能导致改写。

今年，我们发现自己从 2017 年开始编写的一些后端软件正是如此。 这些软件是为特定操作系统（Windows Server）设计的，这意味着我们利用了一些微软特定的操作系统功能，这使得我们的代码与 Linux 不兼容。

我们在设计软件时还考虑到了当时所能使用的某些硬件，即低核心数处理器和使用硬盘驱动器的慢速存储。 这导致我们的很多后端系统在使用硬件时都比较保守，这意味着大部分都是单线程操作和串行数据访问。

我们目前的服务器平均拥有 23.5 个 CPU 线程，而当我们讨论的大部分代码创建时，我们最大最好的服务器只有 8 个 CPU 线程。 说到存储，我们以前使用的硬盘只能处理 800 IOP's，而现在我们使用的 NVMe SSD 可处理 120 万 IOP's。

我们希望重写代码，使其与处理器无关，与操作系统无关，同时更好地利用我们最新（以及未来）的硬件，这就需要重写一些代码。 当然，我们可以重构一些旧代码，在许多较小的情况下，我们也是这么做的，但对于最重要的东西，重写才是正确的方法。

那么，如何以正确的方式重新构建软件呢？

首先，您需要对要重写的系统进行全面的代码审查。 这包括阅读所有代码，理解并记录代码执行的所有任务以及执行这些任务的原因。 这一点至关重要，否则你就会忘记在新重写的代码中加入之前迭代中包含的功能。

其次，您要找出代码中需要改进的所有不足之处。 这可能是杂乱无章或无法管理的代码，也可能是性能不佳或无法实现当前或未来目标（如将您绑定到特定操作系统）的非生产性代码。

第三，你要计划如何改进代码，以实现新程序的目标。 对我们来说，这主要包括使程序多线程化、更好地利用存储系统的 I/O 功能、不使用任何 Windows 操作系统特有的功能或 Linux 上无法使用的功能。 当然，所有这些工作的最终结果是增加了可扩展性和灵活性。

第四，最后是编写和测试代码。 我们在开发过程中进行了大量的测试，以检验我们的许多假设，这也为我们的设计过程提供了参考。 当我们了解到某些解决问题方法的能力时，我们所做的决定也随之改变。

让我们来看看其中的一些。

1：大约两年前，微软终止了对 WinCache 的支持，而 WinCache 是 PHP 的内存数据存储。 我们大量使用了它，因此我们必须建立一个替代品。 因此，我们在两年前编写了我们称之为 ramcache 的软件。 它的作用与 WinCache 相同，并重新实现了 WinCache 的所有功能。 我们还扩展了它的功能。 例如，WinCache 有 85MB 的内存限制，而我们的 ramcache 没有这种限制。 我们还使其与操作系统无关，也就是说，它可以在包括 Linux 在内的任何系统上运行。

2：网络钩子。 我们使用了大量 Webhooks，主要用于与付款相关的事件，例如在付款被拒或即将付款时向您发送电子邮件，但我们也使用 Webhooks 来处理我们认为时间紧迫的事件，例如当您在仪表板中进行更改时，必须快速传播到所有集群节点。

3：我们的数据库同步系统。 同步数据库一度导致处理器使用率高达 70%。 在我们升级到配备更快处理器的系统后，这一比例确实有所下降，但仍然非常高，而且随着客户每分钟产生的数据量越来越多，使用率也在稳步上升。 在这种情况下，我们开发了一个名为 Dispatcher 的新进程来处理这些流量，从而将处理器使用率大幅降低到 0.1%。

#@#4: Cluster management, node health monitoring & node deployment. Before our rewrite, this heavily relied on Microsoft-specific operating system features, especially the node health monitoring and node deployment features. We've now rewritten all of these to also be operating system agnostic and processor independent.#@#

让我们来看看一些净结果。 以前，我们的网络钩子（即一台服务器专门向集群中的一台或多台服务器发送一个小更新）平均需要 6 秒钟才能完成整个集群的更新。 新代码在使用网络时采用了多线程技术，将这一时间缩短到了 0.3 秒。 性能提高了 20 倍。

说到 Dispatcher，这对我们来说是一个巨大的改变，因为使我们的服务器保持同步的一切都使用了我们以前的系统。 旧系统包罗万象，甚至连名字都没有，因为它并不是一个特定的对象，代码中穿插了许多其他功能和特性，在我们的代码中几乎无处不在。

有了 Dispatcher，这一切都改变了，它为我们数据库的读写提供了一个标准化接口，并为我们的集群节点提供了一个框架，通过使用打包节点更新和为每个地理区域临时选择一个主节点作为数据库更新的收集器、处理器和分发器，以最被动（因此也是最不耗费资源）的方式提供数据。

你可以把调度程序想象成一个火车网络。 每个节点都运行着自己的列车，列车不停地在轨道上绕行，前往所有其他节点获取数据。 主节点从非主节点获取数据，对数据进行处理，然后仔细决定数据应插入数据库的哪个位置。 然后，主节点对数据进行重新打包，并提交给从非主节点拾取这些更新数据的列车。

每隔几分钟，节点就会进行一次投票，选出空闲资源最多、正常运行时间最长的节点作为该地理区域的主节点。 我们通过明确定义容器、合并冲突解决方案和围绕结构化 1 分钟时间表建立的数据库，来阻止因多个主节点同时发布更新而产生的冲突。

现实世界中的每一分钟都在数据库中进行记录，并为该分钟和地理区域附加一个主节点。 该节点且只有该节点可以执行维护和更改操作，除非各节点同意将其从该分钟中移除并指定另一个节点，从而允许另一个节点成为该分钟的主节点。 任何节点都可以读取分钟数据，但只有主节点才能执行更改和写入操作。

所有这一切的结果就是一个高性能的数据库同步系统，无论我们拥有多少服务器节点，它都能进行扩展，最重要的是，它能将处理器和存储设备的负担降到最低。

在进行所有这些代码重写和重构的同时，我们还研究了新技术，并为我们编写的代码调整了执行环境。 为此，我们将整个服务（包括所有网页）升级到了最新的 PHP v8.2.6。 在升级过程中，我们还使用了自 PHP v8 以来的最新 JIT 编译器，因为我们发现整个网站的页面加载时间得到了大幅改善，而且没有出现任何倒退。

以上就是今天的更新内容，希望大家喜欢我们的工作和插图。

感谢您的阅读，祝您度过愉快的一周。

在这篇博文中，我们将介绍 proxycheck.io 的架构设计，并解释我们在构建服务的过程中做出的一些决定。 首先，什么是单体架构？

#@#Monolithic in software pretty much means running all your services on one or more beefy servers as opposed to breaking out your services into what is commonly referred to as microservices and having them distributed across many smaller servers or even running them on what is known as "serverless" or "edge" computing infrastructure. The idea behind the microservices approach is you remove a lot of overhead like managing an operating system, you only instead manage the specific application that you've developed.#@#

另一个好处是，您可以横向扩展微服务，也就是说，如果您需要为应用程序提供更多资源，您只需在另一个系统上启动另一个微服务副本，并在它们之间实现负载平衡。

不过，这种方法也有一些注意事项。 随着微服务数量的增加，基础设施中所有服务之间的网络活动量也会增加。 毕竟，每个服务都需要获取、处理数据并与基础架构的其他部分共享数据，而分担这一任务的服务器越多，需要保持同步的内容就越多。

当人们转向这些服务时，数据库流量往往被忽视，但它可能会变得非常大，以至于您无法再进行横向扩展，因为没有足够的资源来保持所有服务的同步。 除了这种复杂性之外，所有这些开销也会导致成本逐渐增加，这可能会使您认为用于为客户提供服务的资源所产生的初始成本黯然失色。

关于其他服务如何从微服务转向单体服务，Dropbox 甚至 Prime Video 都是很好的例子。最近分享了一篇有趣的博文讲述了他们在从微服务转向单体架构时如何将成本降低了 90%。 没错，这就是亚马逊的 Prime Video，他们使用亚马逊的 AWS 服务来运营他们的微服务。

引用亚马逊 Prime Video 的一句话

将我们的服务转为单体后，基础设施成本降低了 90% 以上。 它还提高了我们的扩展能力。 如今，我们能够处理数千个数据流，而且仍有能力进一步扩展服务；

因此，这不仅为他们节省了资金，还提高了他们的扩展能力，帮助他们用更少的服务器支持更多的用户。

我们从一开始就使用单体架构，因为尽管我们发现了微服务的优势，特别是使用 AWS'EC2 和 Azure 云可以快速扩展，但我们也发现了许多缺点。 单个服务的性能不高，也就是说单个请求的性能很差。

换一种说法，这种微服务方法就好比用 2000 个热气球代替 2 架巨型喷气式飞机。 当然，你可以让双倍的人乘坐热气球，但到达目的地所需的时间会更长。

这就是微服务模式的支撑点，它不仅让我们继续单片机模式，还让我们继续裸机模式。 当我们租用服务器时，我们是唯一的租户，我们可以选择硬件，我们通常会选择最快的硬件，我们一直在用新的服务器替换旧的服务器，新服务器的性能是旧服务器的 3 到 4 倍。

#@#Meanwhile, if you look at the past 5 years of "serverless" computing like EC2 the performance has remained pretty much the same driven by the service provider's desire to maximise the amount of customers per unit of compute resource available.#@#

对我们来说，速度至关重要。 例如，如果您将我们的客户仪表盘与使用云提供商和微服务的公司进行比较，您会发现我们的仪表盘会立即加载，并在眨眼间填充数据，而即使是像 OVHCloud 这样的最大公司，他们的客户仪表盘也要让您等待 10 秒钟以上才能填充信息。

我们并不认为微服务毫无用处。 当然，有些工作负载可以从这种方法中获益，尤其是需要大量工作人员且不需要即时结果的数据处理，以及任何可以通过专用固定功能硅加速的工作负载，例如视频转码、网络加密/解密、数据包路由。 所有这些任务都可以采用无服务器/微服务的横向增长方式。

但是，对于速度和延迟至关重要的任何面向客户的服务，我们却看不到同样的好处，用户在等待加载时会感到沮丧，服务的整体性能并不出色，成本可能会失控，数据同步方面的开销可能会造成严重影响。

我们希望这篇文章能引起大家的兴趣，因为我们最近发布的基础架构文章吸引了一些客户给我们留言，询问我们为什么不使用云提供商，而是继续使用裸机。

感谢您的阅读，祝您周末愉快。

今天是我们最后一次宣布有关服务器的消息，我们保证。

在过去的一天里，我们在北美服务区上线了两台新的高端服务器，分别称为木星和土星。

现在，这些服务器是我们为该地区提供服务的性能最高的服务器，每台服务器的性能都比我们以前的节点高出 6.27 倍，上周新增的 Lunar 节点除外，它本身也非常高端。

从整体性能升级的角度来看，我们的三个新服务器（月球、木星和土星）为我们提供了 100,000 单位的性能，而我们的旧服务器（莱托、克罗诺斯、梅蒂斯和尼克斯）只有 25,000 单位的性能。 从四台服务器到三台服务器，性能提升了 4 倍。

不过，我们还不会向 Cronus、Metis 或 Nyx 说再见，因为这些服务器的租约将在 7 月至 9 月间到期。 因此，在此之前，我们已经调整了负载平衡器，以分担负载，使 Cronus、Metis 和 Nyx 处理 25% 的北美流量，而我们的三个新服务器 Lunar、Jupiter 和 Saturn 将处理另外 75% 的流量。

这次升级不仅是为了给我们未来的发展提供喘息空间，也是为了应对我们自今年年初以来新增加的一些大客户。 我们已经看到，北美的流量从占我们每日流量的 35%（欧洲占其余部分）上升到 60%。 由于我们在本月早些时候引入了新的亚洲服务器，我们看到欧洲的流量有所下降，这是因为他们本应处理的一些亚洲流量转移到了亚洲地区的新专用服务器上。

因此，简而言之，我们需要加强美国的基础设施。 除了这一变化，我们还对每秒请求限制进行了调整。 在此之前，您可以每秒向任何服务器发出 100 次请求，然后才会收到警告；而在每秒发出 125 次请求之前，您的请求最多会被拒绝 10 秒钟。

由于我们的硬件性能有了新的提高，我们计划减少服务器的数量（同时使每台服务器的功能更加强大），同时我们也获得了很多大客户，因此我们决定将警告限制提高到 175，硬限制提高到 200。 限制器仍然只查看前 10 秒的请求量，因此如果时间足够短，您仍然可以超过这些限制。

从本质上讲，真正的限制将是 10 秒钟内的 2,000 次请求，无论所有这些查询是在一秒钟内进行的，还是分散在整个 10 秒钟内进行的。 这比我们之前规定的 1,250 次限制有所提高。 请记住，这是对每台服务器的限制。 因此，对于我们的北美服务器，当我们只有 3 台服务器时（少于当前的 6 台），10 秒内的请求次数限制将从 3,750 次变为 6,000 次。

这些新提高的限制也将有助于我们新成立的南亚地区，虽然我们在该地区只有两台服务器，但这两台服务器的性能加起来相当于 8 台上一代服务器，因此它们可以轻松处理这些提高的请求限制。

我们知道，像我们经常做的那样讨论基础设施并不是常规做法。 大多数服务都喜欢把这类事情扛在肩上，不与公众分享。 我们不想这样做，因为我们觉得这是建立任何业务的一个有趣的部分，我们希望您知道，您的付费订阅正被用于改善基础设施，最终为您提供所使用的服务。 我们部署的这些新服务器不仅会增加我们可以处理的流量，还会降低处理延迟，因此使用我们服务的每个人都将从中受益。

感谢您的阅读，祝您本周愉快！

今天，我们推出了名为 LUNAR 的新服务器，它将取代我们之前的服务器 LETO。 这台新服务器的性能比我们之前在北美部署的任何一台服务器都要高出三倍，而且与我们在上一篇博文中提到的在南亚部署的新服务器在物理上完全相同。

我们对这两个新节点的性能非常满意，这也是我们基于与这两个节点相同的硬件平台对北美服务器进行更新的原因。

如上所述，我们不仅仅是将 LUNAR 添加到我们当前的服务器名册中，我们还删除了 LETO，并用 LUNAR 取而代之。 我们想详细讨论一下我们这样做的原因，因为我们认为这对其他像我们一样构建弹性网络服务的人来说可能会很有趣。

首先，我们应该解释一下 LETO 是如何诞生的，以及它是基于什么平台。 当我们寻求增加北美地区的容量时，我们有一项自我规定的任务，那就是购买一台不仅性能高，而且由不同于我们主要使用的公司托管的服务器，这样我们就可以进一步丰富我们的基础设施。

与我们在欧洲使用三个地理位置不同的数据中心类似，我们也希望在北美使用同样的数据中心。 要找到一台速度够快、价格够低，并且由我们尚未使用的公司托管的服务器相当困难。

此外，由于性能、成本和安全等多种原因，我们一直以来都不使用云主机，这也增加了我们的压力。 换句话说，我们只使用裸机服务器，我们是机器上唯一的租户。

在继续搜索的过程中，我们发现美国有一家云主机提供基于 AMD EPYC 的最新一代虚拟机，而且价格非常诱人。 我们决定测试一下，结果发现性能非常好，事实上，在相同价格的情况下，我们看到的性能是我们其他北美裸机服务器的 2 倍。

因此，在性能、成本和主机多样化等方面都达到要求后，我们决定将 LETO 投入使用。 这是我们的第一个虚拟化服务器节点。 最初几个月，一切都很顺利，但后来我们遇到了问题。

首先，我们受到随机关机的困扰。 由于我们是在别人的物理基础设施上托管虚拟机，他们时不时需要关闭运行虚拟机的虚拟机管理程序（Hypervisor）来进行维护。 他们的维护窗口从未与我们的窗口同步，我们也从未收到过此类维护发生时间的提前通知。

因此，我们的 LETO 虚拟机有时似乎会随机崩溃。 我们的系统需要一段时间才能关闭，这是因为内存中有大量数据需要存入磁盘，而这 2-3 分钟的冲洗时间对于我们的虚拟机主机来说太长了。

其次，对我们来说最紧迫的问题是性能急剧下降。 我们不会点名批评我们使用的主机，因为我们知道这并不是他们服务的唯一问题。 虚拟化基础架构的主要问题是，当你与其他人共享一个系统时，你就会受到他们对其可用计算机资源的支配。

#@#And when we first got our server it was clear we didn't have many "noisy neighbours" sharing the resources with us but over time as more tenants moved in their usage began to impact the performance of our virtual machine. Even as we scaled LETO up by doubling its resources (and pricing) we were still seeing untenable performance regressions.#@#

因此，我们决定结束 LETO 实验，转而使用裸机基础架构。在裸机基础架构中，由于我们可以完全控制硬件，并且可以选择何时以及如何进行维护，因此性能始终是一致的、可预测的，稳定性也是一致的。

目前，我们不再使用任何虚拟化基础设施来驱动我们的核心服务，我们只在蜜罐和其他非必要服务中使用虚拟机。

当然，我们确实认为虚拟化有它的用武之地，例如，我们在本地软件开发的裸机服务器上就使用了虚拟化。 但对于像我们这样需要低延迟、一致性和稳定性的服务来说，虚拟化目前并不适合。

感谢您的阅读，希望您度过愉快的一周！

今天，我们将在南亚地区推出两个新的高规格服务器节点。 自 2021 年以来一直关注我们博客的人都知道，我们已经购买了多台服务器作为亚洲地区的测试平台，但并未将其部署到我们的集群中，因此这两台服务器的推出已经有很长一段时间了。 到目前为止，我们尝试过的所有服务器都因这样或那样的原因未能通过测试。

今天，这种情况终于发生了改变，因为我们为该地区部署了两台速度极快的服务器，以满足我们大量且不断增长的亚洲客户群的需求。 这意味着您的查询不再需要前往欧洲，因为在欧洲查询会产生大约 500 毫秒的延迟。

#@#During our testing, we've seen latency results of 30ms for India, 60ms for Singapore, Indonesia, Vietnam & Malaysia, 80ms for South Korea and 100ms for Japan. These new servers will now handle traffic for all of these countries.#@#

他们还将处理大洋洲地区的流量，该地区包括澳大利亚和新西兰以及某些太平洋岛屿，这些岛屿距离我们新的南亚节点比北美节点更近。

我们为新服务器选择的名字是 Pulsar 和 Quasar。 这将延续我们的太空主题命名服务器，因为我们已经用完了大部分希腊泰坦，所以不再使用它们。 幸运的是，我们已经选择的大多数泰坦都以太空现象命名，因此它们仍然非常适合。

在其他基础设施方面，本月早些时候，我们将 LETO 节点的性能提高了一倍，从而将北美的容量提高了 25%。 不过，这只是应对北美日益增长的流量的权宜之计，我们打算在今年晚些时候更换几个北美节点。

在过去的两年里，我们在北美的业务增长迅猛，有时甚至超过了我们在欧洲的业务量，因此我们有必要对基础设施进行更新，就像一年多前我们对欧洲服务器进行更新一样。

这就是今天的新闻，我们希望如果您在亚洲或大洋洲地区拥有服务器，您会喜欢现在为您提供的更低延迟和更高吞吐量。 感谢您的阅读，祝您周末愉快。

今天，我们想详细介绍一下我们在本月和上个月所做的几项重大数据变更，以及这些变更对我们通过 API 向您提供的数据有何影响。

首先，我们看到在互联网上使用住宅代理服务器搜刮网站和执行漏洞利用的情况大幅增加。 住宅代理网络已经超越了洋葱网络（TOR），因为它们的用户是付费参与的，这与 TOR 使用的免费模式不同。

在 TOR 上，任何有互联网连接的人都可以启动所谓的退出节点，其他人可以用它免费代理他们的互联网流量。 我们从一开始就一直在检测 TOR 退出节点。 但现在，随着金钱的介入，这些住宅代理网络正在成倍增长。 我们已经设法找到了其中几个节点的漏洞，并利用这些漏洞在我们的 API 上列出了它们的网络。

三月份，我们增加了两个最大的网络，很多客户给我们发送电子邮件，反映我们未能检测到很多这样的网络，因此我们开始积极追踪他们的网络节点。

为了说明这些网络的规模，我们在 API 中列出了 17500 个节点中的 15000 个。 仅此一项就相当于 TOR 规模的四倍。 虽然这让我们的客户很满意，他们要求更好地索引这些网络，但我们也付出了代价：误报。

误报率上升的原因是这些网络依赖用户共享家庭和移动网络，而这些网络通常是动态的。 在某些情况下，单个用户每天可能会更改 IP 地址多达 20 次以上，这意味着除非我们不断从数据库中删除地址，否则就会出现误报。

为了解决这个问题，我们已经开始以比其他方式更快的速度驱逐地址，有时只需 10 分钟，这取决于我们认为地址的动态程度。 对于我们在这些代理网络中不会多次看到的地址，它们会在一小时内从我们的数据中删除。

总体而言，我们在驱逐动态地址方面取得了显著进展。 例如，90% 的移动（5G/4G/3G 等）代理在 10 分钟内从我们的数据中删除。 我们还对数百个通过运营商级 NAT（CG-NAT）共享的地址范围进行了分类，因为即使代理服务器占用了这些地址范围内的某个地址，也会对这些网络的用户造成巨大影响，因此无法将其列出。

我们还大大扩展了 VPN 检测范围，在 3 月 1 日至 4 月 8 日期间，我们数据库中的托管提供商数量增加了 19.4%，这是我们在如此短时间内的最大增幅。 这主要得益于我们对数百个地址范围的调查，以及客户通过我们的联系表(顺便说一句，我们会阅读并回复发给我们的每一条信息）。

最后，我们还一直致力于一次性电子邮件检测。 我们在收集和存储一次性地址的内部系统中发现了几个问题，通过修复这些问题，我们能够大幅增加添加到数据库中的域名数量。 我们还开发了一些自定义工具，可以从许多最受欢迎的服务中自动获取一次性域名。

以上就是为您提供的数据更新。 在同一时间，我们还对控制面板进行了一些更新，在创建使用这些条件类型的规则时，您现在将收到国家和大陆建议，从而更容易锁定目标地点，而无需猜测我们在 API 中是如何显示其名称的。 该功能由我们的新资源功能驱动。这里.

我们希望您能发现这篇文章的有趣之处，我们要感谢所有花时间写信给我们的客户，告诉我们新出现的威胁、新的代理网络、可疑地址和临时电子邮件域。 我们非常感谢你们为使我们的数据更完善、更全面所做的努力。

感谢您的阅读，祝您周末愉快！