Identify Where Grok Stops Working
When Grok will not load with Clash, “the proxy is connected” is not yet a useful diagnosis. A desktop client can show an active profile while the browser uses a different system proxy, a TUN interface captures only some traffic, or a rule sends the Grok request DIRECT. The reverse can happen too: the browser reaches the service, but a selected node cannot keep a stable connection. Start by describing the failure precisely. Does the page never open, does the sign-in screen load but authentication fail, do conversations remain stuck on a spinner, or does a response begin and then stop? These symptoms point to different parts of the path.
Record the client, operating system, active profile, proxy mode, selected policy group, and approximate time of the failure. Note whether other HTTPS sites work through the same browser and whether Grok works when Clash is stopped. Do not include account tokens, subscription URLs, cookies, or private conversation content in screenshots or support posts. A short, redacted log excerpt showing the requested hostname, matched rule, selected group, and connection result is much more useful than a screenshot that merely says “connected.”
Also check whether the problem is limited to one browser or appears in every app. If only one browser fails, inspect its proxy settings, extensions, secure DNS option, and cached site data before changing the Clash profile. If multiple unrelated applications fail, investigate the client’s system proxy or TUN capture and the selected node. If Grok and other xAI pages fail together while unrelated destinations remain normal, routing or service availability becomes more likely. This small symptom map helps prevent a common detour: editing DNS rules when the actual issue is that the browser never sends traffic to Clash.
Verify Clash Proxy Mode Before Editing Rules
Confirm that the client is using the profile you intended to test. In Clash Verge, Clash Verge Rev, or another Mihomo-based client, profile names can look similar, and a recently edited profile may not be the one currently active. Open the running configuration or profile view and verify that the active configuration contains the expected proxy groups and rules. If the client reports a configuration parse error, resolve that first; a stale or failed reload can leave you testing yesterday’s routing policy while reading today’s YAML.
Next, distinguish the client’s traffic-capture mechanism from its routing policy. System proxy mode typically directs applications that respect the operating system’s HTTP or SOCKS proxy settings. It does not guarantee that every application follows those settings. TUN mode captures traffic at the network interface level, subject to permissions, route setup, exclusions, and DNS behavior. Some clients offer both, while others present the controls differently. For a browser test, use one capture method at a time where practical and verify that the Clash connection log actually shows the browser’s request.
Temporarily switch the relevant policy group to Global mode as a controlled diagnostic, not as a permanent fix. In many Clash interfaces, Global mode sends matching traffic through the selected proxy group rather than relying on normal rule selection. Choose a known-working node, reload Grok, and check whether the relevant connections appear in the log. If the page works in Global mode but fails in Rule mode, the evidence points toward rule matching or group selection. If it fails in both modes, continue testing the node, DNS, and service availability instead of adding broad rules immediately.
Return to your normal mode once the comparison is complete. Global mode can route more traffic through a proxy than intended, affect latency, and obscure which specific rule needs attention. It is a temporary A/B test: keep the browser, node, and test page constant, change only the routing mode, and record the result. If the result changes, you have isolated the policy layer without assuming that every Grok-related hostname needs the same treatment.
Inspect Rule Matches and Clash Logs
In Rule mode, locate the request generated when you reload the failing page. Clash logs and connection panels commonly show a hostname or destination, the matched rule, and the policy group or proxy selected. Interface labels differ between clients and core versions, but the question is consistent: what decision did Clash make for this connection? If the request is DIRECT, compare that decision with the behavior you expect under your own network policy. If it selects a group, confirm that the group has a usable member rather than an empty list, a failed fallback, or an unintended DIRECT option.
Grok is a web application, not necessarily a single hostname or one uninterrupted request. A page may load its main document, scripts, authentication resources, images, and API or streaming connections separately. The exact set of hostnames can change over time, and a hostname that works for one stage does not prove the others use the same route. Observe the actual requests your client records instead of copying an unverified domain list from an old post. Avoid routing an entire top-level domain through a proxy merely because one subdomain appeared in one failed log.
Rule ordering matters. Specific domain or domain-suffix rules need to be evaluated before broad catch-all rules if they are meant to take precedence. A broad MATCH rule placed earlier can capture a request before a later, narrower rule is considered. Remote rule providers can also change their contents or refresh successfully at a different time than you expect. Check the active rule list, update timestamp, and matched rule shown for the failing connection. For a deeper explanation of rule order and policy behavior, see Clash rule routing best practices.
Make one change at a time. If the log shows an unexpected DIRECT match, add or adjust a narrow rule only when that route is appropriate for your environment, then reload the configuration and repeat the same test. If the expected rule matches but the request still times out, changing the rule again is unlikely to help; inspect the selected node and resolver path. Keep a brief change record with the old and new match result. That makes it possible to undo an experiment instead of accumulating duplicate entries that make later troubleshooting harder.
- Unexpected DIRECT: check the matched rule, rule order, and whether the intended profile was reloaded.
- Unexpected group: check the group’s members, selection, health state, and any fallback behavior.
- No visible request: verify browser proxy settings, TUN capture, process exclusions, and whether the request was generated.
- Repeated retries: compare timestamps and destination details to see whether one endpoint or several are failing.
Test the Node and Connection Stability
A successful latency check is not proof that a node can carry Grok’s complete session. Many clients probe a simple URL or perform a brief handshake; the actual page can require multiple TLS connections, sustained response delivery, or a longer-lived streaming request. A node may pass the quick test and still fail under load, have an unreliable route to a particular destination, or close idle connections too aggressively. Conversely, a slow probe endpoint can make a healthy node look poor even when the Grok path is usable. Treat health checks as clues, not guarantees.
Keep the routing mode and profile fixed, then test a second node from the same provider. If the first node fails and the second works, the evidence favors a node-specific route, congestion, or policy issue. If several nodes from one provider fail while another provider succeeds, the provider’s current connectivity may be relevant. If every node behaves the same, revisit the client’s capture mode, DNS, local firewall, and service status. Avoid changing the node, DNS mode, and rule set simultaneously; doing so may make the page load but will not reveal which change mattered.
Use a fresh browser tab or reload after switching nodes, then allow enough time to distinguish a slow response from a failed one. If the connection log shows repeated resets, handshake failures, or timeouts for the same destination, save only the relevant redacted details and note whether the same node can load other sites. Do not assume that a generic browser error identifies the failing hop. A reset may originate from the local network, the selected proxy path, an intermediate gateway, or the destination service.
If the client offers a connection test against a destination you control or an approved diagnostic endpoint, use it to compare general node reachability. Do not treat a random speed-test result as a direct measure of Grok availability. The practical comparison is whether the same browser, profile, policy, and test sequence work with another node. If the alternate node fixes the issue, report the evidence to the provider rather than rewriting unrelated rules. If no node works but direct access does, preserve that distinction for the next checks.
Check DNS, Browser Settings, and Local Capture
DNS can create a misleading split between a hostname that resolves and a connection that reaches the intended route. Clash configurations may use different resolver modes, fake-IP behavior, or DNS routing rules, while a browser can also enable its own secure DNS resolver. These layers do not always share the same cache or query path. If logs show a hostname being resolved differently than expected, or the failure began after a DNS setting changed, compare the active Clash DNS configuration with the browser’s secure DNS setting. Change one resolver path at a time and restart or clear the relevant cache only when you understand which cache you are testing.
When a browser uses DNS-over-HTTPS independently, its DNS requests may not follow the resolver behavior you expected from Clash. This does not automatically mean secure DNS is wrong; it means the browser and proxy client may be making separate decisions. For a controlled test, use the browser’s documented setting to temporarily align its DNS behavior with your normal policy, then repeat the same request and restore the original setting if the test does not help. Do not paste account or session data into third-party DNS diagnostic sites.
Check for local routing conflicts as well. A second VPN, another Clash-compatible client, a corporate endpoint agent, or an old system proxy entry can compete for traffic. On desktop systems, verify that the operating system’s proxy settings point to the currently running client when using System Proxy mode. With TUN, check that the interface is active and that the client has the permissions it requires. On managed devices, a security policy may deliberately prevent proxy changes or tunnel capture; ask the administrator rather than attempting to bypass that control.
Browser extensions can also alter requests, rewrite headers, block scripts, or interfere with streaming connections. Try a clean private window only if the browser’s privacy settings allow the relevant session to work there, and do not disable organizational security extensions without authorization. If one browser profile fails while another works with the same Clash settings, compare extensions, secure DNS, proxy configuration, and cached site data before changing the core configuration. A clean browser test is useful because it changes fewer network variables than reinstalling the client.
Separate Local Configuration Problems from Service Outages
Before making additional YAML changes, compare the failure across time and paths. Check the service’s official status information or announcements, and note the time and scope of any reported incident. A service-side outage can resemble a proxy timeout, especially when the page shell loads but an API request fails. If your local logs show the request leaving through the expected policy group and multiple unrelated destinations work, a temporary destination-side problem becomes more plausible. A status page is not conclusive on its own, but it is useful evidence alongside repeatable local tests.
Compare a small set of controlled conditions: your normal Rule mode with the usual node, Global mode with that same node, and—if permitted—another known-good node with the original profile. Keep the browser and requested page constant. If only Rule mode fails, revisit the match and ordering. If both modes fail on one node but work on another, investigate the first node or provider. If all local paths fail while the service reports an incident, wait and retest before changing a working configuration. If direct access works but all proxied tests fail, focus on the client and proxy path rather than account credentials alone.
Authentication failures deserve their own careful distinction. If the sign-in page appears but login loops or returns an error, the browser may have stale site data, a blocked identity resource, or a time-related certificate problem. Confirm the device clock, check whether the browser reports certificate warnings, and review the specific failed request in the log. Do not repeatedly submit credentials into an unexpected page, and do not share one-time codes with anyone offering to “fix” the proxy. If the service itself rejects an account or session, consult its official account support rather than trying to solve an account-side issue with routing changes.
Once Grok works, return to the intended proxy mode, keep the smallest justified rule change, and remove temporary diagnostic settings. Save the working profile or export a backup before further edits. If the issue recurs, compare the new log with the earlier one: a changed matched rule suggests a profile or provider update, while a changed node result suggests a route or availability change. This evidence-based approach is more reliable than repeatedly reinstalling Clash, replacing a subscription, or adding broad domain rules that may affect unrelated services.
Some lightweight proxy clients expose only a single system-proxy switch, which can make it difficult to see whether Grok matched a rule, which group handled it, or whether DNS and TUN capture disagreed. A maintained Clash-based client with visible profiles, policy groups, and connection logs makes those checks easier to repeat and reverse. If you want a clearer workflow for testing rule matches and node behavior, compare the options on the Clash V.CORE download page and choose the build that fits your platform and permitted network setup.