Clash Setup for All Platforms

General Setup and Configuration Basics

Understand the Client, Core and Profile

In the Clash ecosystem, the graphical client displays configuration, manages startup and sets the system proxy. The core listens on ports, evaluates rules and establishes connections. A profile supplies server settings, proxy groups and other configuration. These are separate components: installing a client does not provide a usable profile, and importing a link does not mean the core has loaded it successfully. When troubleshooting, check each layer separately: can the app start, can it parse the configuration, does traffic reach the core, and is the selected egress working?

Before choosing an installer, check your system information and note the operating system, processor architecture and current user permissions. Where supported, this site recommends Clash Plus; see the client installers for options. Clients differ in their support for core settings, system services and import methods, so matching file extensions do not guarantee full compatibility. Archived clients that are no longer maintained are best reserved for reproducing older setups, not as the default choice for a new device.

Keep Track of Profile Sources and Protect Credentials

Subscription URLs often contain account-identifying parameters, so treat them like credentials. When copying a URL, make sure it contains no line breaks, extra text from a messaging app or trailing punctuation. Never include the full URL in screenshots, support tickets or public logs. If the link opens in a browser, that only confirms the request worked in the browser's environment; the client may use a different network path, request headers or certificate setup. If the format is unsupported, ask the provider which format works with Clash or your chosen core.

Before importing a profile for the first time, save a copy of your existing configuration and note which profile is currently selected. A remote profile update may overwrite downloaded content, so put persistent custom rules in an override, merge or extension configuration explicitly supported by your client. Merge order varies between products; check the final active configuration after saving. When moving settings to another device, copy only what you need and recheck paths, network interface names and local listening addresses on the new device.

Start with the Simplest Working Setup

Start in rule mode, select a working proxy group, then enable just one traffic-routing method. On desktop, test the system proxy first; mobile systems usually have the client create a system VPN tunnel. TUN captures traffic from more apps, but adds variables such as virtual interfaces, routes and DNS. Enabling multiple clients, global mode and TUN at once makes logs harder to interpret and can leave duplicate routes behind.

This sample illustrates local listening settings only. It contains no server details and cannot establish a proxy connection by itself. The port is not fixed; it just needs to be available and match the value used by the client. If these fields already exist in your configuration, edit the existing entries rather than adding duplicate keys.

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

The mixed port accepts both HTTP and SOCKS requests. Allow LAN controls whether other devices can connect, while the local bind address further restricts where the client listens. Allowing only local connections avoids exposing the port to your network before authentication is configured. Make sure the system clock is synchronized too: a clock mismatch can cause encrypted handshakes or certificate checks to fail. Once setup is complete, change one setting at a time, test immediately and check the new logs. This makes problems much easier to isolate than changing several things at once.

Install Clash on Windows and Route Traffic

Choose an Installer and Complete First Launch

Check your processor architecture in Windows Settings under System Information, then choose the matching client from the Windows installers. Clash Plus is the recommended option; depending on your needs, you can also choose Clash Verge Rev, FlClash or Clash Nyanpasu. Clash for Windows is no longer maintained and is available only as an archived option. Renaming an installer for a different architecture does not make it compatible, and moving the main executable without its full extracted folder can prevent it from working.

Before running an installer, review the file source and publisher information shown by Windows. A security warning cannot be judged by the filename alone. If anything looks unusual, stop and verify where the download came from instead of disabling system protection. After installation, launch the client as a standard user and check that the tray icon, settings and logs open. Elevate permissions only when the client requires them to install a service, enable a virtual interface or change protected settings. Avoid running the client as an administrator all the time.

Import a Profile and Confirm It's Active

Open profile management, choose the option to import from a URL, paste the full subscription link and save it. Once downloaded, select that profile, check for parsing errors, then open the proxy or group page and choose an egress. Some clients separate downloading a profile from activating it; seeing a file in the list does not mean the core is using it. If your provider gave you a local file, use the file import option instead of pasting its path into the URL field.

If import fails, identify whether the error is a connection failure, an unexpected response format or an unsupported field. If a web page returns a login screen, the client may have received HTML instead of a configuration. If a field is unrecognized, check whether the profile targets your current core. Keep the original file rather than deleting unfamiliar fields just to clear an error. After a successful load, note the profile name and selected proxy group, then test an update and confirm it does not switch to a different profile.

