← Problem Library
K8s L4 K8S 1199 · 18 min

kubectl port-forward works but ingress still fails because the external hostname path is broken earlier in the chain

Direct pod access proves the app works, yet the external route still fails because the break is upstream of the pod and invisible to port-forward tests.

K8sPlatform ReliabilityLevel 4Pro18 min
Scenario

A team confirms the app with kubectl port-forward and assumes ingress must be fine. The actual failure sits earlier in the edge-hostname or path-rewrite chain.

What to check first
  • Identify the primary failure signal in the Path Layer Separation scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Use port-forward proof correctly: as pod health evidence, not as proof of the full edge path.

Questions worth viewing together
What should you verify first when kubectl port-forward works but ingress still fails appears?

Community-derived ingress troubleshooting scenario based on Stack Overflow and Reddit threads where port-forward success masked edge-path failures. A healthy port-forward narrows the fault domain, but it does not clear ingress, DNS, or edge routing.

What usually causes kubectl port-forward works but ingress still fails in production?

Teams often stop too early once port-forward succeeds.

What should you document after resolving kubectl port-forward works but ingress still fails?

Internal app reachability and external route correctness are different layers of the request path.