直接回答：NetworkPolicy 是白名单模型：任何一条策略选中某 Pod，该 Pod 对应方向（ingress/egress）未被显式允许的流量全部默认拒绝——且拒绝是静默丢包，应用只看到超时，没有拒绝日志，这是它故障隐蔽的根因。排查第一步永远是 kubectl get networkpolicy -A 确认该 namespace 是否存在策略。

展开解析：系统排法：确认策略存在后读懂语义——podSelector 选中谁、policyTypes 管哪个方向、每条规则的 from/to（podSelector/namespaceSelector/ipBlock 三选）与 ports；跨命名空间引用要 namespaceSelector 与 podSelector 的 AND/OR 关系搞清（同一列表项内是 AND，不同项是 OR，这个坑事故率极高）。验证连通性用临时调试 Pod 打相同 label 复现：curl 目标服务看超时（被策略丢包）还是拒绝（服务没起）——超时才像策略问题。旁证手段：CNI 支持的话看策略下发的实际规则（Calico 的 calicoctl、Cilium 的 hubble observe 能直接看到 flow 被 policy denied 的记录，可观测性差异巨大）；临时放开验证——给可疑 namespace 加一条全通策略（allow-all）对比，恢复即实锤。egress 方向的经典漏配：DNS（53 UDP/TCP 必须放行 kube-dns 否则全员解析挂）、云元数据服务、外部 HTTPS。治理建议：策略即代码走评审与金丝雀（先开日志模式 Cilium 支持）；默认拒绝策略上线前清点所有合法流量（DNS、监控抓取、Ingress 回源最易漏）；命名规范让“哪个策略管哪条流量”可读。

追问方向：为什么 NetworkPolicy 无法用 namespaceSelector 选中自己所在 ns 时用 podSelector 组合？ingress controller 回源流量的策略怎么写？

（约 500 字）