根据 VPN 服务商自己的服务器列表识别 IP 背后的服务商

我们在 2026 年 10 月 13 日 05:22 UTC 获取了 Mullvad 的中继列表。其中有 566 个中继，包括 553 台 WireGuard 服务器和 13 个网桥，Mullvad 只把其中 124 个标记为自有硬件。其中一台自有服务器是位于法兰克福的 185.213.155.73，它在 WHOIS 中登记在 "31173 Services Germany" 名下，没有反向 DNS，由 AS39351 宣告。它的网络记录里没有任何地方写着 "Mullvad"。只有列表上写着。

这就是所有"这个 IP 是哪家 VPN"工具背后的全部诀窍，而几乎没有哪家会明说。下文我们列出服务商公开服务器的端点，给出一个经过测试的 Python 匹配脚本，并展示我们的 API 对所查询的服务商列出服务器返回了什么，同时附上对照样本，未命中的结果也一并保留。最后是一张策略表。至于检测这一面，也就是 VPN 究竟是如何被识别出来的，请阅读VPN 检测原理：逐个信号解析。

能判断一个 IP 地址属于哪家 VPN 吗？

可以，前提是该 IP 出现在服务商公开的列表上。VPN 应用必须先知道服务器在哪里才能连接，所以服务商会把这份列表提供给自家应用，而这些列表大多是公开的。如果地址不在任何列表上，通常仍可以通过探测和托管信号判断它是 VPN，但无法知道是哪一家。

下面完整追踪 185.213.155.73。Mullvad 的列表位于 api.mullvad.net/www/relays/all/，其中有一行对应它：hostname 为 "de-fra-wg-001"，type 为 "wireguard"，city_name 为 "Frankfurt"，owned 为 true，provider 为 "31173"。最后这个字段是托管公司，在这里是 Mullvad 自己的公司。

注册机构给出的信息则不同。我们在 05:28 UTC 打开的 RIPE RDAP 记录将该网段命名为 NET-31173-185-213-155-0-24，注册人为 "31173 Services Germany"。RIPE whois 的 route 对象给出的源 AS 为 AS39351。我们运行了 dig -x 185.213.155.73，没有得到任何应答。

接着我们在 05:27 UTC 用我们的 API 查询了它。以下为删减后的副本，数值未作改动：

看看 whois.has_vpn_keywords。在一台 Mullvad 服务器上它是 false，而且在我们查询过的每一个地址上它都是 false。WHOIS 文本从未提到 VPN。"Mullvad" 这个名字来自列表匹配，而 vpn_confidence 为 95 正是我们的 API 对这条路径给出的值。block 处置则来自证据：一条标记为 WireGuard 的服务商列表条目，位于托管地址上。

为什么 WHOIS、反向 DNS 和 ASN 显示的是托管商而不是 VPN

大多数 VPN 服务器运行在租用的机器上，因此网络记录描述的是"房东"。在我们的样本中，M247（AS9009）托管着 NordVPN、PIA、AirVPN、IVPN 和 FastestVPN 列出的服务器。Datacamp（AS212238）托管着一台 Mullvad 纽约服务器和一台 IVPN 布宜诺斯艾利斯服务器。"M247 就意味着 VPN"这样的规则，只是对一家托管公司的猜测。服务商的列表才是关于某台服务器的证据。

Mullvad 替我们说明了这一点。它的列表把每个中继标记为 owned true 或 false，并在 provider 中写明托管商。10 月 13 日，其 566 个中继中有 124 个是 owned: true，最常见的托管商是 DataPacket（128 个中继）、Tzulo（127 个）和 M247（98 个）。我们在 05:33 UTC 查询了两个租用的 Mullvad 中继：

对其中任何一个做 ASN 检查，得到的都是"托管公司"。列表说的是 Mullvad。纽约中继 us-nyc-wg-301（143.244.47.65）在 Datacamp 上也是同样的情况。

反向 DNS 的作用更弱。我们在 05:28 UTC 对 20 个服务商列出的地址运行了 dig -x。其中 11 个没有返回任何结果，其余 9 个也都没有出现 VPN 品牌名：

Riseup 的名字暗示的是 VPN 软件 LEAP 和 Bitmask，而不是品牌。IVPN 维也纳服务器的名字里写着 "adsl"，看起来像家庭宽带连接，但它是 IVPN 列出的服务器。这正是过度解读 PTR 的危险所在。

