Clash Troubleshooting Guide

No Internet Access: Separate Network Issues from Proxy Issues

Disable the proxy and test your regular connection first

If no websites load, turn off the client's system proxy and TUN, then quit the client normally. Make sure no system proxy settings are left behind, then try a website that usually works without a proxy. If it still fails, troubleshoot your Wi-Fi, gateway, captive portal, or broadband connection first—the proxy client cannot fix an underlying network problem. Public Wi-Fi often requires you to sign in, and the proxy may intercept the login page. Disable the proxy, complete the sign-in, then test again.

If your connection works again after disabling the proxy, the issue is likely with the proxy entry point, core, or config. Restart the client, but don't enable every feature at once. Check the logs for messages confirming that the config loaded and listening ports were opened. A visible window only means the GUI is running; it doesn't confirm that the core started. A port conflict, invalid config syntax, or insufficient permissions can leave the interface open while the proxy service is unavailable.

Test with an explicit proxy request to bypass system settings

Check the actual mixed port in settings. The example below uses the local address and port 7890; replace the port if your client uses a different one. This command specifies an HTTP proxy to temporarily rule out system proxy settings, browser extensions, and other variables. On Windows, use curl.exe to avoid PowerShell environments that interpret curl as a different command. Other desktop systems typically use curl.

# Windows PowerShell
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com

# macOS / Linux
curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com

If the connection to the local port fails, the request hasn't reached a remote node. Check that the core is running and that the listening address and port match. If a proxy tunnel is established but the remote connection then times out, investigate the node and rules. An HTTP response means this request got through, but one website doesn't represent the entire network. Also test the target that actually fails and check the client's connection log to see which policy handled it.

Check rules, proxy groups, and recovery steps

Open the Proxies page and check the selected policy group. Make sure it isn't set to REJECT and doesn't reference a node that no longer exists. After a config update, a selection retained in the interface may no longer be valid. Temporarily select a known-working policy for comparison. If Global mode works but Rule mode doesn't, focus on the matched rule and final outbound route instead of repeatedly downloading a different installer. Restore the original mode after testing so you don't mistake a temporary setting for a permanent fix.

If the connection only drops when TUN is enabled, turn TUN off and test with the system proxy alone. If the system proxy works, investigate virtual network adapter permissions, route conflicts, and other VPNs rather than assuming the subscription is invalid. Corporate security software, virtual machine networking, and other tunneling tools can all affect routing. Don't delete every network adapter. Close conflicting apps, save your work, restart the system, then re-enable the network tools you need one at a time.

Suggested recovery order: turn off TUN → turn off the system proxy → quit the client normally → check for leftover system proxy settings → test a direct connection. Resetting the entire network stack should be a last resort. Before doing so, note any static IP, DNS, and corporate network requirements.

For a final check, test two types of destinations: one site that normally works without a proxy and one that requires the current proxy policy. Record the time, mode, target, and result to avoid mistaking a website outage for a client-wide issue. If you're still unsure, review Frequently Asked Questions to understand the roles of the system proxy and TUN, then continue to the next section to identify the specific timeout stage.

Node Timeouts: Identify the DNS, Connection, or Handshake Stage

First, pinpoint when the timeout occurs

A node speed test timing out doesn't necessarily mean the node is permanently unavailable. A test may involve resolving the server's hostname, connecting to the server, completing a protocol handshake, and accessing a test URL. Any of these steps can produce a similar result when it fails. Open the logs and run one test manually, then find the corresponding entry. Don't change nodes, networks, and DNS settings all at once; even if the test succeeds, you won't know which change helped.

A dial tcp message followed by i/o timeout usually means a TCP connection attempt didn't finish within the allowed time, but check whether the address is the node server or the final destination. If it's the node server, investigate the network path from your device to that server. If it's the destination, the request may already have reached the node. connection refused usually means the remote side actively rejected the connection, unlike a timeout caused by silently dropped packets. These errors call for different troubleshooting steps.

Check the subscription and server endpoint

First confirm that the subscription updates successfully and the service is still active. Then check that the selected node's server hostname and port match the provider's current settings. Don't add protocol fields based on guesswork. TLS server names, WebSocket paths, and transport types usually need to match one another; changing one at random may allow a TCP connection but break the handshake. If the node came from a subscription, fetch the original config again if possible. Save a copy and note why before making manual edits.

