从日志和文本里提取 IPv6 地址:运维排查实战指南

我排查过一次夜里的异常访问,Nginx 访问日志和防火墙日志各几万行,里面 IPv4 和 IPv6 混在一起。要把所有 IPv6 来源 IP 拉出来做个清单,手工 grep 写正则改了三遍还是漏,因为 IPv6 的写法太活。后来我把整段日志贴进 IPv6 地址提取器,十几秒就拿到了一份去重后的地址表。这篇就把这套排查方法讲清楚。

IPv6 地址长什么样

先把格式说明白,不然提取规则永远写不对。一个完整 IPv6 地址是八组四位十六进制数,用冒号分隔,比如 2001:0db8:85a3:0000:0000:8a2e:0370:7334。每组取值 0000 到 ffff,大小写不敏感。

它有两个常见简写,日志里几乎都是简写形式:

前导零可省略,0db8 写成 db8,0000 写成 0。
连续的全零组用 :: 替代,一个地址里只能出现一次。上面那个地址可以缩成 2001:db8:85a3::8a2e:370:7334。

还有内嵌 IPv4 的混合写法,像 ::ffff:192.168.1.1,这是 IPv4 映射地址,日志里也会碰到。如果你的正则只认八段完整冒号形式,这些缩写和混合写法全部会漏掉。

为什么手写正则容易翻车

:: 缩写是最大的坑。它代表"这里有一段连续的零",但具体补几组要靠总段数倒推,纯文本正则没法可靠地数段数。再加上地址前后常带方括号和端口,比如 [2001:db8::1]:8080,以及结尾可能挂着区域索引 %eth0,一条规则想全覆盖就会越写越长,最后还是有漏网的。

IPv6 地址提取器内置的解析器把这些情况一并处理:认 :: 压缩、认内嵌 IPv4、自动剥掉方括号端口和周围文字,只留地址本身。畸形的也不丢,而是单独标出原因,方便你区分真假。

一段日志的真实提取例子

假设你从防火墙日志里复制了这么一段:

Jun 13 02:11:04 fw kernel: DROP IN=eth0 SRC=2001:db8::1f2 DST=fe80::1
Jun 13 02:11:07 fw kernel: DROP IN=eth0 SRC=[2400:cb00:2049::a29f:1804]:443
Jun 13 02:11:09 fw kernel: ACCEPT SRC=2001:db8::1f2 note=12345::1 bad
Jun 13 02:11:12 fw kernel: DROP SRC=::ffff:203.0.113.9

粘进去后,提取并去重的结果是:

2001:db8::1f2
fe80::1
2400:cb00:2049::a29f:1804
::ffff:203.0.113.9

注意三件事:第一行的 2001:db8::1f2 出现两次,去重后只留一条;[...]:443 的方括号和端口被剥掉;那个 12345::1 因为第一组超过四位十六进制,被判为无效项单独列出,不会混进干净清单。

排查工作流:从原始日志到可交接清单

我现在固定这么走:

把访问日志、防火墙日志或 ip -6 addr 输出整段贴进提取器。
开启去重,按规范化结果排序,先拿到唯一地址清单。
保留无效项一起看,确认是不是日志被截断或被篡改留下的痕迹。
导出 CSV 或 Markdown,带上行号,作为这次排查的审计记录交接给同事。

如果你只想把一份混乱地址做格式统一,不必跑完整排查,可以直接用 IPv6 地址规范化工具把缩写和大小写拉齐;只需要确认每条是否合法,用 IPv6 地址列表校验器更快。提取本身在 IPv6 地址提取器一步完成。

去重和数据安全

日志里同一个来源 IP 重复几百次是常态,去重前那张表没法看。提取器默认按规范化后的值去重,也就是说 2001:DB8::1 和 2001:db8::1 会被认成同一个,不会因为大小写或前导零的写法差异漏判。如果你的日志里 IPv4 和 IPv6 混着,先把 IPv6 抽出来,再用 IPv4 地址列表校验器单独处理那一半,两条线互不干扰。

更要紧的一点:这类数据常带客户来源 IP,属于敏感信息。整个解析、校验、去重、复制、下载流程都在浏览器本地跑,上传的文件通过 File API 在当前标签页读取,不发到任何服务器。排查内网日志时这一条很关键,你不用担心把内部地址泄到第三方。

小结

IPv6 提取的难点不在工具,在于它的缩写规则让手写正则总有死角。把格式吃透,再交给一个认得 :: 缩写、内嵌 IPv4、方括号端口的解析器,排查就从"改正则改半小时"变成"贴进去看结果"。去重、保留无效项、带行号导出,这三步让一份原始日志变成可复核、可交接的清单。

Made by Toolora · Updated 2026-06-13