System Proxy, UWP Loopback and TUN

After enabling the system proxy in the client, check that Windows proxy settings point to the actual local address and port the client is listening on. A browser proxy extension can override system settings, so use a consistent route while testing. Command-line tools may not follow the system proxy. Try an explicit proxy request to distinguish an app that is not being routed from an egress failure. Replace the port below with the value shown in your settings; you can also substitute the website you're troubleshooting as the test URL.

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com

If a browser works but some Store apps do not, the issue may be a UWP app restriction on accessing local loopback addresses. Check loopback access only for apps that need it, preferably using the client's own management option. Avoid enabling it for every app. You can also consider whether TUN suits your setup, but it does not replace checking that the profile is valid and the expected rule is matched. Follow your organization's device policies on managed work devices.

Enabling TUN for the first time may require installing a service or creating a virtual network adapter. First confirm that the system proxy works, then enable TUN and check the logs for interface creation, route setup or permission errors. Grant firewall access only for the network scope you actually need; local use does not require inbound access from public networks. Another VPN, security software with network filtering, or an old virtual adapter can alter routes. When troubleshooting, disable duplicate traffic-capture tools before repeatedly reinstalling the client.

Startup Behavior and Restoring Network Settings

“Start at login” usually launches the app interface after the user signs in. “Service mode” may run the core independently of the interface; they are not the same thing. Set up a working profile first, then enable startup and restart to confirm the right profile is selected automatically. If the internet is briefly unavailable after startup, check when the network becomes ready, service permissions and whether the profile needs an online download. Do not add the same startup task in both Task Scheduler and the client settings.

For more installation scenarios, see Common Windows Firewall, UWP Loopback and TUN Issues. When reporting a problem, note the network type, permissions and traffic-routing method in use. That is usually more useful than simply saying “it won't connect.”

Clash on macOS: Installation and Network Permissions

Check Your Chip and App Source

Use About This Mac in the Apple menu to check your chip, then choose the matching Apple Silicon or Intel file from the macOS installers. Clash Plus is the recommended option; you can also use Clash Verge Rev or FlClash. ClashX Meta is no longer maintained and is available only as an archived client. Even if compatibility software lets your Mac run an app built for another architecture, using the installer made for your device can help avoid startup and permission issues.

Open the disk image and move the app into your Applications folder, then launch it from there rather than running it from the mounted installer. Assess first-launch security warnings using the download source and the information shown by macOS. If macOS says the file is damaged or from an unexpected source, get the correct installer again and check system compatibility. Do not run online commands from untrusted sources to bypass security restrictions. If the app needs a helper service, make sure the prompt is part of the action you just started.

Import a Profile and Identify the Active Network Service

Paste the subscription link into the profile page, wait for it to download, select the profile and check the parsing results in the logs. If you import through a browser handoff, confirm which app receives the link; with multiple clients installed, the protocol association may point to an older app. If the handoff does not work, paste the link into the client manually. Do not send a credential-bearing URL to a third-party conversion site. After importing, select rule mode and a working proxy group, then run a basic test in a browser.

On macOS, the system proxy is tied to the active network service. Wi-Fi, Ethernet adapters and other services may each have separate settings. If access fails after switching networks, check that the active service still uses the client's local listening port. Automatic proxy configuration and manual web proxies can use different routes, so confirm which one is enabled. The command below only reads the current state; it does not change system settings. The service may not be named Wi-Fi, so list the actual names on your Mac first.

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"

Check that the enabled status, server address and port in the output match the client. If the client has quit but the system still points to a local port, requests will be sent to a listener that no longer exists. To restore access, turn off the relevant proxy options in Network settings and check whether automatic proxy configuration is also enabled. Do not run several commands to change network services without first checking the current state; you could fix Wi-Fi and leave Ethernet misconfigured.

TUN, Helper Services and DNS

TUN implementation varies by client and core. Some use a privileged helper service to adjust routes; others require authorization for a system network extension. Follow the instructions for your client, and check the logs to confirm that the interface and routes were actually created—even if the menu switch appears to be on. After a system upgrade or moving the app, an old service may need repair or renewed authorization. Use the client's service management options instead of manually deleting system files whose purpose is unclear.

