跳转至

Prometheus 内网访问"页面打不开"故障报告（终版·含根因纠正）

报告日期：2026-09-03 涉及集群：kubeadm 单集群（master 192.168.0.2 / k8s-master-01，eth0 另绑 secondary IP 192.168.0.8/32） 涉及组件：Traefik v2.5、kube-prometheus-stack、IngressRoute / IngressRouteTCP CRD、frp 0.37.1 报告人：Rain（TRAE 协助排查）

一、故障时间

  • 发现：2026-09-03 上午，内网 Win 电脑部署 prometheus-ingress.yaml 后浏览器访问 prometheus.rainchen.top 打不开。
  • 定位：2026-09-03 下午，经删/建 IngressRouteTCP 对照实验锁定根因。

二、现象（用户对照实验）

Win 浏览器（地址栏 prometheus.rainchen.top/query，即 80 端口）：

操作 Win 浏览器结果
部署 HTTP prometheus-ingress.yaml（80 端口 IngressRoute） 页面打不开
删除 prometheus-ingress-tcp.yaml（IngressRouteTCP） 404 page not found
apply prometheus-ingress-tcp.yaml（IngressRouteTCP on :9090） Prometheus 页面正常

直觉结论："删 9090 的 TCP 路由 → 80 的页面 404；加回来 → 正常"，看似 HTTP 方式有问题、与 Win 本地配置无关。

三、影响范围

  • 内网 Win 通过域名访问 Prometheus 表现异常（依赖 TCP 路由是否存在）。
  • 公网 frp 链路访问 Prometheus 同样依赖 IngressRouteTCP（见根因）。
  • Grafana / Alertmanager 本次未涉及。

四、根因原理（⚠️ 终版结论，含对初步判断的纠正）

4.1 两条独立链路

链路①：内网直连 80（HTTP 七层）——服务端始终正常

Win(若hosts生效) → 192.168.0.8:80 → Traefik web entrypoint
   → HTTP IngressRoute: Host(prometheus.rainchen.top)
   → kube-prometheus-stack-prometheus:9090

该链路完全不依赖 IngressRouteTCP。

链路②：公网 80（frp 隧道）——后端最终落到 0.8:9090，依赖 IngressRouteTCP

浏览器 → prometheus.rainchen.top:80
   → 公网DNS → 129.226.138.204:80 nginx
   → proxy_pass prometheus.rainchen.top:9090 → frps:9090(remote_port=9090)
   → frp隧道 → frpc(192.168.0.2)
   → frpc local_ip=prometheus.rainchen.top:9090
   → 0.2本机hosts解析 → 192.168.0.8:9090 = Traefik prometheus entrypoint(hostPort)
   → IngressRouteTCP(HostSNI *) → kube-prometheus-stack-prometheus:9090

关键：公网 80 请求经 nginx/frps/frpc 反代后，最终打到 0.2 的 9090 端口，而 9090 是 Traefik 的 prometheus TCP entrypoint，必须有 IngressRouteTCP 才有后端： - IngressRouteTCP 存在 → 转发到 Prometheus → 200 - IngressRouteTCP 删除 → 9090 无路由 → Traefik 返回 404 page not found

4.2 决定性根因

Win 浏览器的流量实际走了链路②（公网），而不是 hosts 指定的链路①（内网 192.168.0.8:80）。

判定依据（对照实验，见第五节）：删除 IngressRouteTCP 后， - 内网 80（192.168.0.8:80 / 192.168.0.2:80）始终返回 200（证明 HTTP IngressRoute 服务端毫无问题）； - 公网 80（prometheus.rainchen.top:80）和内网 9090 同时变 404； - Win 浏览器在删除后恰好显示 404 —— 与公网链路表现完全一致，与内网 80 表现矛盾。

