// ARCHIVE Words and Reflections · LONELY HORSE ## 一、背景 # 一次 FastAPI /metrics 的公网暴露问题的排错和修复 ## 一、背景 我的博客服务运行在 T630 设备上，公网访问主要通过 Aliyun 服务器上的 Nginx 反向代理进入。博客后端使用 FastAPI，并通过 `/metrics` 暴露 Prometheus 指标，供内部 Prometheus 抓取监控数据。 ## 二、现象 我在外界直接搜索域名 + `/metrics` 居然可以直接看到我的很多 Prometheus 指标数据信息，虽然不致命，但是依旧属于是敏感信息行列。 ## 三、误区 最开始我以为，本身设备不具备公网 IP，处于内网就不会受到其他的攻击或者是外界的非法访问。 ## 四、原因 Aliyun 服务器已经使用 Nginx 反向代理 T630 设备固定端口的所有路径，这样会导致我的 `/metrics` 原本只是暴露给 Prometheus 的指标数据可以被外界直接打开访问。 ## 五、修复 我认识到这个问题的重要性，选择了控制服务器的 Nginx 开放程度，将 `location = /metrics` 的路径严格控制，该路径下的外部访问一律返还 403。但是这只是会影响到从公网域名和公网 IP 访问的用户，并不会影响到我的内部设备之间的数据抓取。 ## 六、验证 首先，从外部浏览器访问域名 + `/metrics` 路径进行测试，网页实际返还 403 错误码，Nginx 路径限制成功。然后经过 Prometheus 界面实际观测和访问内部 Tailscale 地址数据的流通，可以显示，说明本身可以被内部访问抓取，基本完成限制任务。 ## 七、总结 这次问题让我意识到，服务是否暴露到公网，不只取决于设备有没有公网 IP 或端口是否开放，还取决于公网入口的反向代理规则。对于 `/metrics` 这类观测接口，应该和业务页面区分访问面，让公网访问业务页面，让 Prometheus 通过 Tailscale 内网抓取指标。 ← RETURN HOME