If only company intranet domains stop working after enabling TUN, the cause may be split DNS or your company's VPN routes rather than an unavailable proxy server. Note the affected domains, active network service and matched rules, then check whether the client is overriding the existing DNS path. Networks that rely on internal DNS need to preserve the correct resolver for those domains; sending every DNS request to a single public resolver is not a general fix. Test both intranet and public sites afterward.

The system proxy mainly affects apps that follow system settings. Terminal tools may need an explicit proxy or environment variables, which apply only to processes that inherit them—not the whole system. If the terminal works but the browser does not, check browser extensions, cache and the active network service. If both fail, inspect the client logs and selected proxy group. Do not treat a proxy icon as proof that requests are working; test an actual connection.

Login Startup, Sleep and Network Changes

To start the client at login, use its startup option and check that it has not been disabled in Login Items. A helper service can run independently of the menu bar interface, so closing the window may not stop the core. After waking from sleep, switching hotspots or reconnecting Ethernet, interface names and the default route may change. Disable and re-enable the current traffic-routing method and check whether routes are recreated before replacing the profile.

When moving to another Mac, you can export the profile, but reauthorize services, check local file paths and select a proxy group again. Do not transfer private certificates, corporate network settings or Keychain contents in an ordinary profile file. Once the setup is stable, restore automatic updates, startup and other extensions one at a time. Keep a log from a successful connection so you can compare it with a failure.

Clash on Android: Installation and Background Connections

Choose the Right Build and Grant Permissions

For Android, Clash Plus is the recommended choice from the Android installers. Other options include Clash Meta for Android, FlClash and Surfboard. Apps vary in the configuration formats and protocols they support, so an import failure in one app does not necessarily mean your phone is the problem. Check which format your provider supports, then choose a compatible client. Match the installer architecture to your device; check system information for older or unusual devices rather than guessing from the phone brand.

When opening an installer from a browser or file manager, Android may ask you to allow installs from that source. Grant permission only to the source you need and revoke it afterward if appropriate for your device. If you see a signature conflict with an existing app, you may not be able to install over it. Export any needed configuration, check the source and package name of both apps, then decide whether to uninstall. Uninstalling may remove profiles, logs and permissions, so it should not be your first troubleshooting step.

Import a Profile and Set Up the System Tunnel

Open the client's profile or subscription manager, add the remote link, save and update it, then select it as the active profile. Use a local label that helps you identify it; do not put the full credentials in the name. To import a local file, grant access through the system file picker. A file in Downloads is not automatically readable by the client. After importing, check that proxy groups appear and that there are no unsupported-field errors.

When you tap Start, Android usually shows a system VPN connection request. This permission lets the client capture traffic from your device; it does not provide a remote proxy server. Confirm the request comes from the app you just opened before allowing it. Most standard setups allow only one active system VPN at a time. Other VPNs, firewalls and filtering apps that use the same mechanism may replace one another, so stop the current service deliberately when switching.

A mobile system tunnel is different from the desktop “system proxy” setting. You usually do not need to enter the same local proxy in your Wi-Fi advanced settings. A manual HTTP proxy in Wi-Fi settings may apply only to some apps and that network; combining it with the tunnel can send traffic to the wrong port. Start with one routing method, confirm that the browser and target app generate connection logs, then consider per-app routing or LAN access.

Per-App Routing and Background Restrictions

If the client offers per-app routing, check whether it is set to “proxy only selected apps” or “bypass selected apps.” Selecting the same app has the opposite effect in each mode. The app list controls whether traffic enters the tunnel; domain and address rules decide which egress it uses once inside. Test these layers separately. If the logs show no requests from the target app, check the app list before adding more domain rules.

Disconnections when the screen locks are often related to battery management. Check that the client shows a foreground service notification, then see whether the app is restricted from running in the background in your device's battery settings. Manufacturer labels for startup, background activity and power saving vary; adjust only the settings relevant to this app rather than disabling battery saving across the device. Test while the screen is on, locked and after a longer idle period instead of judging by the initial connection alone.

