“Internal site unreachable” is a chain-of-dependencies problem, not one failure type
A private web application can fail while public Internet browsing remains completely healthy because the internal site may depend on private DNS, an internal route, a particular VLAN or VPN path, segmentation policy, a proxy exception, a reverse proxy or load balancer, a server listener, and enterprise TLS trust. The fastest diagnosis preserves every checkpoint that already works and finds the first unresolved dependency used by the exact internal URL.
Use Scope → Name Resolution → Exact Route → Reachability Boundary → TCP Service → TLS → HTTP/Application → Targeted Change → Positive + Control Verification. “The Internet works” is a useful control, but it proves almost nothing about private dependencies unique to the internal site.
Source scope and destination scope tell you where to look before you run commands
One client fails
Compare resolver, route table, VPN, proxy/PAC state, certificate trust, browser behavior, and endpoint security with a working peer.
One VLAN/site fails
Investigate dependencies shared by that source network: internal route, segmentation policy, DNS reachability, proxy policy, or site-to-site path.
Everyone fails to one site
Destination-side service, reverse proxy/load balancer, DNS record, certificate, deployment, or server-network policy becomes more likely.
Scope by source and destination. If one internal application fails but other private applications in the same server network work, a broad internal-routing outage is less plausible. If every destination in one remote private prefix fails from one campus, the shared route or policy deserves attention.
Separate “name not found,” “wrong address,” and “resolver unreachable” before touching the server
Internal DNS failures do not all look the same. An NXDOMAIN response means the resolver answered that the queried name does not exist in the namespace it used. A timeout means the client did not receive a timely DNS response. A successful answer containing the wrong address is different again: DNS worked mechanically but supplied an unintended destination.
| DNS observation | Bounded inference | Next discriminating evidence |
|---|---|---|
| Working peer resolves; affected client returns NXDOMAIN | Client may be using a different resolver/search context | Compare DNS server, suffix, exact FQDN, VPN state |
| Both clients resolve, but addresses differ | Split-DNS/cache/record path may differ | Query intended resolver directly; compare TTL/records |
| DNS query times out | Resolver reachability/service path unresolved | Test resolver IP/port path and compare another query |
| Hostname resolves to intended private IP | Name-to-address step succeeded | Preserve it; move to route/flow evidence |
Swipe horizontally to see the full table.
If the affected endpoint is pointed at the wrong resolver, compare the failure pattern with Wrong DNS Server Symptoms.
The same hostname can intentionally resolve differently inside and outside the organization
Organizations may publish one answer to internal clients and a different public answer—or no public answer at all. This makes resolver context part of the application path. A laptop disconnected from the corporate network or VPN may query a public resolver that cannot see the private zone. Reconnecting the VPN can change both DNS availability and routing at the same time, so capture both states rather than concluding “VPN fixed DNS.”
portal.corp.example to 10.40.8.25. The affected client resolves nothing and is configured with a public resolver. That comparison strongly supports correcting resolver context before changing the web server.Read the route for the exact private server address—not merely the default route
Public browsing can work through the default Internet route while a more-specific internal route is absent, stale, or pointed into the wrong tunnel. Determine the resolved server IP, then ask which route wins for that exact address. Longest-prefix matching means a specific private route can override the default route.
Illustrative client routes 10.40.8.0/24 via 10.20.1.1 metric 20 10.0.0.0/8 via VPN-Tunnel metric 5 0.0.0.0/0 via 192.168.1.1 metric 25 Target: 10.40.8.25 Question: which matching prefix is most specific, and is its next hop/path usable?
A route's presence is not proof that forwarding succeeds. Next-hop reachability, VPN state, upstream routing, destination-network routing, and the return path remain separate dependencies.
A healthy client VLAN can still be denied access to one protected server zone
Internal web applications often sit behind segmentation boundaries. A client can obtain DHCP, reach its gateway, resolve DNS, browse the Internet, and access other internal networks while a policy specifically blocks the server zone or TCP/443 flow. That selective success is evidence against a broad Layer 1/2 outage.
Define the flow as source IP/subnet → destination IP → protocol → destination port → direction/state. Then inspect the policy device that actually sees that flow. Avoid vague statements such as “the firewall is blocking it” unless a rule, log, counter, or controlled test intersects the exact connection.
Ping success does not prove HTTPS—and ping failure does not prove the site path is broken
ICMP echo and TCP/443 are different traffic. A server or firewall can allow one and deny the other. Conversely, an internal site can work perfectly while ICMP echo is intentionally filtered. Use ping only for the question it can answer, then test the actual required service.
Ping succeeds, HTTPS fails
Some IP reachability exists. Investigate TCP/443, listener state, firewall policy, TLS, proxy, or application behavior.
Ping fails, HTTPS succeeds
The application requirement is satisfied despite ICMP filtering. Do not “repair” ping by weakening policy.
For selective transport failures, continue with Port Blocked Troubleshooting.
Distinguish timeout, refusal, and successful TCP establishment
A TCP connection attempt gives more specific evidence than generic reachability. A timeout may reflect silent filtering, path failure, or a missing response. An explicit refusal commonly indicates that the destination was reachable enough to reject the connection but no acceptable listener handled that port. A successful TCP establishment moves the unresolved boundary upward toward TLS, HTTP, proxy behavior, or the application.
| Exact-flow result | What it supports | What remains unresolved |
|---|---|---|
| TCP/443 timeout | No successful service handshake observed | Path, silent policy, return path, listener/network state |
| TCP/443 refused | Destination/path responded to attempt | Listener/service configuration |
| TCP/443 establishes | Transport connection succeeded | TLS, HTTP, authentication, app/backend |
| HTTP response code received | Web stack answered | Meaning depends on status/application |
A request can reach the server network while the response takes a broken or policy-incompatible path
One-way evidence is not end-to-end proof. A packet capture at the server that shows SYN arrival but no SYN-ACK leaving points in a different direction from a capture that shows the SYN-ACK leaving but never reaching the client. Multi-homed servers, asymmetric routing, VPNs, NAT, and stateful firewalls can make the response path especially important.
Asymmetry is not automatically an error. It becomes relevant when the design or stateful device requires traffic to traverse a compatible path in both directions.
Internal names may be direct while public sites use a proxy—or the reverse
Enterprise proxy policies often contain exceptions for private domains, RFC1918 destinations, or specific applications. A stale PAC file, incorrect bypass rule, manually configured proxy, or endpoint that cannot reach the designated proxy can make one internal site fail while ordinary browsing works.
Compare a working managed client using the same network and user context. Determine whether the failed URL is supposed to go direct or through a proxy, and test that intended path. Disabling the proxy indiscriminately may create a security/policy violation and does not explain the mechanism.
A certificate warning is evidence that the diagnosis has already moved above basic reachability
If the browser receives a certificate and reports hostname mismatch, expiration, or untrusted issuer, the client reached enough of the HTTPS service to begin TLS negotiation. That makes “no route to server” a poor primary diagnosis for that attempt. Check the exact hostname, certificate names, validity period, internal CA trust chain, client clock, and whether a proxy or load balancer is presenting the certificate.
An HTTP error page means “unreachable” is no longer the most precise symptom
A 404, 401/403, 500-class response, redirect loop, or application-generated error each proves that some web component responded. The investigation should move to the layer indicated by that response: URL/path mapping, authentication/authorization, reverse-proxy routing, backend health, or application state.
Preserve the exact status code and response source. A reverse proxy can return an error even when the backend application is down, so “I received HTTP” does not necessarily prove the final server is healthy.
The IP you reach may be a front end, not the application server
Internal applications commonly sit behind a virtual IP, reverse proxy, or load balancer. DNS may correctly point to that front end while the front end has no healthy backend pool member, an incorrect host rule, a failed health check, or a certificate/listener problem. This creates an important boundary: client-to-front-end success does not prove front-end-to-backend success.
Separate server reachability from whether the web process is actually listening
If the host is reachable but the required port is refused, inspect whether the service process is running and bound to the intended address/port. A process can be healthy yet bound only to loopback, a different interface, or a different port. A host firewall can also reject or drop traffic before the listener receives it.
Server-side evidence should match the exact destination address and port used by clients. “The web service process exists” is weaker than “the service is listening on the intended interface and receives the reproduced connection.”
Move from user symptom to artifacts that intersect the exact failed transaction
| Artifact | Question answered | Overclaim to avoid |
|---|---|---|
| Public site works | Does broad Internet browsing work? | “Therefore internal routing works.” |
| Internal DNS answer | What address did this resolver return? | “Therefore the server is reachable.” |
| Route table | Which path should the client choose? | “Therefore packets are forwarded successfully.” |
| TCP test | Did the exact service transport establish/respond? | “Therefore the application is healthy.” |
| TLS certificate/error | How far did HTTPS negotiation progress? | “Therefore backend application is healthy.” |
| HTTP/app response | Which web/application component answered? | “Therefore every backend dependency is healthy.” |
Swipe horizontally to see the full table.
One laptop uses public DNS for a private-only hostname
Public browsing works. A peer on the same VLAN resolves the internal FQDN to 10.40.8.25 and opens the site. The affected laptop returns NXDOMAIN and is configured with a public resolver rather than the organization's internal resolver. Correcting the managed DNS configuration restores the intended answer and the site opens by name.
The diagnosis is not “the Internet was broken” or “the server was down.” The control peer and resolver difference localize the first failed dependency to private name resolution.
DNS and ping succeed, but a segmentation rule denies TCP/443
The client resolves the correct private address and can ping it. TCP/443 times out. A firewall log generated during the reproduced attempt shows the exact source, destination, protocol, and port matching a deny rule. The approved rule is corrected narrowly; TCP/443 then establishes and the application opens. A prohibited control flow remains denied.
This is stronger than using ping as proof of “server up.” The decisive artifact intersects the required HTTPS flow, and negative verification confirms that the correction did not broadly weaken segmentation.
The site is reachable, but the certificate proves the hostname path is wrong
A user enters an internal alias and receives a certificate-name mismatch. DNS resolves, TCP/443 establishes, and a certificate is delivered. The certificate contains the application's canonical hostname but not the alias. That evidence places the failure above routing and transport. The correction belongs in hostname/certificate/application design—not in the route table.
A VPN installs the wrong more-specific route to the server prefix
At the office, the internal site works. From home, the VPN connects and private DNS returns the correct 10.40.8.25 address, but the route table sends 10.40.8.0/24 toward an unintended local/alternate path instead of the corporate tunnel. Other Internet traffic remains healthy through the default route.
The exact-prefix route explains why public browsing is a misleading control for this failure. After the route policy is corrected, verify the private prefix through the intended tunnel and repeat the original URL.
The reverse proxy answers HTTPS but has no healthy backend
Clients resolve the expected virtual IP, establish TCP/443, receive the correct certificate, and then receive a gateway error from the reverse proxy. Multiple source networks show the same result. Proxy health data shows the application backend failing its health check after a deployment.
Client routing, DNS, and TLS are known-good checkpoints. The failure boundary is now between the front end and backend/application state. Restarting client networking would discard strong evidence.
Change one fact and the best diagnosis should change
Fact change: IP works by browser
If the intended site opens by numeric IP but not hostname, name resolution/hostname handling rises sharply in priority.
Fact change: TCP/443 succeeds
Stop treating a generic port block as the leading explanation; move to TLS/HTTP/application evidence.
Fact change: every internal site fails
A shared client/VLAN/VPN/DNS/routing dependency becomes more plausible than one server process.
Fact change: only one URL path returns 404
The site is reachable; investigate web routing/content rather than network reachability.
Use this sequence without restarting after every clue
- Record the exact URL, source client/network, failure message, and time.
- Compare a working peer or another internal destination to establish scope.
- Resolve the exact FQDN and preserve the returned address/resolver.
- Inspect the route chosen for that exact private address.
- Test the actual required transport service, not only ICMP.
- Use policy/log evidence if the path crosses segmentation or host firewalls.
- If TCP succeeds, interpret TLS evidence before changing routing.
- If HTTPS responds, preserve status/error details and identify the responding component.
- Check proxy/reverse-proxy/backend state when architecture requires it.
- Make the smallest evidence-supported correction and repeat the original transaction.
Verify the repaired transaction and a control that protects the intended network policy
| Repair area | Positive verification | Control/negative verification |
|---|---|---|
| DNS | Exact FQDN returns intended internal answer and URL opens | Other internal names still resolve as intended |
| Route/VPN | Target prefix follows intended path and site works | Unrelated/default traffic follows intended policy |
| Firewall | Approved exact web flow succeeds | Prohibited comparison flow remains blocked |
| TLS | Expected hostname validates under intended trust model | No insecure bypass is required |
| Proxy/backend | Original URL reaches healthy application | Other proxy routes/backends remain healthy |
Write the answer as checkpoint → boundary → mechanism → next evidence → verification
Checkpoint: “The client resolves the correct internal address and TCP/443 to that address establishes.” Boundary: “Basic name resolution and transport establishment have succeeded for this attempt.” Mechanism: “The browser then reports an untrusted internal issuer, so the unresolved dependency is TLS trust rather than basic routing.” Next evidence: “Compare the certificate chain and trusted enterprise CA state with a working managed peer.” Verification: “Open the original hostname without bypassing certificate validation and confirm the expected application.”
24 internal-site troubleshooting flashcards
Practice private DNS, route selection, segmentation, exact-flow testing, TLS, proxies, server listeners, reverse proxies, evidence boundaries, and verification.