A homepage can load while sign-in fails because the journey depends on different hosts: an identity service, an API, application scripts or a third-party redirect. Rechecking only the homepage misses that distinction. Find the request that prevents the next step, then combine browser evidence, domain checks and application logs.
This guide is for services you operate or are authorized to investigate. WeaveBit adds mainland China network observations; it does not sign in, execute JavaScript or validate an end-to-end user journey. If the whole site is inaccessible, start with the general access troubleshooting guide.
1. Describe the step that actually fails
Distinguish an unavailable sign-in page, an unresponsive button, a failed authentication request, a redirect without a session, and a successful login followed by missing data. Record time and timezone, region, carrier, broadband or mobile connection, browser version, and any proxy or corporate gateway.
Reproduce once using a controlled environment and test account. Do not repeatedly submit orders, make payments or trigger messages while investigating. Note whether the browser was already signed in: authenticated and anonymous visits can make different requests.
2. Find the request that did not complete
Open DevTools Network before the action and clear earlier entries. Enable Preserve log for redirects, perform one authorized action, and inspect Fetch/XHR plus relevant JS requests. Use Status and Initiator to identify the failed request and its source. The official Chrome Network reference explains these controls.
Look beyond red rows. A pending request or missing sign-in script can prevent progress. If no authentication request appears, check browser Console errors and script loading. Identify the earliest failure affecting the journey instead of treating every downstream error as a separate incident.
3. Separate the source, destination and application path
Within your controlled environment, confirm the destination scheme, hostname, port and path, including the final host after redirects. A page at www.example.com may authenticate elsewhere. A browser origin includes scheme, host and port; the Origin request header normally identifies the request's source, not its destination.
The path distinguishes session creation, refresh and account-data requests, but domain checks do not reproduce those operations. For shared records, remove query strings, identifiers and tokens, leaving a nonsensitive path template such as /session. Do not paste a full request URL or its headers into a ticket.
4. Route evidence to the right investigation
| Browser observation | What to review next |
|---|---|
| Failed request without a usable HTTP response | Destination, connection error, user network and contemporaneous domain observations. |
| 401, 403 or 5xx | Authentication, access policy and application/CDN logs; a response is not successful login. |
| CORS message or failed preflight | Console details, related responses and cross-origin configuration; do not disable browser security. |
| API responds but the journey stops | Business errors, script handling, session state and subsequent dependencies. |
CORS governs cross-origin script requests; a CORS message alone does not distinguish a network problem from response configuration. See MDN's CORS guide and HTTP status reference, then interpret the evidence alongside your own logs.
5. Prioritize actual, authorized dependencies
For each observed host, record purpose, owner, business importance and testing permission. Authentication APIs and required scripts can block sign-in; a failed analytics request or decorative image may not. Determine whether identity, CAPTCHA or payment providers are essential from the actual journey, not their names.
Only add hosts you own or are authorized to check. Domain lists contain plain hostnames without schemes, paths, ports or duplicates. Record third-party browser observations and the responsible provider first; do not automatically scan every third-party host a page contacts. Confirm authorization before expanding checks.
6. Complement the browser with domain observations
For an initial observation on one authorized domain, use the free DNS Pollution check. No reported poisoning does not establish API availability, and an abnormal result does not explain an account's authentication failure. For multiple domains or HTTP/HTTPS-related questions, go directly to GFW Full rather than checking each domain twice.
Full combines DNS Pollution, HTTP Host and TLS SNI dimensions and a summary; it is neither every method nor a browser test. Choose relevant GFW nodes and keep observation times and dimension results. DNS Pollution checks do not require user-selected nodes. Consult the Full guide for inputs and ports, and preserve normal, abnormal and indeterminate outcomes according to the result reference.
7. A mock example: investigate the login API first
This is fictional, not a customer case. www.example.com loads, authentication uses api.example.com, and scripts come from assets.example.com. Scripts load, but authentication has no usable response. The authorized team prioritizes the API hostname and checks application logs for the same time.
Abnormal GFW observations add network evidence; normal observations leave the actual request, user network and server policy to investigate. Indeterminate results remain awaiting confirmation. None establishes a bad password, a recovered login journey or a proven cause.
8. Hand over a minimal, privacy-reviewed record
Manually share only the step, timezone-aware time, region/carrier, authorized host and port, redacted path template, error category/status, initiating component, relevant check time/result and owner. Remove cookies, authorization headers, keys, passwords, verification codes, query tokens, account details and order information.
Do not share raw HAR files, replay commands or full headers. Chrome's sanitized HAR documentation lists some excluded sensitive headers, but URLs and bodies can still expose confidential or personal data. Use reviewed text and cropped, redacted screenshots instead.
Once dependencies are understood, use the Console entry point and monitoring guide for recurring checks. Keep application monitoring and final sign-in verification alongside network observations.