You can use system tools to check whether a port is reachable, but only test servers you're authorized to access. On Windows, Test-NetConnection can check TCP port reachability; it doesn't verify proxy authentication, encryption settings, or access to a destination website. Some protocols primarily use UDP, so a TCP test alone can't tell you whether they're working. Likewise, a server that doesn't respond to ping may still accept proxy connections. Don't treat ICMP results as a definitive test.

Use cross-tests to isolate the network and node

Keep the client, config, and node unchanged. Switch your computer from its usual Wi-Fi to a phone hotspot, then access the same destination. If it works on the hotspot but not on the original network, investigate that network's outbound policies, UDP restrictions, or sign-in status. If both networks fail, try another node from the same subscription with a different server endpoint. Nodes that share a server hostname aren't independent tests; if they all fail, the shared endpoint may be the problem.

If the speed test fails but websites load normally, check whether the test URL is reachable, bypassed by a direct rule, or restricted. A health check tests one specific URL, not every internet service. Don't keep increasing the timeout to hide a persistent problem. A longer wait may help confirm that a network is simply slow, but it won't fix a wrong port, invalid credentials, or an unresolvable server hostname.

For a TLS certificate error, first sync your system date, time, and time zone, then check the server name in the config. Don't routinely skip certificate verification; doing so weakens server identity checks. For more on reading logs, see How to Find Issues in Clash Runtime Logs. When contacting your provider, include the time, network type, and a redacted error. Don't share your full subscription URL or authentication fields.

Subscription Failures: Check the Download, Format, and Config Loading

Separate download failures from parsing errors

Subscription import failures usually fall into two categories: the client couldn't retrieve the content, or it retrieved the content but couldn't parse it as a config. First identify whether the error occurred during download or loading. HTTP status codes, connection timeouts, and certificate errors point to download issues. Line numbers, indentation, unknown fields, and missing proxy group references point to parsing issues. If the interface only says the update failed, check the logs for details instead of deleting everything and importing it again.

Copy the complete subscription URL from your provider. Messaging apps may add trailing spaces, line breaks, or punctuation. Some URLs contain access credentials, so treat the entire URL as sensitive. Don't post it on public forums, paste it into online search boxes, or include it in screenshots. If you've exposed it, revoke or reset it with your provider. Don't submit a private subscription to an unfamiliar conversion site; the service may be able to access node details and credentials.

Choose the next step based on the response

For 401 or 403, check your account status, link validity, and the provider's access requirements. For 404, check whether the URL has moved or was copied incompletely. For 429, stop retrying and wait as directed by the service. Status codes point you in a direction, but you still need to consider the response body. Even a successful status may return a login page, verification page, or error message instead of a config.

If a browser can download the subscription but the client can't, check whether their network routes are the same. The browser may use a separate extension, a signed-in session, or the system proxy, while the client sends subscription updates directly—or the reverse may be true. Enable the client's subscription download proxy only when you know the update request needs one. If every node is unavailable, routing subscription updates through those nodes creates a loop. Try downloading directly over a trusted, working network instead.

Check the YAML structure and core compatibility

After downloading the file, check whether it's a Clash YAML config or a collection of node share links. They're not interchangeable. YAML uses spaces for indentation; don't use tabs. Quote strings containing special characters correctly. If the interface points to an error on a particular line, check the lines above it too. The missing colon, quote, or list marker may be earlier in the file.

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

This is only an example of top-level fields; it contains no nodes or proxy groups and can't create a remote proxy connection on its own. When merging it, check whether the file already has the same top-level keys to avoid duplicate rules or dns sections. Policy names referenced by rules must match the proxy group names, including spaces and capitalization. If you're unfamiliar with YAML sections, review A Walkthrough of the Clash Config File Structure and check them one at a time.

If the error points to an unsupported protocol or field, check which core is running rather than relying on the client window's name. The GUI and core have separate capabilities, and an older core may not support fields added by your provider. If you need a different client, visit the client downloads page. Clash Plus is a good first choice; select the right installer for your operating system. Don't drop a new core binary into an old client's folder unless that client explicitly supports this update method.

