什么是 IP Geofeed？它如何影响 IPv4 地理位置数据

你租了一个 /24，部署在法兰克福。三周后客户发来工单：你们的 IP 显示在美国。

机器没坏，路由正常，延迟也没问题，origin ASN 和当初商定的完全一致。不一致的是某个数据库里的那条记录。

地理位置数据从来不属于路由系统。它是一批各自独立的数据库，由不同机构持有，用不同来源拼出来，按各自的节奏更新，彼此之间没有任何对齐义务。Geofeed 是其中一种标准化的自发布机制，让网络运营方把自己的答案发布进这堆数据里。

开篇定义： Geofeed 是网络运营方发布的一个文件，用 IP 前缀对应较粗粒度的位置信息——国家，以及可选的大区和城市。RFC 8805 定义了它的文件格式。它是自发布的位置数据：不是路由机制、不是注册要求，也不保证任何一家服务商会因此改动它显示的结果。

一句话说清：Geofeed 是你自己发布的一条位置提示，读不读、信几分，由使用方决定。

白脸小鹿把一枚小小的位置标签别在地址带的一根分叉上，另一条路由轨道从画面中穿过，完全没有被碰到。

Geofeed 给前缀挂上位置信息，它不碰这条前缀实际走的路由。

1. Geofeed 是什么

RFC 8805 的全名是 A Format for Self-Published IP Geolocation Feeds。它记录了一种格式，让网络运营方可以发布「IP 地址前缀 → 简化地理位置」的对应关系，并把这份文件称作 geolocation feed。

这句话里有三点最关键：

自发布。 文件由运营方自己发布，没有中心化注册表要申请，也没有审批环节。运营方把文件挂在一个 URL 上，然后声明这件事。
故意做得粗。 RFC 里写得很直白：这个格式 "intentionally only allows specifying coarse-level location"。它不是 IP 的门牌号，也查不出某个前缀在哪个机柜里——本来就不打算查出来。
是提示，不是指令。 格式里没有任何东西要求使用方接受它。RFC 8805 明确写了，使用方 "MAY treat published feed data as a hint only and MAY choose to prefer other sources of geolocation information for any given IP prefix"。

第三点是 Geofeed 被当成万能药时最常被漏掉的一条。发布一份准确的 Geofeed 是件好事，但它不是那种一按下去、全世界的位置数据库就跟着改的开关。

2. Geofeed 里都有什么

它是一个纯文本 CSV 文件，通过 HTTP 或 HTTPS 从某个 URL 提供。编码是 UTF-8；空行忽略，# 到行尾是注释。剩下每一行是一条记录：

ip_prefix,alpha2code,region,city,postal_code

字段	是否必填	填什么
`ip_prefix`	必填	单个 IP，或 CIDR 写法的前缀，IPv4、IPv6 都行
`alpha2code`	可选	ISO 3166-1 alpha-2 国家代码，比如 `DE`
`region`	可选	完整的 ISO 3166-2 行政区代码，比如黑森州是 `DE-HE`
`city`	可选	城市名，自由文本，比如 `Frankfurt`
`postal_code`	可选	已废弃，见下文

拿文档保留网段写几行，大概长这样：

# 示例 geofeed —— 仅使用文档保留网段
# 前缀,                 国家,   大区,    城市,       邮编
192.0.2.0/24,           DE,     DE-HE,   Frankfurt,
198.51.100.0/24,        NL,     NL-NH,   Amsterdam,
2001:db8:1200::/40,     DE,     DE-HE,   Frankfurt,

同一个文件可以同时放 IPv4 和 IPv6 记录，靠前缀这一列区分。注意大区这一列：RFC 8805 要求填 ISO 3166-2 的地区代码，而这份 RFC 自己举的例子用的都是完整写法——US-AL、PL-MZ、NL-ZH——不是省略国家前缀的那种。

动手写或审之前，两条解析规则值得先记住：

最长前缀优先。 允许嵌套前缀，使用方拿一个 IP 去匹配时，应当取覆盖它的最长前缀。所以在一个已发布的 /16 里单独给某个 /24 换城市，是合法做法，不用把整个 /16 拆开。
重复即错误。 同一个前缀在一个文件里出现两次，会被当成错误，应该记下来人工复查。这种问题几乎都出在脚本生成的 feed 上。