“Always-on VPN” and “Block connections without VPN” are system-level policies. The latter may block all other network access if the client has not started or its configuration is unavailable. Enable it only after understanding how it works and testing after a reboot. Do not confuse the client's auto-reconnect option with system-level blocking; they apply at different stages. When removing an enforced policy, verify that the system setting has been restored, not just the switch in the app.

DNS, Private DNS and Hotspot Limits

Android Private DNS, the client's DNS settings and an app's own encrypted DNS can all be active at once. If domain access fails, note the original settings and test them one at a time rather than changing everything at once. Some apps reuse cached results or long-lived connections, so a new request may be needed after changing DNS. An IP address being reachable does not mean you should permanently disable every DNS feature.

A phone's VPN usually does not automatically route traffic from other devices connected to its hotspot. To use the phone's proxy from a computer, the client must explicitly support LAN listening, and you must configure a reachable address, authentication and firewall rules. That is separate from enabling a hotspot. For ordinary mobile use, keep LAN access disabled. If a profile update fails on mobile data but works on Wi-Fi, check data permissions, network restrictions and provider reachability before assuming the profile is damaged.

Set Up Clash on iOS

Install Clash Plus from the App Store

Clash Plus is available for iPhone and iPad. Find it via the iOS client page or open Clash Plus on the App Store directly. The product website is clashplus.io. Check the compatibility details on the App Store page and follow what your device shows. Do not try to install packages made for other platforms, and do not install a device management profile from an unknown source just to use a subscription.

When you first open the app, take a moment to find the profile page, proxy mode and connection switch. Notifications and network tunnel permissions serve different purposes: notifications show status or reminders, while establishing a tunnel requires system approval for a VPN configuration. If your device is managed by a school or organization, network access may be restricted by policy; check what is allowed first. Installing the app does not provide a working profile—you still need to import one and select the right egress.

Import a Link and Check the Profile Source

Copy the full subscription URL from your provider. In the client, choose the option to add a profile by URL, enter a local name and save. If asked for clipboard access, allow it when you are pasting. Browser-based import links use app associations; if nothing opens, add the profile manually in the client. There is no need to open the same link repeatedly, which can create duplicate profiles that are hard to tell apart. Do not save subscription URLs containing account parameters in public notes or shared screenshots.

After the update finishes, select the profile and check its proxy groups. If the list is empty, confirm the download succeeded, the response contains a configuration and the client supports its format. Server details and rules may be in one file or organized in another structure supported by the client; file size alone does not tell you whether the profile is complete. Save a copy before editing by hand so you do not damage the original indentation or group names while fixing a format issue.

Allow the VPN Configuration and Check Rules

When you connect for the first time, iOS will ask to add a VPN configuration and may require your device passcode or another confirmation. After granting permission, return to the app and check its connection status, then make a new request in a browser. The VPN icon in the status bar means the system tunnel is up; it does not guarantee the remote server is working or that every request uses the same egress. In rule mode, some domains may still connect directly, so check the matched rule and proxy group when testing.

iOS clients typically use a system network extension to capture traffic. This is different from the HTTP proxy setting on a desktop. The manual proxy option in Wi-Fi details is a separate route and generally does not need to be configured to start the client. If other VPN configurations are installed, check which one is active. Switching repeatedly between apps can change the system's selection; while troubleshooting, keep just one client running to reduce interference from overlapping configurations.

Use the connection log for the current request to verify which rule matched. An app may reuse an existing connection, so returning to an already-open page after changing a rule may not trigger a new match. Close the page and revisit it, or restart the app if needed. Do not repeatedly reset network settings across the whole device just to test one domain. If a rule refers to a proxy group that does not exist, fix the name or profile compatibility rather than switching everything permanently to global mode to hide the error.

Background Behavior and On-Demand Connections

The system tunnel and the app interface have different lifecycles. Switching to another app does not necessarily stop the connection, and force-closing the interface alone does not prove the tunnel is off. To disconnect, use the client's connection switch and confirm the VPN status in system settings. If on-demand connections are supported, read the trigger conditions and test on both Wi-Fi and cellular. Check for automatic startup, reconnection after network changes and exceptions for specific networks.

If an app briefly fails to load after you unlock your device, make a new request and check the logs to distinguish a stale connection from a persistent tunnel failure. Low battery, network changes and session limits on the target service can all affect behavior, so one reconnection attempt is not enough to identify the cause. Server reachability may also vary by network; test on the current connection instead of relying on results from another one.