只有当服务商运营自己的网络时，ASN 才会显示 VPN 的名字，例如 Mullvad 的 AS39351 和 Riseup 的 AS16652。如果您想了解背景，可以阅读什么是 ASN 以及它显示的是谁。我们的 API 维护着一张由 VPN 服务商运营的网络的小表，Mullvad 的 AS39351 就在其中，这张表是下文四条命名路径之一。

VPN 服务商在哪里公开服务器 IP

以下是服务商自家应用读取的列表。"今日已获取"表示我们的网络在 2026 年 10 月 13 日收到了 200 响应；"今日无法访问"表示从我们的网络尝试两次后请求仍失败。

我们无法访问的四个都是真实存在的端点。我们是从服务商的官方或开源客户端中得知它们的，gluetun 的 NordVPN 代码甚至在注释里写道，station 字段"看起来就是入口 IP 地址"（"is, it seems, the entry IP address."）。这些 API 会拦截来自数据中心的请求，而我们的扫描器正运行在数据中心里；10 月 13 日，它们也没有响应我们为撰写本文所使用的网络。

因此，我们的 API 依据服务商自己的服务器列表以及一份公开的第三方列表来为 VPN 命名。对于 NordVPN、PIA 和 Windscribe，我们的扫描器会回退到它们 API 响应的保存副本，日期为 2026 年 10 月 4 日。我们没有 Surfshark 的副本。第三方列表是 gluetun-servers，即开源 VPN 客户端容器 gluetun 背后由社区维护的服务器数据。我们加载了其中 20 多家服务商的文件，它也是我们关于 FastestVPN 的唯一来源。我们今天获取的其中四个文件，分别对应 ExpressVPN、FastestVPN、NordVPN 和 PIA，时间戳都是 2026 年 8 月 6 日。

自己根据 IP 识别 VPN 服务商：Mullvad 和 NordVPN

下载服务商的列表，查找与该地址精确匹配的条目。Mullvad 是最简单的情况，因为我们每次请求它的列表都有响应。下面是我们在 2026 年 10 月 13 日 05:29 UTC 运行的脚本，使用 Python 3.9.6，仅依赖标准库：

我们在命令行中传入了七个输入，它输出：

我们还通过 stdin 输入了三行带空行和空白填充的内容，就像把日志中的一列喂给它一样，它把 45.83.220.70 匹配到了 se-mma-wg-103。将它指向一个返回 404 的 URL 时，它输出 "could not load Mullvad's list: HTTP Error 404: Not Found" 并以状态码 1 退出。有两点需要注意：无效输入会被报告为不在列表上，而不是报错；13 个网桥也会被匹配，所以请查看 type 列。

用同样的方法检测 NordVPN。 NordVPN 的列表把每台服务器的 IP 放在 station 字段中，我们 10 月 4 日保存的副本里每台服务器都有一个。10 月 13 日，在线端点从我们的网络两次请求均超时，所以我们不会发布无法实际运行的 NordVPN 代码。请在 NordVPN 会响应的网络中运行同样的精确匹配逻辑。

如果一次只查一个地址，您可以检查任意 IP 是否为 VPN 及其服务商；该工具会在 detection.vpn_provider 中返回名字。在代码中，只需一个把 IP 放在路径里的请求：

vpn_provider 在免费套餐中可用，免费套餐包含所有数据字段，每天 1,500 次查询。如果您要以名字为键做任何处理，请匹配其开头，而不是整个字符串：我们的 API 对列出的服务器返回 "Mullvad"，对 ASN 路径返回 "Mullvad (31173 Services)"。下面是我们在 05:34 UTC 不带密钥运行的代码片段：

第三行才是您设计时需要考虑的情况：没有名字，但仍是 VPN，仍被 block。

如果您关心的是另一个问题，即您自己的连接是否显示为 NordVPN，请在连接状态下打开查看您的连接所显示的 IP。

我们的 API 对服务商列出的 IP 返回了什么

我们抽样的每一家服务商，其列出的服务器都被识别出了名字，而 vpn_confidence 表明是四条路径中的哪一条为其命名。在已命名的行上，该值与路径对应如下：

这些查询是我们在 2026 年 10 月 13 日 05:27 至 05:28 UTC 之间运行的。最后一列只列出有响应的 VPN 握手探测；表中省略了 detection_methods 的其余部分。

