指南 / 教程 网络技术

BGPlayer 从零开始速成指北 - 如何获得一个朝鲜/南极洲 IP

你是否见过这样的场景:

  • 评论区里, IP 归属地来自一些极其小众的国家或地区, 比如朝鲜、南极洲, 或加勒比地区那些人口只有几万人的海岛国家
  • 又或者, 同一个评论区中, 短短几分钟内就 “横跨半个地球”, 上一条显示来自瑞士, 下一条却来自乌克兰

难道大家都是隐藏多年的富豪, 终于摊牌了？

B站 小红书 抖音

是他手持 oneworld Emerald (寰宇一家绿宝石) 在世界各地飞?

当你开始思考这个问题时, 实际上已经触及到了网络最罕见、也是最核心的部分。你触及到了网络组成的本质

我先给你一个结论, 不带情绪, 不带滤镜, 稳稳的接住你的问题 ( ChatGPT 5.2 风味

通过修改 IP 定位, 你可以实现:

  • 在各类平台显示一些离谱的 IP 归属地
    • 几乎没有互联网基础设施的南极洲
    • 没接入互联网的朝鲜 ✋😭🤚
    • 某些从没听过的, 人口一共几万人的海岛小国家
  • 可以解锁各地流媒体, 参考 DIY任意地区流媒体解锁IPv6
  • 用一台 VPS 获得全球各地的 IP 地址, 挂探针装逼点亮全球, 实现另类的 All In One (怎么这也 All In One)
  • 开 oneman IDC 卖各种地区的 VPS

本篇主要讲述修改 IP 定位的原理以及套 WARP 后得到一个对应地区的 IPv4 地址

IP 定位原理

在互联网中, IP 并不存在一个物理意义上精确的位置。

我们日常看到的 IP 归属地, 本质上是各类 IP 数据库 基于多种信息来源所做出的综合判断, 其中包括:

  • IP 注册机构 (RIR) 中的登记信息
  • 路由与 BGP 宣告情况
  • 网络测量结果 (延迟、路径等)

这种判断并非绝对准确, 也会随着网络结构、广播方式和数据库策略的变化而不断调整。

当然也有一些例外。美团所使用的 IP 定位, 会结合用户的外卖配送地址等业务数据进行校正, 因此在特定场景下非常精准, 但这已经超出了传统 IP 数据库的范畴。

理解 IP 定位的运作方式, 是理解 “为什么能出现朝鲜 / 南极洲 IP” 的前提。

IP 数据库

要查询 IP 的归属地, 需要依赖 IP 数据库。这些数据库会记录各个 IP 段被认为的使用位置。

有些大型公司会维护自己的私有 IP 数据库, 例如 Google、Netflix、淘宝、美团。而 B 站、小红书、抖音 这类平台, 一般会直接使用第三方提供的 IP 定位服务。

常见的 IP 数据库有: Maxmind、IPInfo、DB-IP、Digital Element 等, 有些小数据库, 会直接从这些主流数据库同步或二次加工数据。

IP 数据库 の 数据来源

IP 数据库本身并不是权威机构, 而是一个整合者。它们会从多个渠道收集信息, 并对不同来源赋予不同权重, 主要包括:

  • RIR (如 RIPE、APNIC、ARIN) 数据库中的注册信息
  • 公网路由表与 BGP 宣告分析
  • 基于探测节点的网络测量结果
  • 网络运营商或用户主动提交的定位修正请求
  • 历史数据与行为特征分析

在此基础上, 数据库会整理出 IP → 地理位置 的映射关系, 并附加更多维度的信息, 例如:

  • IP 类型 (家庭宽带 / 数据中心 / VPN)
  • ASN 与运营商信息
  • 风险与威胁评分

这些数据被出售给网站或平台使用, 网站后端直接查询数据库结果, 用于归属地展示和风控判断。

顺便推荐一个可以同时查询多个 IP 数据库的网站: iplark.com

IP 数据库 の 探测节点与定位修正

为了判断 IP 段的实际部署位置, IP 数据库会在全球各地的数据中心部署探测节点。

Probe network - how we make sure our IP data is accurate

这些探测节点主要用于:

  1. 从公网路由表中收集已宣告的 IP 前缀
  2. 进行 ICMP Ping 延迟测量
  3. 推测 IP 段的实际部署区域

由于已分配但未使用的 IP 段数量极其庞大, 大多数 IP 数据库只会收录已经广播到公网的 IP 段。截至目前, 全球已广播的前缀数量: IPv4 前缀为: 1016978、IPv6 前缀为: 225354

基于这种测量机制, 如果你在美国广播一个在 RIR 注册信息中标注为南极洲的 IP 段, IP 数据库会认为

探测到的实际部署位置 > 注册信息

从而将该 IP 的归属地直接修正为美国

但需要注意的是, 这种基于网络测量的方式本身也存在误差。例如在香港广播的地址段, 有时会被粗略归属为深圳

IP 位置 の 模糊性

事实上, IP 的位置本来就是一个模糊的概念。

以 2a14:67c0::/29 为例, 这是一段整体分配给英国的原生 IPv6 地址, 在 RIPE 数据库中, 它在注册层面被视为英国 IP

IP 注册地

大善人 Alice 免费提供了其中的一小段子网 2a14:67c3:660::/44, 我从中进一步划分出 2a14:67c3:666::/48

作为该 IP 段的持有者, 我可以在 RIPE 数据库中随意修改该网段的 Whois 信息, 例如将 country 字段填写为 AQ (南极洲)

这类注册信息会被部分 IP 数据库直接采纳, 作为 IP 定位判断的重要参考依据之一

RIPE 数据库 IP country 字段

我将 2a14:67c3:666::/48 在德国法兰克福、美国洛杉矶、美国纽约、新加坡、日本东京五地的 VPS 上进行了 Anycast 广播。同时, 在五台服务器上绑定了相同的 IP 地址 2a14:67c3:666::1, 用户访问该 IP 时, 会自动连接到距离最近的服务器。

说人话就是, 同一个 IP 地址, 可以同时出现在多个国家的不同服务器上。这时候探测节点的定位就会不准确了

这最常见的应用场景就是公共 DNS 服务, 例如 1.1.1.1 和 8.8.8.8 它们的 IP 地址本身就是通过 Anycast 方式在全球范围内提供服务的。

正是由于以下因素的共同存在:

  • Anycast 等复杂的路由结构
  • IP 注册信息与实际部署位置不一致
  • 不同数据库采用不同的数据来源和权重

在这种情况下, 很难通过某一种技术手段准确判断 IP 的真实位置。

因此, 几乎所有主流 IP 数据库都允许公众或网络持有者主动提交 IP 定位修正请求。

修改 IP 定位

在理解了 IP 定位原理之后, 修改 IP 定位就会 从从容容, 游刃有余。先从注册信息入手, 再影响 IP 数据库, 最后避免被探测节点纠正。

整体流程可以概括为三步:

  1. 修改 RIPE 数据库中的注册信息
  2. 向各大 IP 数据库提交定位修正 (手动提交或通过 Geofeed 批量提交)
  3. 避免探测节点对定位进行修正

需要注意的是, 如果将 2a14:67c3:660::/44 整个地址段直接广播出去, 而没有在 RIPE 数据库中提前划分更小的子网, 这并不利于 IP 数据库进行精细化收录。整个地址段都会被统一归属为同一个国家, 后续再对 /48 子网进行单独定位修正, 生效会非常缓慢, 往往需要 1～2 个月

如果你拥有该 IP 段在 RIPE 数据库中的编辑权限, 建议在广播之前, 先将对应子网的 country 字段修改为目标国家, 再进行广播, 否则更新定位会非常慢。

分配最小子网

在修改 IP 定位之前, 需要先将 IP 段拆分为最小广播单位

  • IPv4: 最小广播子网为 /24
  • IPv6: 最小广播子网为 /48

如果你只获得了一个 /48 的 IPv6 网段, 则无法再继续拆分, 只能编辑 LIR 分配给你的网段。

登录 RIPE Database 后, 依次进入 My Resources -> IPv6 -> Create assignment

进入创建 inet6num 的表单, 按照如下方式填写

inet6num:       2a14:67c3:660::/48             # 填写要分配的子网段
netname:        AceSheep-Network-North-Korea   # 网段名称, 取一个喜欢的名字
descr:          AceSheep Network North Korea   # (可选) 网段介绍
country:        KP                             # 选择希望定位到的国家 / 地区
admin-c:        JD12053-RIPE                   # 联系人对象, 选择之前创建的即可
tech-c:         JD12053-RIPE                   # 联系人对象, 选择之前创建的即可
status:         ASSIGNED                       # ASSIGNED 表示该地址段已分配
mnt-by:         ACESHEEPTEST-MNT
source:         RIPE

完成创建后, 该子网在 RIPE 数据库中的注册信息, 将成为后续 IP 数据库定位判断的重要参考依据。

创建新的 inet6num

单个提交修正

在完成 RIPE 数据库修改并广播 IP 段后, 下一步就是向各大 IP 数据库提交定位更正请求。

提交方式的选择

  • 修正数量 ≤ 5 个 IP / 网段
    👉 可以通过各数据库提供的 在线表单, 逐个提交 IP 定位修正。
  • 修正数量较多 (> 5) 或经常变更
    👉 用在线表单简直是坐牢, 建议使用 Geofeed 方式进行批量提交

许多大型网络和运营商, 都会通过 Geofeed 来维护和发布 IP 地址的地理位置信息。

如果你是搭配 Cloudflare WARP 使用, 其实只需要确保 IPInfo 的定位正确即可。Cloudflare 早期使用 MaxMind 作为定位服务商, 但已于 2025 年 6 月 11 号正式切换为 IPInfo

IPinfo is the IP geolocation data provider of Cloudflare

值得注意的是, MaxMind 的 Geofeed 功能目前仅针对付费用户开放。这也是 Cloudflare 最终放弃 MaxMind 转向 IPInfo 的重要原因之一

常见 IP 数据库的修正入口

可以向以下主流 IP 数据库提交定位修正请求

  • Maxmind 使用最广泛的商业 IP 数据库之一, 许多网站和安全产品仍在使用, 但免费用户的修正生效较慢或者不予修正
  • IPInfo Cloudflare 当前使用的 IP 数据库, 对网络运营者提交的修正响应积极
  • Google 主要影响 Google 搜索与相关服务中的 IP 定位展示

MaxMind 更正 GeoIP 位置 Google 报告 IP 问题

IPinfo 错误 IP 地理位置数据更新

不同 IP 数据库都有各自的维护流程, 部分数据库还会进行人工审核, 定位修正通常需要 3 天到 2 周 才会生效。

我自己的测试中

  • IPInfo 大约 1 周内接受并生效
  • Maxmind
    • 两个月无任何回应
    • 即使 IP 实际广播位置真实, 也不会主动修正 IP 定位
    • 免费用户屁都不是

如果多次提交都没人受理再联系, 可以选择硬刚通过 MaxMind 的表单联系他们

如果需要填写修正理由, 建议使用和业务影响有关的描述, 避免涉及匿名代理等敏感用途。例如 “因为 IP 定位错误, 我的客户无法访问部分地区限制的网站” (用英文写)

以下是一段真实沟通案例, 仅供参考 (请自行组织措辞):

Hello,

I am the network operator and owner of <ASN 号码>.

I have noticed that my IPv6 address block <IPv6 网段> is incorrectly geolocated to the <国家> in the MaxMind database. This issue affects all /48 subnets under this /40 prefix, which are also being incorrectly localized. As a result, some of my customers are denied access to certain websites and services due to geolocation-based restrictions.

I have submitted multiple data correction requests through the MaxMind correction form, but unfortunately have not received any response so far.

To ensure the accuracy of the authoritative data, I have already corrected the country information for this prefix in the RIPE NCC database. Other geolocation providers, such as ipinfo.io, have since synchronized this update and now show the correct location. However, MaxMind continues to locate this entire prefix (including all /48 subnets) in the <国家>.

I would like to politely ask if you could let me know why my previous correction requests have not received a response, and whether there is any additional information required from my side to facilitate the update.

Thank you very much for your time and assistance. I would appreciate any guidance on how this issue can be resolved.

Kind regards,
AceSheep
Network Operator, <ASN 号码>

Geofeed 批量提交修正

对于拥有分布在全球各地 IP 地址的 ISP 来说, 一个一个手动提交 IP 定位修正请求显然不现实。因此, 业界制定了一种名为 Geofeed 的规范, 用于批量发布和维护 IP 地址的地理位置信息

什么是 Geofeed

Geofeed 是目前业界公认的 IP 地理位置共享标准, 相关规范在 RFC 8805 中有详细定义。

原文参考: Publishing a Geofeed

Geofeed 其实就是一个 CSV 文件, 格式如下

network, iso_country code, iso_region_code, city_name, postal_code

下面是一个有效且完整的 Geofeed 示例

8.8.8.0/24,US,US-CA,Mountain View,
2001:4860:4860::/46,US,US-CA,Mountain View,

这是目前最规范、也是各大 IP 数据库厂商普遍接受的 IP 定位信息发布方式。

托管与提交 Geofeed

你需要将 geofeed.csv 文件托管在一个可公开访问的 URL 上, 例如:

https://example.com/geofeed.csv
https://geofeed.example.com/geofeed.csv

托管位置可以是

  • 自己的网站
  • 对外可访问的对象存储
  • 甚至是托管在 Google Sheets 并导出为 CSV

完成后, 可以通过以下两种方式让 IP 数据库使用你的 Geofeed

  • 通过联系网站 Support, 将 Geofeed 链接提交给各大 IP 数据库厂商
  • 在 RIPE 数据库的 inet6num (或 inetnum) 对象中填写 geofeed 字段, 让数据库厂商自动抓取并定期更新你的 IP 定位信息

于是, 你就可以拥有来自全球各地、稀奇古怪的 IP 地址, 通过挂探针的方式实现「点亮全球」

防止 IP 被拉回

需要注意的是, IP 定位修正并非一劳永逸。各大 IP 数据库仍会结合其他技术手段来判断 IP 的实际部署位置, 定位信息有可能被重新修正 (拉回)。

常见的应对措施:

  • 在服务器防火墙中禁止 ICMP (Ping) 及常见端口的探测, 降低被主动扫描的概率
  • 尽量避免直接使用服务器自身的 IPv6 地址访问网站
  • 对外访问时优先使用通过 WARP 获得的 IPv4 地址

此外, 部分厂商 (例如 Google) 还可能结合手机的 Google Maps 的定位数据, 对 IP 归属地进行纠正, 这类行为已经超出了传统 IP 数据库和 Geofeed 所能控制的范围。

Patience Is Key in Life

在提交定位修正请求后, 通常需要等待几周, IP 数据库才会陆续完成更新。这时可以使用 iplark.com 这类工具, 批量查询各大 IP 数据库中你的 IP 定位信息, 确认数据是否已经生效。

多数 IP 数据库也提供了在线查询方式, 例如 Maxmind、IPInfo。在等待期间, 可以通过这些工具手动查询, 用于确认当前 IP 的归属地状态。

需要注意的是, Cloudflare 同步 IPInfo 数据本身也可能存在延迟, 通常在一到两周左右。如果在线查询显示 IPInfo 的定位已经正确, 但 Cloudflare 没更新的话, 只需要再耐心等待一段时间即可。

检查 IP 在 Cloudflare 中的定位结果

在前面的步骤中, 我们已经将 2a14:67c3:666::/48 的定位修改为 南极洲, 接下来需要确认 Cloudflare 是否已经同步了这一变更。

可以通过 Cloudflare 提供的 /cdn-cgi/trace 接口进行测试 (任何接入 Cloudflare 的网站都支持该接口)

curl -s -6 --max-time 10 www.cloudflare.com/cdn-cgi/trace --interface 2a14:67c3:666::1

如果 IPInfo 中的定位已经修改完成, 但返回结果中仍显示 loc=US, 说明 Cloudflare 尚未同步最新的 IPInfo 数据, 此时仍需要继续等待。其中, colo=SEA 使用的是 IATA 机场代码

此时返回结果如下

fl=561f233
h=www.cloudflare.com
ip=2a14:67c3:666::1    # 当前使用的 IPv6 地址
ts=1769417304.89
visit_scheme=http
uag=curl/7.76.1
colo=SEA               # 请求命中的 Cloudflare 数据中心为 SEA (西雅图-塔科马国际机场)
sliver=none
http=http/1.1
loc=US                 # Cloudflare 当前识别的 IP 定位为 US / 美国
tls=off
sni=off
warp=off               # 当前未启用 WARP
gateway=off
rbi=off
kex=none

又过了十几天后, Cloudflare WARP 使用的 IP 数据库终于完成了！更新相比 Cloudflare 的其他服务, WARP 的更新速度还慢了十天。此时, 距离 IPInfo 更新已经过去了半个月, 距离第一次提交 IP 定位修正请求过了一个月。

再次执行相同的测试命令, 返回结果变为

fl=20f788
h=www.cloudflare.com
ip=2a14:67c3:666::1    # 当前使用的 IPv6 地址
ts=1769419002.274
visit_scheme=http
uag=curl/7.76.1
colo=SEA
sliver=none
http=http/1.1
loc=AQ                 # Cloudflare 已正确识别该 IP 的定位为 AQ / 南极洲
tls=off
sni=off
warp=off               # 当前未启用 WARP
gateway=off
rbi=off
kex=none

当你直接使用修改定位后的 IP 访问 Cloudflare, 且 loc 字段返回正确结果时, 就可以进入下一步操作了。

使用 WARP 获得对应地区 IPv4

由于我们目前只有 IPv6, 因此无法访问大部分 IPv4-only 的网站。这时就需要借助 Cloudflare WARP 来帮忙了。

WARP 有一个非常重要的特性: 它会根据用户的连接 IP 来分配对应归属地的 IP, 而不是按照 WARP 接入节点所在的地理位置来分配。例如, 大陆用户连接 WARP 时, 实际接入的是美国节点, 但最终分配到的 IP 定位在大陆。

正是利用这一特性, 我们可以用已经被修改为南极洲定位的 IPv6, 通过 WARP 获得一个定位同样在南极洲的 IPv4

WARP 会根据当前 IPv6 的定位, 为我们分配一组对应地区的 IPv4 + IPv6 地址。其中, WARP 分配的 IPv4 地址不仅可以用于访问 IPv4-only 的网站, 其定位信息还由 Cloudflare 统一维护, 在各大 IP 数据库中的准确性都非常高, 比手动向多个数据库提交修正请求要省心得多。

获取 WARP 连接配置

需要注意的是, 如果直接通过 Linux 内核提供的 WireGuard 连接 WARP 会修改系统的默认路由表, 将所有流量进行全局代理, 而这并不是我们当前的需求。

因此我们不使用内核 WireGuard, 而是通过 ViRb3/wgcf 获取 Cloudflare WARP 的配置文件, 再使用 whyvl/wireproxy 将 WARP 导出为一个 SOCKS5 代理。这种方式可以避免修改系统路由表, 也更方便后续进行 IP 定位验证与测试。

后续, 你也可以使用 Xray 实现 WireGuard 出站, 并结合自定义路由规则进行精细化分流。

如果你需要使用 WARP+, Telegram 上有些频道会分享免费的 WARP+ 密钥, 例如 Warp Plus

使用以下命令快速获取 WARP 的连接配置

mkdir ~/wgcf
cd ~/wgcf
wget -O wgcf https://github.com/ViRb3/wgcf/releases/download/v2.2.30/wgcf_2.2.30_linux_amd64
chmod u+x wgcf
alias wgcf=~/wgcf/wgcf
wgcf register --accept-tos
wgcf generate
wgcf status
cat wgcf-profile.conf

生成的配置文件如下

[Interface]
PrivateKey = yN0tzPQtrM/tlUmzAceSheepRTWGp/JF6zlL4/kQ02I=
Address = 172.16.0.2/32, 2606:4700:110:8c98:cefb:abcd:1234:498c/128
DNS = 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, 2606:4700:4700::1001
MTU = 1280
[Peer]
PublicKey = bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = engage.cloudflareclient.com:2408

接下来需要修改连接的 Endpoint, 手动指定为 IPv6 地址, 以避免域名解析到 IPv4 地址。

由于我们当前是通过 IPv6 出口 连接 WARP, 如果 Endpoint 解析为 IPv4 地址, 将导致连接无法建立, 因此必须显式指定 WARP 的 IPv6 Endpoint

[2606:4700:d0::a29f:c001]:2408

安装并配置 WireProxy

这里我们需要使用修改版的 xiahuaijia/wireproxy。该版本支持在多 IP 的服务器上手动指定出站 IP, 这样就可以使用我们通过 BGP 广播并绑定在 dummy1 网卡上的 IPv6 地址 进行测试。

通过这种方式, WARP 的连接将使用南极洲定位的 IPv6 作为出口, 从而获得对应地区的 WARP IPv4/IPv6 地址。

下载支持多出站 IP 的修改版 wireproxy

wget https://github.com/xiahuaijia/wireproxy/releases/download/v1.1.0/wireproxy_1.1.0_linux_amd64.tar.gz
tar xzvf wireproxy_1.1.0_linux_amd64.tar.gz

编辑配置文件

vim wireproxy.conf

内容如下

WGConfig = wgcf-profile.conf

[Socks5]
BindAddress = 127.0.0.1:1080

启动 wireproxy, 并指定南极洲定位的 IPv6 作为出站 IP

./wireproxy --config wireproxy.conf --interface 2a14:67c3:666::1

验证 IP 定位结果

完成 WARP 配置后, 我们来实际测试一下获取到的是不是 南极洲 (AQ) 的 IPv4 地址

使用 IPInfo 验证

通过 SOCKS5 代理访问 IPInfo

curl -s --max-time 10 -x socks5://127.0.0.1:1080 ipinfo.io

返回结果如下

{
  "ip": "104.28.244.152",
  "city": "McMurdo Station",
  "region": "Antarctica",
  "country": "AQ",
  "loc": "-77.8463,166.6682",
  "org": "AS13335 Cloudflare, Inc.",
  "timezone": "Antarctica/McMurdo",
  "readme": "https://ipinfo.io/missingauth"
}

可以看到, 此时已经成功获得由 WARP 分配的 南极洲 IPv4 地址

使用 Cloudflare 验证

通过 Cloudflare 的 /cdn-cgi/trace 接口测试一下

curl -s --max-time 10 -x socks5://127.0.0.1:1080 www.cloudflare.com/cdn-cgi/trace

关键字段如下

ip=104.28.212.152
colo=SEA
loc=AQ
warp=on

其中 loc=AQ 表示 Cloudflare 已正确识别该 IP 的定位为 南极洲, 且当前流量确实通过 WARP

使用 B 站接口验证

最后, 使用 B 站供的 IP 查询接口进行验证

curl -s --max-time 10 -x socks5://127.0.0.1:1080 https://api.live.bilibili.com/ip_service/v1/ip_service/get_ip_addr

返回结果

{
  "code": 0,
  "msg": "",
  "message": "",
  "data": {
    "addr": "104.28.212.152",
    "country": "南极洲",
    "province": "南极洲",
    "city": "",
    "isp": "cloudflare.com",
    "latitude": "-81.5",
    "longitude": "0"
  }
}

可以看到, 不同平台和数据库对 WARP 分配的 IPv4 地址给出了高度一致的定位结果

WARP 南极洲 IPv4 多数据库查询结果

至此, 已经成功获得了 南极洲定位的 WARP IPv4 地址

The End

此时只需在这台 VPS 上配置一个代理, 你就可以使用南极洲的 IP 到各大网站上炫耀了

最后附上一张实际在 B 站评论区显示定位的截图, 作为成果展示。

B 站评论截图

终于啊终于……本文从 2024 年 10 月开始筹划, 到最终完全生效, 期间经历了多次修正与漫长等待, 前后历时 15 个月, 终于在反复折腾中圆满结束。

原文

教你如何获得一个南极ip
自己在家开运营商 Part.5 - 如何得到一个朝鲜/南极洲 VPS (新概念点亮全球)
DIY任意地区流媒体解锁IPv6 - 图片备份

最后更新于 2026-01-27