HN讨论 · 身份未知
零配置实时查看 Docker 容器出站连接，避免 sidecar 与反向 DNS
homelab Docker 用户希望直接看到每个容器实时连接到哪些域名或 IP，但常见做法要么引入 sidecar 代理或改动容器配置，要么依赖反向 DNS，而 anycast CDN IP 会让反向 DNS 失效。dsnitch 用 eBPF 自动发现容器并嗅探 UDP/53 DNS 响应，提供零配置、只读的实时 TUI。
查看原始信号hn:49586159
目标用户
运行 homelab Docker 容器、想了解容器出站网络行为的个人用户或小团队
潜在需求
一个无需改动容器、无需 sidecar、自动发现运行中容器并实时展示其出站连接目标域名/IP 的可视化工具，且 IP 到域名的解析不依赖反向 DNS。
发生场景
homelab 中运行多个容器时，用户想确认某个容器正在连接哪些外部服务，用于排查异常流量或做轻量安全审查；现有方式需要旁挂代理、修改容器配置或靠反向 DNS 反查 IP，而 anycast CDN IP 无法用反向 DNS 映射到域名。
来源证据
作者构建 dsnitch，是因为他想在 homelab 中零配置实时查看 Docker 容器出站连接，并避免 sidecar 代理、修改容器配置及依赖在 anycast CDN IP 上失效的反向 DNS。
Hi HN, I built dsnitch because I wanted a zero-config, bandwhich-style live TUI to see what my homelab Docker containers are connecting to—without running sidecar proxies, modifying container configs, or relying on reverse DNS (fails on anycast CDN IPs). Just run the binary and it automatically discovers running containers. Under the hood, it's written in Rust and attaches eBPF probes to the unified cgroup v2 hierarchy and TCP state tracepoints. To map IPs back to domain names accurately, ithttps://news.ycombinator.com/item?id=49586159
为什么值得留意
作者基于自身 homelab 场景构建了零配置、只读的 eBPF 方案，直接回应了现有工具配置成本高和反向 DNS 失效的痛点；这种轻量路径可能成为容器出站审计的实用替代，值得进一步验证真实用户场景。
已有方案
- sidecar 代理
- 修改容器配置
- 反向 DNS 解析
未满足部分
- 不引入附加组件即可查看逐容器出站连接的手段
- 不依赖反向 DNS 的 IP 到域名映射方式
可能延伸 · 模型推测
- 扩展追踪非 Docker 进程或 systemd 单元的出站连接
- 捕获 DNS over HTTPS/TLS 以补足加密 DNS 场景的域名映射
- 将实时连接导出为日志或接告警，用于异常外联检测
- 适配集群或多主机环境以覆盖更多容器部署形态
目前未知
- 目前只有作者自述，缺少独立用户评论或反馈
- 需要 Linux 5.8+ 和 eBPF 权限，可能排除部分 homelab 环境
- DNS 嗅探仅覆盖明文 UDP/53，加密 DNS 下只能显示 IP
- 工具长期稳定性和维护投入尚未验证
继续核实
- homelab Docker 用户对容器出站连接可视化的需求是否普遍，现有工具为何未满足？
- 反向 DNS 在 anycast CDN IP 上失效的频次是否构成足够强的痛点？
- 零配置 eBPF 方案与 sidecar/网络插件方案相比，用户更看重配置成本还是功能完整性？
主题词
docker egress monitoringcontainer network visibilityebpf network inspectionreverse dns limitationdns response decoding