Automatic updates can also overwrite manual edits. Subscription files are usually regenerated from remote content. To make persistent customizations, use the client's supported override or merge mechanism rather than repeatedly editing the download cache. After a fix, run a manual update and restart the core to confirm that the config downloads and loads successfully. Keep a recent working config, but avoid frequent background retries against an invalid subscription. Rate limiting can then be mistaken for a new network problem.

Slow Connections: Separate Latency, Bandwidth, and App Behavior

First, identify what feels slow

Long waits before a page opens, slow downloads, video buffering, and laggy gameplay are different problems. Describe a repeatable symptom: Is only the first visit slow? Are all sites slow? Does it happen only in the evening? Does switching Wi-Fi fix it? A node speed test measures one specific request; it doesn't predict sustained download speeds or explain every app's performance with a single latency figure.

Keep the node and destination unchanged and check the underlying network first. A laptop far from the router, a congested Wi-Fi channel, cloud sync, or a system update can all use bandwidth. From the same device, access a working destination directly and then through the proxy, recording several results. Don't compare speeds from different sites, files, or times. The destination server's location, rate limits, and caching policies can all affect the result.

Check the actual route in connection logs

Confirm that app traffic is using the intended policy. A webpage's main document, images, video segments, and sign-in requests may come from different domains and match different rules. A fast-loading homepage doesn't mean video streams follow the same route. Filter connection logs by app or domain and check the final policy group and outbound node. If specific resources are routed incorrectly, fix the rules instead of putting every connection in Global mode because one resource is slow.

Automatic selection groups can also be misleading. Their health-check URL, interval, and availability criteria determine the selection, which may not reflect your current workload. Temporarily pin a known-working node for comparison to avoid automatic switching during the test. After switching nodes, an app's existing long-lived connections may still use the old route. Close the relevant page or reconnect the app, then check new connections rather than just the selected button.

Understand protocol, UDP, and routing differences

Some browsers and video apps try QUIC, which uses UDP. If your network or node doesn't support the required UDP forwarding, you may see fallback delays, slow-loading resources, or repeated connection attempts. Check the logs to identify the protocol, then confirm that the node and client support it. Don't block all UDP globally just to test one website. You can temporarily disable the protocol in a controlled app for comparison, then restore the original setting.

If slowdowns occur only with TUN, look for routing loops, path MTU issues, or network adapter conflicts. Clues include small pages loading while large downloads stall, or one network working while another doesn't. Close other VPNs and compare the system proxy route with TUN. Before changing the MTU, check the client and core documentation and save the original value. Copying a fixed value from the web may make another route worse rather than provide a reliable fix.

Server distance, peering between networks, and peak-time congestion can also affect performance. If the same node performs poorly for the same destination across multiple devices and networks, while other nodes work, you have stronger grounds to report a routing issue to your provider. Include the test time, destination, connection method, and repeatable symptoms—not just that the speed is terrible. Don't invent throughput figures or treat a brief peak as sustained bandwidth.

When you're done, undo temporary changes such as Global mode, app protocol settings, and manually pinned policies. Keep only the changes needed to explain the issue, then monitor whether your normal use has improved. Changing all DNS servers, adjusting network adapters, switching cores, and reinstalling the client at once may seem fast, but it makes the problem impossible to reproduce and harder to diagnose after your network changes.

DNS Issues: Trace the Path Your DNS Queries Actually Take

If a domain won't load, don't replace every resolver right away

DNS issues can appear as unresolvable domains, slow first visits to some sites, or a node server whose hostname can't be found. First determine whether the failed name belongs to the destination or the node server; they may use different resolution paths. System DNS, browser Secure DNS, the client's built-in DNS, and an app's own resolver may all be active. If changing the system setting has no effect, the setting may be fine—the app may simply not use that path.

On Windows, use nslookup example.com. On macOS or Linux, use dig example.com if available to inspect the system query result. These commands show only the path used for that query; they don't prove how a browser or TUN handles DNS. Note the resolver, result, and error, then compare them with the client logs. Different DNS paths returning different addresses isn't always a problem. CDNs may return different results based on location.

Understand the difference between Fake-IP and real addresses