邮编字段已经废弃。 RFC 8805 把它标为 OPTIONAL, DEPRECATED，理由是 "due to the granularity of this information"，新 feed 不建议再包含这个字段。使用方仍要能解析带邮编的 feed，但现在没什么理由继续用它。

真正有用的是前四个字段；最后那个已经废弃，不填反而更合适。

3. Geofeed、注册信息、GeoIP 数据库，三者不是一回事

这三样经常被揉成一件事，但它们由不同人写、为不同目的服务、变更路径也完全不同。

	Geofeed	注册信息	商业 GeoIP 数据库
是什么	自发布的「前缀 → 粗粒度位置」CSV	RIR 数据库里的注册数据，包括 `country:` 字段	卖给各类服务的厂商数据集
谁写的	实际使用这些地址的网络运营方	资源持有方，通过数据库 maintainer	厂商自己收集
主要用途	告诉地理位置使用方这些前缀部署在哪	记录资源归谁、注册资料和联系人句柄	向付费客户回答「这个 IP 在哪」
怎么变更	换一个新文件，同时更新注册表里的引用	数据库更新，受对象授权规则约束	厂商自己的刷新周期
是否保证被采用	不保证	不保证	不保证

由此引出两个很实际的结果。

注册信息里的国家字段是行政记录，不是测量结果。 RFC 9632 说得很直接：注册对象里 country:、geoloc: 这类提示 "tend to be administrative, and not deployment specific"——想想那些总部离自己绝大部分部署地点都很远的全球化服务商就明白了。一个分给荷兰主体的 /24，实际跑在法兰克福，country: 字段照样可能写着荷兰。

发布 Geofeed 不会覆盖掉任何东西。 每家 GeoIP 厂商维护自己的数据，各自决定给自发布 feed 多少权重。有的会读取 feed，有的会拿它和自己的测量结果混着算，有的对某个具体前缀可能完全不用它。feed 确实有人在读：RFC 8805 里记了一笔，RFC 撰写时已有主要使用方在处理约 400 份 feed、覆盖超过 75 万个前缀。这说明机制是活的，但不代表某一份具体 feed 一定会被谁读到。

确有一处规则会让 Geofeed 改变结论，而它约束的是使用方，不是被存下来的数据。RFC 9632 要求：已经取到某地址段 Geofeed 数据的使用方，必须忽略该地址段的其他地理提示——country:、geoloc: 属性，以及 DNS 地理记录。这是对使用方处理流程的约束，它不修改注册对象，对象里的属性原样不动。所以，遵循规范并且真的读取了这份 feed 的使用方，会在这段地址上优先采用 feed 而不是其他提示——这是一条处理顺序上的规则，不是说 feed 就一定准确。不读的，一切照旧。

4. 其他系统怎么找到你的 Geofeed

一个文件挂在 URL 上，如果没人知道去哪找，那它等于不存在。而 RFC 8805 恰恰没写这件事——它只定义格式。早期草案里提过通过 WHOIS 或 RIR 数据库来发现，但正式版 RFC 明确说明这些机制 "has never been implemented"，相关段落也删掉了。

RFC 9632（Finding and Using Geofeed Data）补的就是这块：它规定注册对象如何指向 geofeed 文件。

inetnum: 192.0.2.0/24
geofeed: https://example.net/geofeed.csv

如果某个注册库还不支持 geofeed: 属性，同样的信息写进备注：

inetnum: 192.0.2.0/24
remarks: Geofeed https://example.net/geofeed.csv

实操上有几个细节容易踩：

两种写法不等价，但都必须能读。 remarks: Geofeed 这个标记大小写敏感；如果同一个对象里两种形式都在，应当以 geofeed: 属性为准。合规的使用方必须两种都能处理，因为不是每个注册库都实现了这个属性。
支持情况因注册库而异。 RFC 9632 发布时，inetnum 对象里的 geofeed: 属性已经在 RIPE 和 APNIC 数据库实现。还没实现的库用备注形式。ARIN 的注册数据不是 RPSL 格式，它的 NetRange 和 Comment 键分别对应 inetnum 和 remarks。
一个对象只放一条引用。 应当最多只有一个 geofeed 引用，且只指向一个 feed 文件——不能是目录，也不能是一捆文件。
注册库只存指针。 它不会去验证那个 URL 上的文件准不准、更新没更新、甚至还在不在。RFC 9632 描述了一套可选的 RPKI 签名机制，让发布方能对自己的 feed 做加密归属，但它是可选项——没有签名的 feed 仍然是合法的 feed。
IPv6 同理。 上面关于 inetnum 说的每一句，都适用于 inet6num。