因此： 1. HTTP 方式的 IngressRoute（80）服务端配置完全正常，不是故障点。初步报告中"Win 客户端 hosts 可能未指对"的方向正确，但当时缺铁证；本版用对照实验证实 Win 流量根本没走内网。 2. Win 本地 hosts 虽然配置了 192.168.0.8 prometheus.rainchen.top，但未真正生效，浏览器请求被导向了公网。最可能原因（按概率）： - 浏览器/系统开启了 HTTP 代理（科学上网/公司代理/SwitchyOmega 类扩展）：代理模式下浏览器把请求发给代理服务器，由代理在公网侧做 DNS 解析，本地 hosts 被完全绕过； - 浏览器启用了安全 DNS（DoH）或存在 DNS 缓存（未 ipconfig /flushdns、未重启浏览器）； - hosts 文件编码问题（UTF-8 BOM/异常换行）——本次截图格式正常，可能性低。 3. 用户"加 TCP 路由就能访问"本质是：TCP 路由让公网链路②的后端（0.8:9090）恢复转发，Win 走公网也能打开页面，造成"TCP 方式有效"的表象；真正的内网 80 链路一直是好的。

4.3 hostPort 机制说明

Traefik 非 hostNetwork，通过 CNI portmap 的 iptables DNAT 把宿主机 hostPort（80/443/9090/3000/9093…）转发到 Traefik Pod。故宿主机 ss -tlnp | grep :80 看不到监听进程属正常现象，不代表端口不通。

五、证据摘要

5.1 删/建 IngressRouteTCP 对照实验（核心铁证）

测试目标 TCP 路由存在 TCP 路由删除 TCP 路由重建
内网 192.168.0.8:80（Host 头）/query 200 200 200
内网 192.168.0.2:80（Host 头）/query 200 200 200
公网 prometheus.rainchen.top:80 /query 200 404 200
内网 192.168.0.8:9090 /-/healthy 200 404 200

结论：内网 80 与 TCP 路由无关（恒 200）；公网 80 与 9090 同生共死（受 TCP 路由控制）。Win 删除后 404 → Win 走公网。

5.2 链路配置证据

项 值 / 结果
0.2 网卡 IP eth0 含 192.168.0.2/24 与 192.168.0.8/32（同一台机器）
0.2 /etc/hosts 192.168.0.8 prometheus.rainchen.top（frpc 据此连本机 9090）
frpc.ini [k8s-prometheus] type=tcp, local_ip=prometheus.rainchen.top, local_port=9090, remote_port=9090
Traefik entrypoint --entrypoints.web.Address=:80、--entrypoints.prometheus.Address=:9090
Traefik hostPorts 80、443、9090、3000、9093、…
后端 Service/Endpoints kube-prometheus-stack-prometheus ClusterIP 10.107.81.213:9090 → 10.244.5.34:9090 Ready
404 响应特征 Content-Length: 19、无 Server 头 → Traefik/frp 默认 404（无路由）
防火墙 firewalld inactive（非防火墙问题）

注：集群重建后 Service 名为 kube-prometheus-stack-*，与旧 SOP 记录的 prometheus-kube-prometheus-* 不同。

六、解决方案

6.1 服务端（已完成，保持现状）

IngressRouteTCP 已创建并保持存在，保证公网链路②与 9090 直连可用：

kubectl get ingressroutetcp -n monitoring
# NAME                 AGE
# prometheus-ingress   ...

HTTP IngressRoute（80）也在，内网链路①随时可用。