In Fake-IP mode, the core assigns a reserved address to a domain and stores a mapping. When a connection is made, it uses that mapping to recover the domain and apply routing rules. Seeing a reserved address doesn't mean the website's server is actually on that subnet. The key is whether the app making the connection still passes through the core that maintains the mapping. If the client exits while the system or app has cached a synthetic address, connections may temporarily fail. Restore the normal DNS path and clear the relevant cache.

Device discovery on a LAN, printing services, and some apps that require real IP addresses may not work well with synthetic addresses for every domain. Identify the affected domain and behavior first, then add it to fake-ip-filter using syntax supported by your core rather than excluding every domain. Check the current core's documentation for filter syntax and policy support. For background and limitations, see Fake-IP vs. redir-host.

Check the config, upstream servers, and startup dependencies

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

This example shows a local DNS listener and upstream server settings, but whether the upstream is reachable depends on your network. Listening on 1053 doesn't automatically route all system DNS queries through it. System settings, TUN DNS interception, or another forwarding mechanism must be configured separately. Don't expose a DNS listener to the public internet without access controls, and don't set a loopback address on this device as the DNS server for another device.

Encrypted DNS also has startup dependencies: resolving the upstream hostname may require DNS, while connecting to the upstream may depend on a proxy that isn't available yet. If that creates a loop, configure bootstrap resolution and node hostname resolution separately using fields supported by your core, and verify upstream reachability first. Don't add a long list of resolvers at random; more upstreams add variables, and incorrect routing will still fail. For internal corporate domains, retain the resolver path required by your organization.

Check IPv6 separately as well. When a domain returns both IPv4 and IPv6 addresses, a device may try a path that isn't actually available. Compare connection results for both address families, then check routing, node support, and client settings. Turning off IPv6 isn't a universal fix for DNS issues. If you disable it temporarily for testing, note the original setting and make sure other network services aren't affected.

Clear caches only after correcting the DNS path. Stop the app from retrying, then flush the cache using the method supported by your system, reopen the app, and trigger a new query. Repeatedly clearing the cache won't fix an unreachable upstream server or incorrect DNS interception.

For the final check, test an ordinary domain, the domain that originally failed, and any required internal domains. A successful lookup isn't enough; confirm that the connection matches the right policy and completes its request. If the issue occurs only in a browser, compare its Secure DNS and extension settings temporarily. If it occurs only with TUN, revisit DNS interception and routing rather than changing subscription nodes unrelated to the problem.

System Proxy Not Working: Check the Entry Point, App, and Routing Boundaries

Enabling the system proxy doesn't route every app's traffic

The system proxy provides an entry point for apps that honor system settings. Some command-line tools, games, background services, and apps with their own network settings won't use it. So a browser working while a terminal app fails doesn't necessarily mean the client is broken. First test the local entry point with the explicit proxy command from the first section. If that works, check whether the target app supports the system proxy, needs its own proxy setting, or actually requires TUN to route its traffic.

On Windows, check the manual proxy address and port in Network settings. On macOS, check proxy settings for the active network service. Linux desktop settings vary by desktop environment and app. Wi-Fi and Ethernet may have separate settings, so check the active connection rather than an old settings page. If your environment uses an automatic proxy script, distinguish its URL from the manual HTTP proxy to avoid conflicting settings.

Check the local listener and environment variables

On the same device, use 127.0.0.1 to reach the client port; it serves a different purpose from a LAN address. Consider allow-lan and the listening address only when other devices need access. Enabling LAN access won't fix a wrong port in the local system proxy, and it may expose the service more broadly. Get the local connection working first, then configure sharing separately for a trusted network.

# Affects only the current macOS / Linux shell and its child processes
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

# Restore the current shell after testing
unset HTTP_PROXY HTTPS_PROXY NO_PROXY

These variables are read only by programs that support them; they don't force all traffic through a proxy. Some programs read only lowercase variables, while others use their own config files. Check the target program's documentation instead of stacking multiple settings. Here, the value of HTTPS_PROXY can still use http://: the connection goes to a local HTTP proxy, which then establishes a tunnel. This doesn't downgrade the destination website to plain HTTP.

Rule out conflicting proxy settings