白脸小鹿顺着一条细细的指针线，从一张注册卡片跨过一小段空隙，连到板子上钉着的另一张空白文件。

注册对象里并不装位置数据，它只是指向那个装着数据的文件。

5. 租来的 IPv4，谁来发布和更新 Geofeed

到这一步，租赁的事才开始真正上场，而且答案比看上去要绕一点。

Geofeed 不在租赁合同里，它在一个注册对象里。谁能改这个对象，由对象授权规则决定——具体说，就是保护它的那个 mnt-by: maintainer。拿到一份签了字的合同和一批地址，本身并不会给你编辑那个地址段注册记录的权限。

对于由 RIPE NCC 和 LIR 共同管理的分配对象，对象上挂着两个 maintainer，具体哪些属性谁能改，由业务规则决定。通常情况下，持有该分配的 LIR 才是能发布或修改其下前缀 geofeed: 引用的一方。

放到租赁场景里，分工大致是这样：

事项	通常由谁持有
覆盖该前缀的注册对象	资源持有方 / LIR
在其上添加或修改 `geofeed:` 的权限	该对象的 maintainer
CSV 文件本身托管在哪	由双方约定，只要 URL 稳定即可
feed 内容（哪个前缀写哪个城市）	通常是知道设备实际部署位置的一方
设备搬迁后更新 feed	必须写进约定，否则就不会有人做

最常见的失效场景一点不复杂：地址段从法兰克福搬到阿姆斯特丹，没人动那个文件，feed 继续发布一份看起来正确、实际已经过时的答案。过期的 feed 和没有 feed 一样不可信，会交叉核对的使用方一眼就能看出矛盾。

租用地址段上线之前，有五件事值得白纸黑字定下来：

1. feed 覆盖的具体前缀
2. 该前缀发布哪些位置取值
3. 谁有权在注册表里新增或修改 geofeed 引用
4. 谁维护 CSV 文件，URL 挂在什么地方
5. 变更怎么提、大概多久处理完

SKNK 在 IPv4 地址租赁服务里，把 Geofeed 和位置记录列为可以按合同或 Order 定制的项目。真正的范围划定就在这个层面：前缀、发布内容、授权方、变更路径。如果审核权限对你的部署很关键，在申请阶段就提出来，别等交付后再补——这和租赁中 route、ROA、LOA 的安排是同一套纪律。

白脸小鹿拿着笔在一张空白注册卡上写下一笔，旁边小架子上放着两张等待处理的申请卡。

只有保护该对象的 maintainer 能改动里面的引用——租约本身不带这项权限。

6. 怎么核对结果，以及 Geofeed 改不了什么

核对就四步，按链路顺序走：

1. 查询覆盖该前缀的注册对象
   找 "geofeed:" 或 "remarks: Geofeed"，记下 URL
2. 请求这个 URL，确认返回的是一个 feed 文件
3. 在文件里找到交付给你的前缀，核对取值
4. 对照多家地理位置服务，并记录核对日期

第 4 步是「核查」和「假设」的分界线。各家服务的更新节奏不同，只看一家，证明不了多少东西。如果是替客户做核对，把查询了哪几家、哪天查的记下来，和 IP 声誉核查的做法一样。

白脸小鹿把一条细指针线和一排各自独立的仪表对照着看，每个仪表的读数都不一样。

好几家服务、好几个更新节奏：核对的意思就是多看几个读数，并记下日期。

接下来说说它改不了什么，说清楚一点：

Geofeed 不改变 BGP 路由。 它不是 route object，不是 ROA，也不是起源授权。前缀怎么走由 BGP 和路由策略决定，前缀显示在哪由数据库决定，这两套系统互相不读对方。
Geofeed 不保证第三方服务一定会跟着变。 它给的是一条提示，权重多少由使用方自己定。
Geofeed 不替代注册信息里的 country: 字段。 它是补充。遵循 RFC 9632 并且真的读了 feed 的使用方，会优先采用 feed 而不是该地址段的其他地理提示，但注册数据本身不会被任何人改写。
Geofeed 不会让一个地址段「归属」某个国家。 有些服务会把位置当成准入判断的因素。发布 feed 是在纠正一条数据记录，不是在迁移一项资源，把它说成后者，只会带来错的预期。
Geofeed 不是注册要求。 没有哪条规定强制持有方必须发布。它一般是位置数据不准已经造成实际损失之后，运营方才会去采用的做法。

