内网服务速查页：用一份 JSON 加反向代理管住所有端口

背景

家里的内网设备越来越多：几台 Arm 小主机、一堆容器、还有若干个只在内网可用的小服务。每次想知道“现在哪台机器、哪个端口上跑着什么”，都得到处翻笔记。用久了就想要一个不依赖外部服务、打开网页就能看的内网资产与端口速查页。

做了什么

我用一台 ARM64 小主机做反向代理，再加一个纯静态的查询页：代理负责把 *.example.lan 这类域名分发到不同端口，静态页只负责展示信息。整页没有后端、没有数据库，数据就一份 JSON，改完刷新即可生效。

关键点有三个：一是所有服务只在内网监听，公网零暴露；二是页面本身只需要一次 HTTP GET 就能拿到全部信息，不用轮询也不建长连接；三是有个健康检查脚本，每隔几分钟抓一次各服务的状态码，把结果写回那份 JSON。

关键机制

反向代理侧用一份很短的配置描述“域名 → 上游地址”，这样新增服务只改一行。静态页读取的 JSON 结构很平：每个条目记名称、域名、端口、健康状态、最后探测时间。健康检查脚本只做一件事——对每个条目发一次 GET，记录 HTTP 状态码和耗时，超时也记成一种状态，而不是直接判成“挂了”。

这样做的好处是排障时能区分三种情况：服务没起来、服务起来了但路径写错（404）、服务活着但很慢。以前全归成“打不开”，现在一眼能看出是哪一类。

踩的坑

第一个坑是 DNS。*.example.lan 这类通配解析在部分路由器上不生效，得在内网 DNS 里显式加上。第二个坑是健康检查的判定：一开始只看状态码 200，结果有些正常服务会返回 204 或 401，被误报成故障。后来改成“只要能连上并返回任意 3xx/4xx 都算活着”，误报就没了。

第三个坑最容易忽视：容器用 host 网络模式时，DNS 解析可能被注入成空的，导致所有外部请求都超时。排查时先看容器内的 /etc/resolv.conf，比怀疑上游服务快得多。

结论

这套东西的价值不在技术含量，而在于把“我知道它大概在哪”变成“我能查到它现在怎么样”。一个静态页 + 一份 JSON + 一个探测脚本，加起来不到三百行，却省掉了大量翻笔记的时间。如果你也有类似的内网服务，建议先做一份准确的清单——清单本身就是最有用的工具。