Browser extensions, old clients, corporate proxy scripts, and startup items may rewrite system proxy settings. If the setting switches back just after you enable it, quit other proxy tools and check background processes and startup apps. Temporarily disable browser extensions for comparison, but don't remove network components installed by your employer. On managed devices, follow your organization's policy; don't disable security services to bypass existing restrictions.

If you need TUN, first confirm that the client supports it, the service is installed, and it has the required system permissions. Unlike the system proxy, TUN uses a virtual network interface and routing to handle traffic, but it still depends on rules, DNS, and route exclusions. TUN isn't a switch that automatically fixes everything. If local devices become unreachable after you enable it, check LAN routes and exclusions rather than forcing your entire private network through a remote proxy.

Virtual machines, containers, and subsystems have their own network boundaries. Inside a container, 127.0.0.1 refers to the container itself, not the host. A virtual machine may not inherit the host's system proxy settings either. Use the host access address supported by that environment, and configure the listening address and firewall as needed. Access methods vary by network mode, so don't copy one host command into every container unchanged.

To let a phone or TV use your computer's proxy, first make sure both devices are on the same trusted network, LAN access is enabled on the computer, and the firewall allows only the sources you need. On the connected device, enter the computer's LAN address, not its loopback address. For setup details, see Mixed Port and LAN Sharing Setup. Close the sharing entry point when you no longer need it to avoid leaving access open.

The final test is whether the target app's new connection appears in the client logs and which policy it matches. If the request doesn't appear, check the app's proxy entry point. If it appears but uses the wrong outbound route, check the rules. If the route is correct but the request still fails, investigate the node. Following these three boundaries is more useful than repeatedly toggling the system proxy.

Client Crashes: Separate the GUI, Core, and System Components

First, identify which part stopped

A window disappearing, a frozen window, and a tray icon that remains while the proxy stops working are different issues. The core may keep running after the GUI exits, and the GUI may remain visible after the core stops. Check related processes in Task Manager or Activity Monitor, then inspect the last few lines of the client logs. Note whether the issue started during launch, config import, TUN startup, a subscription update, or wake from sleep. These triggers are more useful than a general report that the app crashed.

Save your work, quit the client normally, and check for leftover background processes. Don't repeatedly launch multiple instances while an old process is still running; this can cause port conflicts or config lock issues. If you have to end a process, check for leftover system proxy settings afterward so traffic isn't still pointed at a local port whose service has stopped. Restore direct access first, then gather information and troubleshoot. That avoids adding confusion by repeatedly downloading files while offline.

Check architecture, install location, and dependencies

Choose an installer that matches your operating system and processor architecture. Apple Silicon and Intel builds, different Windows architectures, and Linux package types aren't interchangeable just because their filenames look similar. Select your platform on the client downloads page. Clash Plus is a good first choice for most desktop users; Linux users can choose a suitable client from the list. Don't install an unmaintained app just to match the interface shown in an old tutorial.

If the app fails on first launch, check for missing runtime components, permission issues, or an installation path problem reported by the system. A Windows GUI may depend on the system WebView component, Linux may report a missing shared library, and macOS may show app permission or security warnings. Follow the client documentation and system prompts. Don't download individual shared libraries from unfamiliar sites or disable system security globally just to launch one app.

Isolate config and state with minimal changes

If a crash only occurs after loading a particular config, back up the config and client data directory, then test with a known-working config. Disable recently added overrides, scripts, or external rules and see whether the issue goes away. Large rule sets, excessive connection logging, and high log levels can increase resource use, but rising memory alone doesn't prove a leak. Consider the trigger, duration, and system resource trends together.

When the core exits because of a config error, its logs usually include a syntax or reference issue. A GUI crash may instead require system events or a crash report. Don't try to fix both by deleting all your configs. If the client supports a separate data directory for testing, compare a clean state while keeping the original data. Otherwise, follow its migration instructions to avoid deleting subscriptions, override rules, and local settings by mistake.

Reinstalling may not remove user data or fix an old config. Before you start, identify the difference between the config directory and program directory. Before uninstalling services or deleting data, keep a recoverable copy and note which system components need authorization again.

If the issue only occurs after waking from sleep, check whether the network interface changed, the system proxy still points to the original port, and TUN routes were restored. Try stopping and restarting the core before reinstalling. If changing networks reliably triggers the issue, record the exact steps, such as switching from Ethernet to Wi-Fi or from a hotspot back to a router. A repeatable sequence can help pinpoint service recovery and route rebuilding problems.