FAQ

发布 Geofeed 后，所有 GeoIP 服务都会显示同一个位置吗？

不会。它提供的是公开提示。读取 geofeed 的服务大体上会跟着反映——有的很快，有的要等一个刷新周期；而依赖自身测量的服务可能完全不改，也可能继续把它和其他信号混着用。如果某一家服务对你很重要，直接去查那家，别指望 feed 能一次性解决。

租来的 IPv4 地址段，位置能改吗？

多数情况下可以——发布一份 Geofeed，并让注册表里的引用更新过来。但这两步都依赖未必是你的那一方：注册对象的 maintainer 得动手改，而且要有足够多的使用方去读这份 feed。所以「谁有这个权限」这个问题，签之前问，别签完再问。

Geofeed 和 RIR 的国家字段是一回事吗？

不是。注册对象里的 country: 是行政注册数据。RFC 9632 指出这类位置提示 "tend to be administrative, and not deployment specific"，所以它的取值并不代表设备实际跑在哪里。联系人信息记在同一个对象的其他字段里。Geofeed 是另外一份、可选、自发布的声明，说的是地址实际在哪里使用。遵循 RFC 9632 并且读了 feed 的使用方会优先采用它、而不是该地址段的其他地理提示，但 country: 属性本身并不会被改写。

Geofeed 会改变流量走向吗？

不会。路由和位置是两套系统，Geofeed 只存在于位置那一套里。要改流量怎么到你的前缀，那是路由变更——origin ASN、route object、ROA 和上游策略——不是改 Geofeed 能办的事。

结尾

Geofeed 纠正的是一条数据库记录，它不搬运任何一条路由。

Geofeed 的价值很窄，但很实在：让知道设备部署在哪的一方，用使用方能读的格式把这件事讲出来，不用等别人去猜、还猜错。它做不到的，是强迫别人同意——GeoIP 厂商不会，自己有测量结果的服务不会，路由表更不会。

对租来的地址段，真正有用的问题不是「发个 Geofeed 能不能修好我的位置数据」，而是「这段前缀，谁有权限发布和更新 Geofeed」。答案在注册对象的 maintainer 手里，也在 Order 里，所以它应该和反向 DNS、路由记录、滥用处理一起，写进签约前的确认清单。

Key Takeaways：

Geofeed 是自发布的 CSV，把前缀映射到粗粒度位置数据，格式由 RFC 8805 定义。
它承载国家、大区、城市三类信息；邮编字段已废弃，新 feed 不建议再包含。
发布 Geofeed 不会强制任何 GeoIP 服务采用它，使用方可以只把它当提示。
RFC 8805 没规定怎么找到 feed；RFC 9632 定义了注册表引用方式，即 geofeed: 属性或 remarks: Geofeed，且各注册库支持情况不同。
修改这条引用取决于注册对象的 maintainer，而不是你有没有租约——所以「谁发布、谁更新」必须写进订单。
Geofeed 对 BGP 路由没有任何影响，也不会改写注册信息里的 country: 字段。

一句话总结： Geofeed 是一份自发布、刻意做得粗的文件，用来告诉地理位置使用方前缀在哪被使用——它能纠正部分数据库的显示，但不动路由、不改注册记录，也不逼任何一家服务跟着改。

继续阅读：

什么是 IPv4 反向 DNS（PTR）？ —— 跟着租用地址段走的另一条记录，以及它由谁控制。
IPv4 租赁 IP 声誉核查清单 —— 和位置数据并行的签约前核查。
IPv4 租赁中的 route、ROA、LOA —— 租约里的路由记录，以及它为什么是另一套系统。
如何租用 IPv4 地址 —— 租赁转移了什么、没转移什么。
IPv4 小于 /24 的租赁 —— 前缀小于 /24 时，哪些环节会变。
什么是 IPv4？ —— 这些记录所描述的那套地址空间。
SKNK IPv4 租赁 —— 价格、范围，以及可以按 Order 定制的项目。

技术资料核对： RFC 8805（自发布 IP 地理位置 feed 格式）、RFC 9632（Geofeed 数据的查找与使用）、RFC 5737（IPv4 文档保留网段）、RFC 3849（IPv6 文档保留前缀）、RIPE Database 主要对象说明（inetnum / inet6num）。