Move to Another Device and Update Profiles

On a new device, recheck system VPN permissions, the active profile and proxy group selection. Do not assume a device backup restores every connection permission. Before exporting a file, check whether it contains subscription credentials or server passwords, and transfer it only through a trusted channel. Profiles from desktop cores may contain listening ports, interface names and local paths; mobile clients handle these fields differently. Use a compatible profile rather than copying every setting verbatim.

Regular profile updates can pick up changes from your provider, but do not keep retrying updates during a network outage. First check whether the current profile still works, then see whether the update request succeeded, the remote content changed and the same profile remains selected. For general update troubleshooting, see subscription update issues. Keep a local backup that loads successfully so you can distinguish a failed download from a broken new profile.

Linux Desktop and Core Setup

Choose a GUI Client or a Standalone Core

For Linux desktops, choose Clash Verge Rev or FlClash from the Linux installers. First check your distribution, processor architecture and package format, then use an installation method supported by your distribution. The packages on the download page may not cover every distribution and architecture; renaming a package for another system will not make it work. Review dependency information from your package manager and investigate conflicts instead of forcing the installation past checks.

A graphical client is useful for importing profiles and switching proxy groups. A standalone Mihomo core may suit users who maintain their own server, router or service; see core downloads. A core has no graphical interface: after extracting it, you still need execute permissions, a configuration directory and a startup method. Desktop users do not need to build a background service just to use a proxy. Verify the network path in a GUI client first to reduce deployment variables.

Profiles and Proxy Settings in a GUI Client

After installation, import a remote profile from the configuration page. Once downloaded, select it and check the logs. A working GUI does not mean its core process has started; verify the actual listening address and port. Desktop environments differ in system proxy support: some apps read desktop settings, others use environment variables, and some use their own network settings. So a browser working while a terminal fails does not necessarily mean the proxy server is the problem.

For a terminal test, specify a proxy temporarily rather than editing your login scripts. The environment variables below affect only the current shell and processes it starts; they do not apply automatically to desktop apps that are already running. Clear the variables when you finish so the terminal does not keep sending requests to a local port after the client exits. Use the address and port the client is actually listening on, and do not put credentials in scripts that others can read.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl --head https://example.com
unset http_proxy https_proxy

Here, the HTTPS destination is reached through an HTTP proxy tunnel, so using HTTP for the proxy address is correct. Also check for uppercase variables, global environment files or settings in the tool itself; any of these can affect the result. Containers, remote sessions and sandboxed apps have separate network or environment boundaries. A localhost address inside a container usually refers to the container, not the host, so do not assume the service is unavailable just because you reused a desktop port.

Standalone Core: Directories and Run User

For a manual setup, place the extracted executable in a controlled location, make it executable and create separate directories for configuration and runtime data. Start it in the foreground first to confirm that parsing and listening succeed, then consider running it as a service. The example below assumes the executable is named mihomo and the configuration is saved in a file under your user directory. The command does not create a valid subscription or supply missing remote server details.

mkdir -p "$HOME/.config/mihomo"
chmod u+x ./mihomo
./mihomo -t -d "$HOME/.config/mihomo"
./mihomo -d "$HOME/.config/mihomo"

A successful test confirms only that the configuration parses; it does not guarantee that the remote service is reachable. When setting up a service, specify the run user, working directory, startup command and configuration path so the service does not accidentally read a different default profile. Make sure the log and update data directories have appropriate write permissions. Do not make every file writable by every user just to avoid permission issues; the configuration may contain account details and controller credentials.

TUN, Routes and DNS Permissions

TUN generally requires access to a virtual network device and permission to change routes. A GUI client may handle this through a helper service, while a standalone core requires you to configure the necessary permissions. Do not blindly grant network administration capabilities to an arbitrary file. First confirm the binary's location, update method and security boundaries. Recheck after updates, since replacing the binary can change file-level permissions.

After enabling TUN, use route and DNS inspection tools to check what changed, including current routes, listening ports and the system resolver. Distributions may use different DNS managers; avoid letting multiple components repeatedly overwrite the same resolver file. If you manage a remote server, keep a second admin session open and have a clear recovery plan. A wrong default route can cut off your current connection, and a GUI switch alone may not restore it.

