Hubble UI打不开是因服务未运行或未暴露，需检查Pod状态、将Service改为NodePort/Ingress，或用kubectl port-forward svc/hubble-ui 20200:80；流量不显示因默认不采集策略拒绝事件，需启用hubble.listen-address、hubble.metrics及hubble.enable-egress-policy，并确认内核支持。
为什么 Hubble UI 打不开或显示“Connection refused”
本质是 hubble-ui 服务没跑起来，或者没暴露给浏览器访问。它默认只监听 127.0.0.1:20200，宿主机外根本连不上。
- 确认
hubble-uiPod 是否 Running：kubectl get pods -n kube-system | grep hubble-ui - 检查 Service 类型：默认是
ClusterIP，必须手动改成NodePort或加ingress，否则浏览器无法直连 - 别直接访问
localhost:20200—— 那是容器内部端口，不是你本机的 - 若用
kubectl port-forward临时调试，命令得写对：kubectl port-forward -n kube-system svc/hubble-ui 20200:80（注意是 svc/，不是 pod/）
网络策略在 Hubble UI 里查不到流量记录
Hubble 默认只采集 L3/L4 流量元数据，不开启 eBPF trace 或 flow logging 时，策略拒绝事件不会上报。
- 确认 Cilium 安装时启用了
hubble.listen-address（如:4244）且hubble.metrics包含dns,drop,tcp,flow -
CiliumNetworkPolicy拒绝流量只有带rule.action: DENY且启用了hubble.enable-egress-policy才会出现在 Flow 视图 - UI 左上角时间范围默认是 5 分钟，新策略生效后没流量触发？手动发个
curl测试下，别干等 - 如果看到大量
UNKNOWN协议或空源/目标 IP，大概率是节点没开bpf-clock-probe或内核版本太低（
点击 Flow 记录跳转到 Policy 视图却显示“no matching policy”
不是策略没生效，而是 Hubble 的策略匹配逻辑只看当前连接的五元组是否被某条 CiliumNetworkPolicy 显式允许/拒绝，不回溯旧版本或 CRD 删除残留。
- 确保策略已成功 Applied：
kubectl get cnp -A看 STATUS 列是不是OK，不是Invalid或空 - 策略里写的
endpointSelector必须精确匹配 Pod label，大小写、连字符一个都不能错；Hubble 不做模糊匹配 - 如果策略用了
toEntities（如all,cluster），Hubble UI 当前版本（v0.12+）仍可能无法关联到具体规则，这是已知限制 - 多租户场景下，命名空间未指定或
namespaceSelector写错，会导致策略“存在但不可见”
用 curl 调 Hubble API 查策略影响比 UI 更准吗
更准，也更直接。UI 是静态快照 + 前端聚合，API 返回的是原始流日志和实时策略评估结果。
- 查某次拒绝原因：
curl -s "http://localhost:20200/v1/flows?filter=type:drop" | jq '.flows[0].dropReason' - 验证策略是否命中：
cilium policy trace --src-k8s-pod default/pod-a --dst-k8s-pod default/pod-b（这个命令比 UI 的“simulate”可靠得多） - API 返回的
policyMatched字段是布尔值，而 UI 有时把not enforced和allowed by default都渲染成绿色，容易误判 - 注意 Hubble API 默认不鉴权，但生产环境务必通过
ClusterRoleBinding限制访问，否则等于裸奔暴露所有网络行为
真正卡住人的往往不是策略写错，而是 Hubble 自身采集链路断在哪儿——比如 hubble-relay 没连上所有节点上的 hubble-server，或者 etcd 存储满了导致 flow buffer 丢弃。先盯紧 kubectl logs -n kube-system ds/cilium | grep -i hubble 里的 warning 级日志，比反复调 UI 有用得多。