有三行需要说明。NordVPN 和 PIA 的服务器在我们保存的副本中，但它们返回的是 80，即 gluetun 路径的值，而且两者都在 gluetun 的文件中。PrivadoVPN 的服务器今天就在 PrivadoVPN 自己的导出列表上，但它返回的是 90 而不是 95：它的名字来自解析其主机名 hkg-006.vpn.privado.io，而 gluetun 的 PrivadoVPN 文件中也有这个主机名。请根据 vpn_confidence 判断路径，而不是根据您在哪份列表上找到这个 IP。ExpressVPN 不在我们直接拉取自有列表的九家服务商之中。一个 gluetun 列出的 ExpressVPN 地址被识别出了名字，这说明该路径有效，而不是说明我们覆盖了 ExpressVPN。

最后一行是 ASN 路径。45.83.220.7 不在 Mullvad 的列表上；今天的列表在该 /24 中有 .68、.69 和 .70，没有 .7。它之所以被命名，是因为它所在的网络 AS39351 属于 Mullvad 的运营方：

请注意，这里同样触发了 known_vpn_server。这个方法名并不表示"在服务商的列表上"；在这一行，它来自网络表。请通过 vpn_confidence 判断路径，并且只在 vpn_provider 不是 "none" 的行上这样做。

为什么有些 VPN IP 返回 "none"

"none" 表示该 IP 目前不在我们持有的任何列表上。它并不表示该 IP 不是 VPN，也不表示某个服务商的相邻地址是干净的。

NordVPN 的服务器 pl128（194.99.105.99）在我们 10 月 4 日保存的 NordVPN 响应中，状态为在线。今天它返回的 vpn_provider 是 "none"，但 is_vpn 为 true，评分 98，处置为 block，检测方法中包括 ipsec_open。是它的 IPsec 握手暴露了它；没有任何来源为它命名。PIA 的列支敦士登服务器 91.90.122.25 出现在同一天的 PIA 列表中。今天它返回 is_vpn false，评分 64，处置为 step_up，仅来自黑名单和托管信号。

这两个地址都不在 gluetun 的文件中，而上文已命名的 NordVPN 和 PIA 行都在。我们今天无法重新获取 NordVPN 或 PIA 的 API，因此这两台服务器可能在 10 月 4 日之后已经下线或更换了地址。我们能说的结论更窄，但可以确定：只有当服务器出现在我们当前持有的列表上时，才会被命名。

在一家我们今天确实获取了列表的服务商上，我们也有一个未命中的例子。91.90.123.29 与列出的 Mullvad 中继 91.90.123.2 位于同一个 /24，但它不在 Mullvad 的列表上。10 月 13 日，IPinfo 的服务商页面把它作为 Mullvad 的示例 IP 展示。我们的 API 返回 is_vpn false，vpn_provider "none"，评分 12，处置为 allow。它可能是一个出口地址，或是与列出地址相邻的未列出地址；这只是一种迹象，并非证据。无论如何，列表匹配只覆盖列出的地址，不覆盖它旁边的任何地址。

文档中的对照样本展示了未命名但被检测到的情况。102.129.235.17 位于 AS834 IPXO，返回 is_vpn true，vpn_provider "none"，评分 92，处置为 block，检测方法为 known_vpn_server、openvpn_open 和 ipsec_open。一台未命名的服务器只要与我们的扫描器完成了 OpenVPN 或 IPsec 握手，仍会被识别出来；上文链接的核心文章介绍了这些探测。

VPN IP 未被命名的常见原因：

• 没有公开列表。 有些服务商不公开任何列表，自建的 VPN 也永远不会出现在列表上。
• 列表无法访问。 我们拉取的九份列表中有四份会拦截数据中心，因此在有保存副本时我们使用副本，此外还依靠 gluetun。
• 轮换。 服务器可能在我们上次获取副本之后离开列表或更换地址。
• 它是代理，而不是 VPN。 代理没有可供匹配的服务商列表；请参阅数据中心代理、住宅代理和移动代理。

iCloud Private Relay 和 Cloudflare WARP 不属于这个意义上的 VPN 服务商。它们有自己的字段 relay_provider 和自己的策略，详见 iCloud Private Relay 与 Cloudflare WARP。

被命名的 VPN 并不是风险更高的 VPN

名字说明谁在运营服务器；评分来自证据，例如开放的握手端口、托管属性和滥用历史。我们样本中一些最低的评分属于已命名的服务器，而最高的评分之一属于一台未命名的服务器。