Startup and Cleanup Checks

A desktop startup entry runs after the user session begins; a system service may start before login. Choose based on whether you need persistent background operation, and do not launch two copies of the core on the same port. After restarting, check the actual process, configuration directory and listening port—not just whether the service name looks healthy. When stopping, restore proxy and route settings before ending the process. If a port is in use, identify the owning service before changing anything so you do not stop an unrelated network process.

Common Configuration Issues and Troubleshooting

Identify the Fault Layer from the Symptoms

Before troubleshooting, note your operating system, client, active profile, proxy mode and traffic-routing method. Record the last change made before the issue began. Pause other proxies and VPNs, then send one new test request. If the client receives no connection, check the system proxy, app list or TUN routes. If it receives the request but cannot connect out, check the proxy group and server. If the connection succeeds but the page is still broken, investigate DNS, rules and the app itself.

“Connected” may only mean that the local core is running or the system tunnel is established; it does not confirm that the full connection works. Test local traffic capture and remote reachability separately to avoid changing settings at the wrong layer. For a full checklist, see Connected but No Internet: Troubleshooting Checklist. If the logs point to a remote timeout, see How to Troubleshoot Proxy Timeouts and Connection Failures.

Rule Order, Group Names and Profile Updates

Rules are usually evaluated in order, and the first matching rule determines what happens next. A broad rule near the top can override more specific ones; fallback rules generally belong at the end. The snippet below is for illustrating syntax only and assumes your configuration has a proxy group named PROXY. If your group has a different name, use that name instead. Do not create an empty group just to match the example, or append the snippet as a second top-level rules key.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

GeoIP rules depend on the relevant data being available, and DNS results can affect IP-based matches. Global mode can help with a quick comparison, but it does not prove that your rules are correct. For an affected site, check the rule matched by that connection and its final egress—not just the proxy group's current selection. A remote update may rename groups, leaving overrides that reference old names and causing the profile to fail to load. Compare errors before and after updates; if needed, restore a known-good backup and migrate changes one at a time.

How DNS and TUN Interact

DNS translates domain names into addresses that can be reached. A successful proxy connection does not guarantee that DNS is using the right path. With fake-IP mode enabled, some domains may receive mapped addresses; these are not the remote server's real addresses. Copying them to another device or bypassing the client may make the site unreachable. If an app needs special handling, configure the appropriate domain exceptions according to the core documentation and confirm that rules can still identify the original domain.

If intranet domains, printers or local devices become unreachable, first check whether their traffic is being sent into the tunnel incorrectly and whether DNS still uses the original network. Replacing every resolver with a public DNS server is not a universal fix. When testing with TUN disabled, check whether the system proxy or other DNS settings are still active; otherwise, the original network path has not actually been restored. IPv6 has its own addresses, DNS and routes. If only some sites fail, check for differences between IPv4 and IPv6 before permanently disabling IPv6.

Profile Updates and Latency Tests

If an update fails, first check the response type. A connection timeout means the request did not complete; an authentication failure calls for checking credentials and account status; a format error means the response could not be parsed in the expected format. Whether update requests use a proxy depends on the client and its settings—do not assume they always connect directly or always use a proxy. If the old profile still works, keep it rather than repeatedly deleting and recreating it. See the Help Center's subscription update guide for more detail.

A latency test reflects the result of a specific request at that moment. It is not a measure of sustained download speed and does not guarantee that every website will work. Results vary with the test endpoint, handshake stage and concurrent connections, so keep conditions consistent when comparing. After choosing an egress, test it in the app you actually need. For more, see Latency Tests vs. Real-World Speed. Do not rely on one test score instead of connection logs and real-world use.

Save Evidence, Then Restore a Stable Setup

Before sharing logs, remove subscription URLs, account parameters, server passwords and unnecessary personal network details. Keep only the error type, time and relevant context. Use debug-level logging only long enough to reproduce the problem, then return to the normal level to avoid generating excessive data. Record the result of each change and revert it if nothing improves; continue until you find a specific difference that explains the issue. Once stable, re-enable automatic updates and startup. To follow the full setup again, return to the Getting Started guide; do not leave temporary troubleshooting settings as your permanent defaults.