DNS succeeds but the application connection fails

Understand the likely causes

• A correct answer does not prove that the application used it, that the selected family has a route, that the transport endpoint accepts, or that the service identity matches. Proxy termination, cached connections, stale views, policy boundaries, listener configuration, and application authorization can produce different failures after successful DNS.

1. Identify the exact application request

Record scheme, hostname, explicit or default port, method, client context, proxy use, and time. Confirm the application’s selected address and family rather than substituting a lookup performed elsewhere. A browser can reuse an old connection and a container can use a different resolver or route. Keep credentials and payload out of the evidence bundle. The offline example parses a synthetic URL only; it is not a connectivity test. This distinction prevents a successful parser or resolver result from becoming a claim about an untested service path.

from urllib.parse import urlsplit
request = urlsplit('https://report.example:8443/export')
print(f'name={request.hostname} port={request.port} path={request.path}')

name=report.example port=8443 path=/export

2. Locate the first failed protocol milestone

Separate lookup, local next-hop delivery, routed transport, TLS verification, and application response. A TCP timeout differs from a refused connection, and neither is equivalent to a hostname mismatch. An HTTP 403 indicates that an HTTP-speaking component responded, possibly a proxy. Preserve not-reached states rather than treating them as additional independent failures. The first observed failure narrows the next question; it does not automatically reveal the root cause. Compare a healthy request with the same client, family, destination, and timing boundary when such authorized evidence exists.

milestones = [('dns', 'ok'), ('tcp', 'timeout'), ('tls', 'not-reached'), ('http', 'not-reached')]
failed = next(name for name, result in milestones if result not in ('ok', 'not-reached'))
print('first_observed_failure=' + failed)

first_observed_failure=tcp

3. Follow evidence at the failed layer

For transport failure, compare intended route, source selection, listener address, family, and policy in both directions using existing authorized records. For TLS failure, preserve the requested name, chain metadata, time context, and termination point. For an application rejection, inspect the responding component and documented authorization or resource semantics. Do not disable verification or switch DNS servers to hide a later-layer error. A successful test from a different machine is useful comparison evidence but does not reproduce the original routing, proxy, or address-family context automatically.

4. Prepare a correction for the demonstrated cause

Use a synthetic or isolated configuration copy to review the smallest relevant change. Examples include correcting an address-family-specific route in the plan, the intended bind address, a documented proxy destination, or a mismatched service certificate deployment. Preserve rollback and required trust properties. Do not change several layers simultaneously, because a later success would not identify which assumption was wrong. This guide executes no operational correction, scan, capture, handshake, or traffic test; its output is a precise evidence-backed action for an authorized environment.

Keep it from recurring

• Monitor protocol milestones separately, retain endpoint and family context, and document proxy/TLS termination boundaries. Include name, transport, identity, and application failures in offline regression scenarios. Keep resolver changes distinct from service deployment changes and avoid troubleshooting procedures that automatically weaken trust.