Identify whether Gemini, Google sign-in, or the session stops

First checks for common Gemini loading failures
SymptomCheck firstKeep a record of
Gemini and Google sign-in pages both failGoogle service status, DNS, and basic connectivityExact URL, time, and browser error
Google sign-in succeeds; Gemini stays blank or loadingSite data, script blocking, and resource requestsWhether another browser or device reproduces it
A private window works; the normal browser does notCookies, cache, content blocking, or extensionsThe difference between the two environments
Only the current network failsIPv4, IPv6, DNS, proxy, and managed-network policyBoth families, ASN, region, and check time
The same Google account fails on several networksPage guidance, account type, Workspace policy, or official supportFull message and reproduction steps

Review Google status before restoring a comparable session

  1. Review Google's official status

    When the same issue occurs across devices and networks, check the Google Workspace Status Dashboard first. A normal dashboard cannot rule out every local issue, but it avoids unrelated local changes during a known incident.

  2. Identify the page and sign-in method

    Separate the public page, Google Account sign-in, authorization redirect, and authenticated Gemini page. Keep the exact page text instead of only noting that it would not load.

  3. Reproduce in a private window or clean profile

    Use a private window or new browser profile as the first comparison. Then review Gemini and Google sign-in site data, cookies, and extensions one setting at a time rather than clearing everything at once.

  4. Compare one known-stable network

    If another network works, inspect the original network's DNS, proxy, IPv4/IPv6, and managed policy. Change one network variable per test so the result can be attributed.

  5. Follow the reproduction scope

    A browser-only issue belongs in browser troubleshooting; a network-only issue warrants exit and routing checks; a persistent account or Workspace message should follow the page guidance and official support.

Use a network result only when a clean session changes with the network

Only when the same Gemini entry point, Google Account, and clean browser session recover on another stable network should the Gemini check be used to record IPv4, IPv6, region, ASN, network type, and public-resource connectivity differences. It does not read a Google Account, Google One or AI plan, or Workspace administrator setting.

Gemini does not currently have a product-level endpoint on this site that reliably returns a real public exit IP, so there is no Gemini routing-exit card. Do not substitute another service's exit for Gemini's request path; compare this site's network observation with the browser flow and account-page message instead.

Use IPv4, IPv6, and WebRTC as path evidence

  • Record IPv4 and IPv6 region, ASN, network type, and connectivity separately
  • Confirm whether proxy rules cover both address families or leave IPv6 direct
  • Use WebRTC to add browser-observable public candidates, not as Gemini's only exit evidence
  • Repeat the same browser flow on one other network and preserve the failure time

Record a reproducible Gemini page failure

  • Date, time zone, exact URL, and full page message
  • Whether a private window, another device, and another network reproduce it
  • Google Account type: personal or managed work/school account
  • Current IPv4, IPv6, ASN, region, and proxy or managed-network context
  • Steps already tried and their outcome; redact sensitive details from screenshots

Sources and evidence limits

Sources below support the stated technical or policy boundary. Diagnostic comparisons in this guide remain observations, not account verdicts.