ip maddr show 是首选，因它直接读取内核 IGMP/MLD 维护的真实组播成员表，反映实际加入状态而非配置或套接字绑定；输出为空不等于未加入，可能尚未触发 Report，且需注意接口状态、命名空间隔离及 IPv4/IPv6 区分。
直接看内核当前维护的组播成员状态，用 ip maddr show 最准——它反映的是 IGMP/MLD 实际加入结果，不是配置、不是猜测、不是进程列表。
为什么 ip maddr show 是首选
netstat -g 和 ss -g 会列出“绑定到组播地址的套接字”，但不等于“已加入组播组”；一个进程 bind() 到 224.0.0.1 并不触发 IGMP Report，内核不会把它记为成员。ip maddr show 读取的是内核网络栈中由 IGMP/MLD 协议维护的真实成员表，和路由器看到你是否发过 Report 完全一致。
- 输出为空 ≠ 没有程序想加入：可能还没发第一个 Report（比如刚启动的服务还没触发 discovery）
- 出现
inet 224.0.0.1或inet6 ff02::1是正常默认行为，不代表你的业务服务已就绪 - docker0、cni0 等虚拟接口也会显示条目，需结合
dev参数过滤，避免误判物理网卡状态
查特定组播地址是否被加入
别靠肉眼扫，用 grep 精准匹配。注意 IPv4 地址格式必须严格，239.192.0.1 不能写成 239.192.1：
ip maddr show | grep '239\.192\.0\.1'
IPv6 要注意 scope 前缀：ff02::1（链路本地）和 ff05::1（站点本地）语义不同，不能混用。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 如果没匹配到，再检查对应接口是否存在：运行
ip link show dev eth0确认接口 UP 且 MULTICAST 标志存在 - 某些容器或 network namespace 中执行该命令，只能看到该命名空间内的成员，不是宿主机全局视图
- 若目标地址是 IPv4，但输出只有
inet6行，说明根本没走 IPv4 IGMP 流程——可能是应用只调用了 IPv6 socket
/proc/net/igmp 里看到的十六进制地址怎么换算
/proc/net/igmp 的 Group 字段是小端序逆序的十六进制，例如 010000E0 对应 224.0.0.1：
- 拆成字节：E0 00 00 01 → 倒序 → 01 00 00 E0
- 转十进制：01→1, 00→0, 00→0, E0→224 → 得
224.0.0.1 - 查
239.255.0.1：先转为十六进制0100FFEF，再倒序为EF FF 00 01，搜索EF00FF01（注意无分隔符）
手动换算容易出错，日常排查优先用 ip maddr show；只有调试 IGMP 报文或验证内核行为时才碰这个文件。
常见误判点：看到地址 ≠ 服务可用
组播地址出现在 ip maddr show 输出里，只说明内核收到了 JOIN 请求并接受了它，不保证：
- 对应进程仍在运行（进程崩溃后内核不会自动清理成员项，需重启或等待 IGMP timeout）
- 网卡物理连通（交换机未开启 IGMP snooping 或 ACL 拦截了 224.0.0.x）
- 防火墙放行入向组播报文（
iptables -I INPUT -d 239.192.0.1 -j ACCEPT必须显式加） - 应用层真正收到了数据（UDP recvfrom() 是否阻塞？缓冲区是否溢出？）
真正要确认服务级可用，得配合抓包（tcpdump -i eth0 host 239.192.0.1）和应用日志交叉验证——ip maddr show 只是第一道门，不是终点。
