This guide concerns troubleshooting a web request on a network you are permitted to investigate. It does not cover professional networking or authorize changes to routers, DNS, firewalls or certificates.
Separate the page from its failed data request
This original fictional browser observation contains three records:
Q1: GET https://portal.example/ returned HTTP 200.
Q2: GET https://portal.example/api/reports returned HTTP 502.
Q3: The reports panel displayed "Reports unavailable".
Observation scope: one browser session; no gateway or origin logs supplied.
The browser received an HTTP response for Q2. A claim that the browser could not resolve portal.example does not explain that observed response. A gateway can still have an upstream DNS, connection or application problem; the client records alone do not identify which one.
The HTTP status reference, checked October 24, 2026, describes 502 as an invalid response received by a gateway or proxy from an upstream server. It does not establish the cause of this fictional response or which component in a real deployment generated it.
The first useful question is which request failed and what evidence exists on each side of that boundary. Successful page loading does not prove all API requests work, and one API error does not prove a company-wide outage.
Collect a small, redacted observation packet
In Chrome DevTools, open Network before reproducing the permitted action, then inspect the relevant request. Chrome's Network reference documents status, request details and timing views. Record the action, timestamp with zone, request path, status or exact browser error, and whether the observation came from cache or a live request when that is visible.
Avoid posting a raw HAR or copied request with cookies, authorization headers, private query values or response records. Prepare the minimum redacted evidence allowed by your team. Keep distinct hosts and request paths distinguishable through consistent placeholders.
For a connection error with no HTTP status, retain that fact. Do not fill the status field with a guessed 500. For the 502 fixture, ask the endpoint owner to correlate the permitted timestamp and request identifier with gateway and upstream records. That proposed check has not run merely because ChatGPT describes it.
Ask for an explanation that respects the observation boundary
Help interpret these network observations; do not change anything.
Permitted target/environment: [ENTER]
Action and timestamp/time zone: [ENTER]
Failed request and exact status/error: [PASTE REDACTED RECORD]
Working comparison and relevant request details: [PASTE]
Checks already performed and actual outcomes: [PASTE OR NONE]
Evidence unavailable: [ENTER]
Separate observed facts, possible explanations and missing evidence.
Distinguish browser DNS/connection/TLS failure from a received HTTP
response, and distinguish client-to-gateway from gateway-to-origin.
Propose the smallest discriminating next check and its responsible
owner. Explain what each outcome would and would not establish.
Do not invent logs, broaden the outage scope, suggest bypassing TLS
validation, or change DNS, firewall rules, routing or application data.
OpenAI's prompting guidance supports providing context and action boundaries. The fixture is an authored interpretation exercise, not an actual network capture or model response.
Hand over the request-specific evidence
For Q2, the useful handoff is “the reports request returned 502 at this time; the page request returned 200; please correlate the request at the gateway.” Keep “upstream DNS failure” as one unverified possibility until the owner checks it.
If several explanations remain, the root-cause investigation guide helps organize competing hypotheses. Record the actual next result before revising the diagnosis. A configuration change should follow the authorized operating procedure and evidence for that change.