When reporting an issue, include the client name, system architecture, core details, reproduction steps, and redacted logs. Remove subscription credentials, node authentication details, and sensitive information from personal file paths. Crash reports may also contain your username and file locations. Enable debug logging only while reproducing the issue, then restore log-level: info to avoid excessive logs disrupting normal use or future troubleshooting.

After a fix, verify that the client can quit normally, start again, and reconnect to the network. Check that the system proxy, config loading, and core service all recover. If a fresh installation still fails at the same step, stop reinstalling and return to the reproducible conditions. Keeping a way to restore direct internet access is more useful than changing clients repeatedly without recording what happened.

Mobile Troubleshooting: VPN Permissions, Background Limits, and Network Changes

First, check how the device routes traffic

Phones typically route traffic through the system VPN interface, unlike desktop clients that may use a local HTTP proxy. The first time you enable it, allow the VPN configuration in the system prompt and confirm that the active connection belongs to the intended client. A VPN icon in the status bar means the system tunnel is established; it doesn't confirm that the subscription node, rules, and DNS all work. Check the client's logs for new requests, matched policies, and errors to identify the failing layer.

Choose a client from the Android downloads or iOS downloads section. Clash Plus is a good first choice. On iOS, get it from its App Store page; the official website is clashplus.io. Clients differ in supported config fields and system capabilities. Don't assume every TUN setting in a desktop YAML config is required on mobile.

Android: Background Restrictions and App Scope

If the connection works with the screen on but fails after the phone has been locked for a while, check the system battery policy, background activity settings, and the manufacturer's process management settings. Adjust restrictions only for the client you're using; don't turn off power saving for the entire device. For a controlled test, keep the same node, lock and wake the screen, then review the log timeline. Check whether the system stopped the app, the tunnel remained active with expired connections, or Wi-Fi went to sleep.

Some Android clients let you choose which apps use the proxy. If a browser works but another app doesn't, check whether the app is excluded, uses a separate process, or is a second instance in a work profile. System settings such as always-on VPN and blocking connections outside the VPN may make a disconnected tunnel look like the entire device is offline. Understand what these settings do before changing them, so you don't mistake a protection feature for a node failure.

iOS: Permissions, On-Demand Connections, and Config Compatibility

If a VPN won't start on iOS, check whether a system VPN configuration exists, whether it belongs to the current client, and whether another app is already using the tunnel. Existing configurations may come from an older installation or device management. Don't delete an unfamiliar corporate profile. On a personal device, if you need to authorize the client again, stop the connection in the app, follow the system's process, then trigger authorization again and check the prompts.

If iOS shows the VPN as connected but some services still fail, check whether the config imported completely, a policy group needs to be selected manually, and the client supports the protocols in the subscription. Mobile compatibility depends on the app's documentation; importing a config doesn't guarantee that every field has the same meaning. For a first-time import, follow the iPhone Config Import Guide rather than changing many rules before authorization is complete.

Test Wi-Fi and cellular separately

Keep the same node and config, then test the same destination on Wi-Fi and cellular. If it fails only on one Wi-Fi network, complete any captive portal sign-in and check whether the network isolates devices or restricts certain traffic. If it fails only on cellular, consider carrier routing, IPv6, and data restrictions. After changing networks, old connections may no longer work. Send a new request and, if needed, stop and restart the tunnel instead of relying on a page loaded before the switch.

If your phone is using a proxy shared from a computer, troubleshoot it differently. Set the phone's proxy server to the computer's LAN address and the port to its mixed port; make sure the computer doesn't go to sleep. Wi-Fi client isolation can prevent devices from reaching each other, and a cellular connection usually can't access a private address on your home network. In this setup, the phone may not use its own VPN, so don't use the VPN status icon to decide whether proxy sharing is working.

Finally, check the app's cache and existing sessions. After changing outbound routes, long-lived connections for sign-in, video, or messaging may need to be re-established. Close and reopen the target app, then check its new connection logs. One app working again doesn't prove everything is fixed; retest the service that originally failed. If you need help, include the phone's OS, client name, network type, and a redacted error, then continue with the relevant section of this guide.