我们的分段是：25 及以下为 allow，50 及以下为 review，75 及以下为 step_up，高于 75 为 block。在我们的数据中，PrivadoVPN 的服务器没有响应任何握手探测，所以只触发了 known_vpn_server，停留在 review。那台未命名的服务器响应了两个。这才是正确的方向：规则应当衡量我们观察到的内容，而不是服务器上挂的是谁的标志。各信号的权重见评分是如何构建的页面。

入口 IP、轮换的服务器和过时的名字

服务商列表告诉您的是应用所连接的地址。对于我们样本中的大多数服务器，正是这个地址响应了我们的探测，但我们只验证了列出的地址会被命名，并没有验证服务商使用的每一个出口地址都在列表上。

字段名里写的是 "in"。Mullvad 使用 ipv4_addr_in，AirVPN 为每台服务器公布四个地址，即 ip_v4_in1 至 ip_v4_in4。Surfshark 的列表只给出主机名，因此必须有人先把名字解析为 IP，才能进行匹配。我们的 90 路径正是对 gluetun 文件中的服务器主机名做这件事。FastestVPN 的 au-stream.jumptoserver.com（46.102.153.134）就是这样被命名的。

列表中还带有您应当读取的状态信息。Mullvad 今天的列表把 24 个中继标记为 active: false，其中包括 se-mma-wg-101（45.83.220.68），而我们的 API 仍以 95 将其命名为 "Mullvad"。列出的服务器是关于服务商机群的事实，并不能证明这台服务器今天承载了流量。这也是各厂商的 VPN IP 数量相差如此之大的原因。它们在不同日期统计的是不同的东西，例如服务器、列出的入口地址、观察到的出口地址或整个网段。我们引用的唯一数量是 Mullvad 自己的列表。我们在此不公布服务商列表的刷新计划；如果您自己运行匹配脚本，请在每批处理前获取列表。

拿到服务商名字之后该怎么做

把名字用于策略和调查，而不是用作拦截开关。决策应以 recommended_action 及其背后的证据为依据，例外处理和报表则以名字为依据。

常见的错误是把第一行变成拦截规则，这会让服务商的客户变成 VPN 检测误报。本周可以在您自己的日志上做两项检查：

• 找出以名字为键的规则。 在您的规则中搜索 vpn_provider。像"只要识别出服务商就拦截"这样的规则，会放过未命名的 92 分，却拦截已命名的 36 分。请改为以处置和证据为键，并按前缀匹配名字。
• 用一份列表比对您的日志。 把最近 30 天的注册或登录 IP 输入 Mullvad 匹配脚本，统计匹配数量。将它与您的规则拒绝了其中多少请求进行比较，然后在 IP 查询工具中抽查几个。

常见问题

能判断一个 IP 地址属于哪家 VPN 吗？

可以，前提是该 IP 出现在 VPN 服务商为自家应用公开的服务器列表上。如果它不在任何列表上，通常仍能判断它是 VPN，但无法知道是哪一家。

有 NordVPN 的 IP 地址列表吗？

NordVPN 的应用从 api.nordvpn.com 读取列表，其中每台服务器的 IP 位于 station 字段。2026 年 10 月 13 日，它没有响应来自我们网络的请求，因此我们使用了保存的副本。

WHOIS 或反向 DNS 会显示 VPN 服务商吗？

很少。大多数 VPN 服务器位于 M247 这类租用的托管网络上，所以 WHOIS 和反向 DNS 显示的是托管商。就连 Mullvad 自有的法兰克福网段也登记在 31173 Services 名下。

vpn_provider 为 none 是什么意思？

表示该 IP 不在我们持有的任何服务器列表上。这并不代表该 IP 不是 VPN：请查看 is_vpn 和 scoring.detection_methods。

被识别出名字的 VPN 会得到更高的欺诈评分吗？

不会。一台列出的 PrivadoVPN 服务器得分 36，处置为 review；而一个未命名的 VPN 得分 92，处置为 block。名字说明谁在运营服务器，评分来自证据。

哪些 VPN 服务商公开了服务器列表？

2026 年 10 月 13 日，Mullvad、AirVPN、IVPN、PrivadoVPN 和 Riseup 响应了我们的公开请求。NordVPN、Surfshark、PIA 和 Windscribe 也为自家应用发布列表，但没有响应来自我们网络的请求。