6.2 Win 端：让流量真正走内网（推荐，省公网带宽、延迟低）

  1. 关闭代理（最关键）
  2. Windows：设置 → 网络和 Internet → 代理 → 关闭"使用代理服务器"，"自动检测设置"可保留。
  3. 浏览器：检查 SwitchyOmega / 科学上网扩展，切到"直连"或"系统代理"；无痕窗口复测。
  4. 刷新 DNS 缓存：管理员 cmd 执行 ipconfig /flushdns，然后完全重启浏览器。
  5. 确认 hosts：C:\Windows\System32\drivers\etc\hosts（管理员打开）含 192.168.0.8 prometheus.rainchen.top
  6. 验证解析：cmd 执行 ping prometheus.rainchen.top
  7. 显示 [192.168.0.8] → hosts 已生效（走内网）；
  8. 显示 [129.226.138.204] → hosts 仍未生效（多为代理/DoH 拦截）。
  9. 验证连接 IP：curl -v http://prometheus.rainchen.top/query，看 Connected to prometheus.rainchen.top (x.x.x.x) 是否为 192.168.0.8。

6.3 不依赖域名的内网直连验证

  • 浏览器直接访问 http://192.168.0.8:9090（9090 的 IngressRouteTCP 用 HostSNI(*)，不校验 Host 头）→ 应直接出 Prometheus 页面。能打开即证明内网与 TCP 路由正常。

七、验证结果

  • IngressRouteTCP 存在时：内网 80、内网 9090、公网 80 均 200。
  • IngressRouteTCP 删除时：内网 80 仍 200；公网 80 与内网 9090 404。
  • 服务端 0.2 本机 curl http://127.0.0.1:9090/-/healthy → Prometheus Server is Healthy.
  • Win 端按 6.2 关闭代理 + flushdns 后，ping 应解析到 192.168.0.8，访问 http://prometheus.rainchen.top 走内网 80 正常（待用户确认）。

八、回滚方案

本次仅新增 1 条 IngressRouteTCP（声明式 CRD，源文件 prometheus-ingress-tcp.yaml 即备份）：

# 删除后：公网链路②与9090直连变404；内网80(HTTP IngressRoute)不受影响
kubectl delete ingressroutetcp prometheus-ingress -n monitoring

建议保留该 TCP 路由——它同时承载公网 frp 链路与 9090 直连，删除会导致外出公网访问失效。

九、预防建议

  1. 排查访问问题先分清"走内网还是走公网"：浏览器代理极易绕过本地 hosts。用 ping 域名/curl -v 确认实际连接 IP，不要只看 hosts 文件内容。
  2. apply 后必须 kubectl get 确认资源落地（本次 TCP 路由最初未创建成功即因此被忽略）。
  3. Service 名称变更：集群重建后为 kube-prometheus-stack-prometheus/grafana/alertmanager，请回写更新旧 SOP 第三章表格。
  4. Traefik entrypoint 拼写坑：Grafana 入口名是 --entrypoints.granafa.Address=:3000（granafa 拼错），配 Grafana 的 IngressRouteTCP 时 entryPoints 必须写 - granafa。
  5. Grafana/Alertmanager 公网/9090 类直连同理：frpc 已配 3000/9093 隧道，若要公网或端口直连，需分别在 Traefik 的 granafa(:3000)、alertmanager(:9093) entrypoint 上建对应 IngressRouteTCP（后端 kube-prometheus-stack-grafana:80→注意容器端口、kube-prometheus-stack-alertmanager:9093）。
  6. 长期建议：内网用户优先靠内网 DNS/hosts 走链路①（80），公网 frp 链路②仅作外出兜底；两条链路后端端口不同（80 用 HTTP IngressRoute，9090 用 IngressRouteTCP），排障时勿混为一谈。

十、变更记录

时间 操作 结果
2026-09-03 创建/重建 IngressRouteTCP prometheus-ingress（monitoring，:9090） 公网链路②与 9090 直连恢复 200
2026-09-03 删/建对照实验 证实内网 80 恒正常、公网 80 依赖 TCP 路由、Win 实际走公网

来源：/home/rain/Documents/trae_for_om/prometheus_grafana_internal_access/prometheus-ingress访问故障排查-20260903/prometheus-ingress访问故障报告-20260903.md ｜ 最后更新：2026-09-03 19:47（由 build/sync.py 同步，请勿在站点侧修改）