V2Ray Setup Guide
Complete Client Configuration Handbook

Part 1 · Understand the basics

Core concepts: How a connection flows

V2Ray is often used as an umbrella term for a family of proxy technologies, but it helps to distinguish the GUI client, proxy core, connection profile, and remote server. The GUI client imports subscriptions, saves settings, and starts the core. The core accepts connections, applies routing rules, and handles outbound traffic. Seeing “running” in the interface only confirms that the local process has started; it doesn't prove the remote server is reachable or that your browser is sending requests through the client.

Client, core, and server

Project V is a useful starting point for understanding this ecosystem. V2Fly continues development related to V2Ray, while Xray follows a separate core implementation path. They share some concepts, but feature support and configuration fields don't always match. v2rayN is a desktop GUI client; v2rayNG and v2flyNG are Android GUI clients. Choosing a client doesn't guarantee support for every protocol—the core it runs and that core's capabilities still matter.

Think of a request as passing through four layers: application, inbound, routing, and outbound. The application decides whether to use a proxy. The inbound may be a local HTTP or SOCKS listener, or a virtual network interface. Routing selects an outbound based on conditions such as the domain or IP address. The outbound then uses a connection profile to reach the server. A mismatch at any layer can cause connection problems, so troubleshoot each step in order instead of repeatedly switching servers.

Protocols, transports, and security settings

VMess and VLESS are proxy protocols; TCP, WebSocket, and gRPC describe how a connection is carried; TLS and REALITY relate to connection security. These are different kinds of settings, not interchangeable options. Keep the combination supplied with your profile after importing it. Changing the transport or adding a security option based on its name alone rarely improves a connection; it can instead make the client and server disagree during the handshake.

The server address, connection port, user ID, server name, and transport path each serve a different purpose. A server name may be used in the security handshake and need not match the hostname in the address field. A path usually belongs to a particular transport and should not be entered as the server address. Before checking a setting, identify which layer it belongs to. If a field is unclear, ask the profile provider rather than replacing it with a setting from an online example.

Subscriptions and local settings

A subscription is a way to fetch connection profiles in bulk; it isn't an active connection. After updating a subscription, you usually still need to select a profile and start the service or enable the system proxy. A successful subscription update only means the subscription URL was reachable, not that every server in it can connect. Conversely, an update failure doesn't necessarily mean the proxy core is broken if an existing profile still works—the two requests may take different network paths.

A local listening port is where apps connect to the client; a remote port is the destination port the client uses to reach the server. They don't need to match. For example, if the local port is 10808, don't use that as a reason to change the remote port in your subscription. Also check which protocol the listener accepts. Some versions provide separate ports; others offer a mixed inbound. Use the settings shown in your current client.

Part 2 · Choose your tools

Choose a client: start with the platform, then the core

Choose for your platform first, then consider the interface and core. For desktop, start with v2rayN, which offers a broadly similar workflow across Windows, macOS, and Linux. For Android, start with v2rayNG. Consider v2flyNG only if you specifically need V2Fly core behavior or compatibility with a particular profile. Installing multiple clients doesn't automatically improve compatibility; beginners will find it easier to troubleshoot with one primary client.

Desktop versions and architectures

The Windows v2rayN download page offers a desktop edition and a classic WPF edition. The desktop edition follows a cross-platform UI approach, while the classic WPF edition has a different layout. Choose based on system requirements, your preferred interface, and the features you need—not because the two downloads use different proxy protocols. Both editions read connection profiles and require you to check the core, listening ports, and proxy mode. A familiar interface is no substitute for verifying the configuration.

On macOS, check your chip in system information, then choose the Apple Silicon or Intel download. On Linux, check both the processor architecture and your distribution's package format; common options include deb and rpm. For an arm64 device, choose a package built for that architecture. Package format and processor architecture are separate requirements, and meeting only one may still prevent installation or startup.

Two Android core options

v2rayNG primarily uses the Xray core, while v2flyNG uses the V2Fly core. Their interfaces and some workflows may look similar, but that doesn't mean every import format or protocol extension works in both. If a profile relies on a core-specific feature, check its support first. If imported fields are missing or unrecognized, or the connection fails, check the core and profile format before assuming the server is unavailable.

The arm64 Android package suits most newer mainstream devices. A universal package is another option when you don't know the architecture, but check the app's requirements. Don't infer processor architecture from the phone's purchase year; system information or device specifications are more reliable. Package size doesn't indicate how many features are included: a universal package generally supports more architectures, not faster networking.

Avoid conflicts from running multiple clients

When switching clients, exit the old one before starting the new one. On desktop, two apps may compete over the system proxy, the same listening port, or a virtual network adapter. On Android, VPN permission can also affect the active connection. Closing a window may leave a background process running, so check the system tray, notification shade, or app status. To compare clients, use the same network and connection profile so a route change isn't mistaken for a software difference.

Before downloading, see the side-by-side client comparison. All installers are available on the client downloads page. You don't need to memorize a package name or version number; you should be able to identify your platform, processor architecture, client, and core. Those four details are more useful for troubleshooting than simply saying “it's up to date.”

Part 3 · Set up the local environment

Installation and basic setup: verify the local service first

The goal of installation is not to tweak advanced options right away. First confirm that the app runs, saves settings, and can use an available local port. Check the system requirements for your platform on the download page, then follow the standard installation process for your system. On first launch, keep the default routing and DNS settings and leave TUN off. If the connection fails later, this keeps the initial troubleshooting scope small instead of involving several network interception methods at once.

Before starting the desktop client

On Windows, use the installer to choose a folder and complete setup. If the release comes as an archive, extract it fully before launching; don't run the app from the archive preview. Keep the configuration folder somewhere writable, not in a temporary or automatically cleaned location. If Windows reports a missing runtime component, check the client's system requirements and the exact error before installing anything. Don't download a similarly named file from an unknown source.

On macOS, launch the app from the normal Applications interface after installation. If macOS displays a security warning, verify the download source and read the warning, then follow the system's recommended steps; don't disable security protections system-wide for a single installation. On Linux, use the package manager for your distribution and review dependency messages and the desktop session requirements. An app that installs but shows no window is a different problem from a core that fails to start. First confirm that the main app can open its settings.

Local listeners and basic switches

In basic settings, note the local listening address, port, and inbound type. For a single-device setup, a loopback address is usually sufficient; you don't need to enable “Allow connections from the LAN.” Keep the default port if no other app is using it. If binding fails, exit duplicate instances and other proxy tools before considering a port change. If you change the local port, update apps with manually configured proxies too. Reapply the system proxy if needed.

“Enable UDP” and “Enable traffic sniffing” aren't general-purpose speed boosters. UDP support depends on the app's inbound, routing, server, and the entire connection path. Sniffing can help identify a destination from some connection details, but it won't recognize all traffic. At first, note the existing values and change them only when there's a clear need. If saving a setting prompts you to restart the service, stop the current connection and restart it as instructed.

Android permissions after installation

After installing the Android app, open it and confirm that settings can be saved before importing profiles. The first time you connect in VPN mode, Android asks for permission. This allows the client to create a local network tunnel; it does not purchase remote service. Without permission, profiles may appear in the app, but it can't route app traffic through the VPN. Disconnect any other active VPN first so you don't mistake a connection handled by another app for one handled by this client.

Battery management and background restrictions can stop an Android client after the screen locks, but don't change every system optimization setting as your first step. Complete a foreground connection test first, then adjust background permissions if it disconnects after locking. Keep per-app proxy rules simple at the start. Adding a long app list immediately makes it harder to tell whether the service stopped or the test app was excluded from the tunnel.

Save an initial baseline

Once the basic setup is ready, record the client, operating system, listening port, and current switch settings. Exported or backed-up profiles may contain credentials, so don't post the full file publicly. Close and reopen the app to confirm that settings persist. If they disappear after every restart, first check folder permissions and system cleanup behavior. Reinstalling usually won't fix a configuration folder that keeps getting deleted.

Part 4 · Get connection profiles

Importing a subscription: update, select, then connect

Subscription URLs often contain account-identifying parameters, so treat them like credentials. Don't post screenshots or share the full URL in a forum. Make sure you copied the subscription endpoint, not an account page, help page, or browser address after signing in. Subscription formats aren't universally compatible with every client. If the provider offers different formats for different clients, choose the right one to avoid importing a profile with missing protocol fields.

Create a subscription group on desktop

In v2rayN, open subscription group management, add a group with a recognizable name and subscription URL, save it, and update the subscription. The group name is for local organization; it doesn't change the remote profiles. When the update finishes, check that selectable entries appear in the group, then choose one as the active profile. Saving a group doesn't mean the subscription has been updated, and seeing entries in the list doesn't mean you're connected.

For the first update, use a direct network path if one is available. If the subscription endpoint requires a proxy, first confirm that an existing connection works, then use the client's update-through-proxy option. Relying on a nonworking proxy to fetch the subscription needed to establish that proxy can create a circular dependency. If network restrictions apply, ask the provider whether the subscription endpoint is reachable instead of changing URL parameters at random.

Import and verify on Android

v2rayNG and v2flyNG let you add profiles through their subscription management screens; exact menu names vary by version. After updating, return to the profile list, select the one you want, and start the connection. Importing from the clipboard, scanning a QR code, and updating a subscription are different actions. Clipboard and QR imports may add a single profile without setting up future updates. To keep receiving changes, confirm the profile is saved in a subscription group rather than imported once.

After importing, check that the protocol, address, port, transport, and security settings are present. A profile name alone doesn't prove the settings are correct; providers can name entries whatever they like. For duplicates, check their groups and sources before deleting anything; entries may differ only in transport settings. If you need to edit a profile, make a separate copy so a later subscription update doesn't overwrite your changes and make behavior hard to reproduce.

Diagnose subscription update failures by layer

If an update returns a parse error, check whether the response is actually subscription data supported by the client. An expired endpoint, a required sign-in, or a verification page can result in a URL that opens but can't be parsed. For a timeout, check the network and DNS first. Don't paste a webpage response into a profile field or replace the original profiles with a generic format conversion; conversion may discard extensions required by a particular core.

If an update leaves you with fewer profiles, the local data may be fine—the provider may have changed the subscription contents. Note whether the old profiles still work, then check the group and update time. Don't repeatedly clear and reimport everything; you'll lose useful comparison data. If old profiles work but all the new ones fail, compare their protocols, transports, and security settings, and confirm that the client core supports the changes.

Subscription security and maintenance

A subscription provider can change the connection profiles it delivers, so keep only subscriptions from known sources that you actually need. Before deleting a group, check whether it contains profiles you need to keep. When moving to another device, use the client's supported export or import method rather than copying display names. If a subscription URL has been exposed, replace its credentials through the provider's account portal. Renaming the local group won't invalidate the old URL.

Part 5 · Verify the app's inbound

Proxy modes: system settings and app behavior

A proxy mode answers “how does the app send a connection to the client?” Routing answers “where does the connection go after the client receives it?” Check these layers separately. Enabling the system proxy and choosing to bypass mainland China doesn't mean every app is using the client. Likewise, enabling a virtual network interface doesn't mean every destination will use a remote outbound. Verify the app's inbound first; only then can routing and DNS checks start from a reliable baseline.

What desktop system proxy settings cover

In v2rayN, automatically configuring the system proxy usually changes proxy settings for the current operating system or desktop environment. Apps that honor those settings can use it. Browsers often do, but some download managers, games, and command-line tools use their own network settings. If the interface says the system proxy is enabled but one app still connects directly, check whether that app inherits system proxy settings before switching servers or enabling global routing.

When configuring a proxy manually in an app, use the inbound type, address, and port the client actually listens on. Don't guess whether a port is HTTP or SOCKS from its number. Confirm that your version provides a mixed inbound before using one. For a single device, the loopback address is usually right. Options such as “Bypass local addresses” or “Use custom DNS” can also change the path. Note their current values, then test with an app that has explicit proxy settings.

Verify the inbound with a controlled request

The command below is for systems where curl is installed; first check the port against the client settings. It explicitly uses the local SOCKS inbound and lets the proxy resolve the destination hostname. It doesn't change the system proxy or subscription. The example target is a public test site, and results still depend on your network. If the client doesn't provide SOCKS on that port, use the actual inbound settings instead—don't copy the command and assume the service is broken.

curl --proxy socks5h://127.0.0.1:10808 --head --connect-timeout 10 https://example.com

If an explicit proxy request works but the browser doesn't, check the browser's proxy settings, extensions, cache, or custom network configuration. If both fail, check whether the client log shows the request. No matching log entry points to the local inbound. If the request appears but the outbound fails, continue with the remote server, routing, and DNS. Use one fixed target and note the test time so you don't mix unrelated requests in the logs.

Android VPN and per-app proxying

Android VPN mode uses a system interface to route traffic, so there's no need to enter a loopback proxy in a standard browser. Per-app proxy settings control which apps use or bypass the tunnel; the list may work by including or excluding apps, so read the current screen's instructions. If the test app is excluded, it won't follow the expected route even if the notification shows an active connection. Reconnect after changing the list if the client asks you to.

Don't rely only on whether a page loads to decide if an app is using the VPN; a direct connection could also work. Check the client log and use a controlled request. Android apps may also have background processes, embedded browsers, and separate services, so requests from the same app may behave differently. Start with a simple browser test, confirm the basic path, then investigate specific apps. This avoids confusion from login state and background caches.

Knowing how to stop and restore matters too

Before stopping desktop proxy use, make sure the system proxy has been cleared or restored. If you force-quit the client, the system may keep sending connections to a local port that no longer exists, making every site appear unavailable even though the network is still connected. On Android, confirm that the VPN is disconnected. Before testing a new mode, learn how to turn the current one off. Restart affected apps after switching so they don't reuse old connections and give inconsistent results.

Part 6 · Control where connections go

Routing and DNS: make rules and resolution work together

Routing runs after a connection enters the core. It selects an outbound based on available conditions such as the domain, destination IP, or port. Presets such as “Bypass mainland China” and “Global” are entry points to rule sets, not protocols. Global mode usually sends intercepted traffic through the proxy outbound, but app inbounds and preset exceptions still apply. Check which rule actually matched instead of assuming a connection went remote based on the mode's name.

Rule order and matching conditions

Most routing rules are evaluated in order, so a specific rule should come before a broad rule that could override it. Before adding a direct-connection exception for a domain, check whether an earlier rule already matches it. Domain rules require the core to know the destination hostname. If the app supplies only an IP address and the inbound doesn't preserve the hostname, adding a domain rule may have no effect. Sniffing can help identify the domain in some cases, but it can't replace missing information in every situation.

This partial Xray routing object shows how to write an exact-domain rule; it isn't a complete client configuration. The rule only works if the full configuration has an outbound named direct. A GUI client may generate routing rules and outbound tags automatically, so don't paste this snippet into an arbitrary field. Prefer expressing the same intent through the custom rules interface, then check the generated configuration.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

How V2Ray DNS settings fit together

DNS isn't limited to the server list in the client settings. The system resolver, browser encrypted DNS, app-level resolution, and core DNS can all handle requests. If an app resolves a domain before connecting, the core may never see the original hostname. If the app sends the hostname to the proxy, resolution may happen elsewhere. Before changing DNS, determine whether the current inbound passes a hostname or an IP address. Changing core DNS won't affect a lookup the app has already completed.

DNS requests from the core still need a working network path. If the resolver is reachable only through the proxy, but the proxy server's hostname itself needs that resolver to find its address, startup can get stuck in a dependency loop. For basic troubleshooting, restore the client's default strategy and confirm that the server address resolves, then handle direct and proxied destinations separately. Avoid changing system DNS, browser encrypted DNS, and core policy all at once; otherwise it's hard to tell which layer helped.

Domain strategies aren't universal performance settings

AsIs and IPIfNonMatch affect whether the routing stage tries to resolve a hostname to an IP address for address-rule matching; they don't simply mean “fast” or “slow.” Their behavior may vary between cores and settings locations. With address rules, consider whether the resolved address suits the intended outbound. With domain rules, make sure the hostname is available. A clearly defined rule matters more than choosing the strategy that sounds more aggressive.

IPv6 needs separate consideration too. A network may return both IPv4 and IPv6 addresses, while one path is unreachable. You may see a long delay before a page loads or failures for certain destinations. Compare DNS and connection errors in the logs before changing address selection; don't treat disabling an address family system-wide as a universal fix. Reconnect to the same destination after changes, since existing connections and cached results may not reflect the new settings immediately.

Part 7 · Extend traffic capture

TUN mode: when to enable it and how to restore your network

TUN routes matching traffic through a virtual network interface, making it useful for apps that ignore system proxy settings but need to use the same proxy path. It expands the inbound scope; it won't fix an invalid remote profile or guarantee support for every protocol and network setup. Before enabling it, make sure the same profile works in a basic mode. If the outbound already fails with the system proxy, troubleshoot the profile instead of wrapping the existing problem in TUN.

Check support and permissions first

The TUN implementation, available options, and required permissions in desktop v2rayN depend on your platform, client, and selected core. First check whether the feature is actually available in settings and review any permission prompts. If administrator or system authorization is required, use the normal authorization flow. Don't leave the client running with elevated privileges as your only troubleshooting method. If the option isn't available, don't copy menu locations or configuration fields from another platform.

Before enabling TUN, close other tools that capture network traffic, including another virtual network interface, conflicting network filtering modes, and existing proxy connections. Stacking capture mechanisms can cause default routes to override one another, duplicate DNS handling, or traffic loops back to the inbound. Two switches showing “on” doesn't prove the tools are compatible. First establish a working setup with one tool, then test coexistence one change at a time if needed.

Enable TUN in a controlled sequence

1. Record the original system proxy, routing mode, and DNS settings. Confirm that the client can exit normally.
2. Choose a connection you've already tested, then authorize and enable TUN as prompted for your platform.
3. Check a regular webpage first, then test an app that previously ignored system proxy settings. Review the corresponding logs.
4. Check local network services and any essential work connections to make sure they haven't been routed unexpectedly.
5. Test turning TUN off. Confirm that the virtual interface and system networking are restored before deciding whether to keep using it.

The key is to preserve a baseline. After enabling TUN, don't immediately change routing, DNS, and servers at the same time. First verify that traffic capture has actually changed. If the client documentation says to use TUN with the system proxy, follow those instructions. If the two features are independent, don't stack them just because it worked elsewhere. Implementations vary by platform, so a successful combination on one setup isn't a universal rule.

Local network and DNS exceptions

LAN devices, printers, company intranet domains, and remote work connections may rely on local routes or dedicated resolvers. If only these resources fail after enabling TUN, check bypass rules for local IPs and internal domains instead of routing everything through the proxy. Internal DNS results may vary by network, so hard-coding an address may not be reliable long term. For work networks, follow the access requirements provided by your network administrator.

DNS capture is another common dividing line. If all domain names fail after enabling it but connections by IP still work, focus on the DNS path. If even the local gateway or a previously working direct connection fails, check routing capture and interface status first. Don't repeatedly reinstall the virtual interface without understanding the symptoms. Disable TUN and restore the baseline; if that fixes the issue, the added capture layer is the likely source and the next checks can be more focused.

Android VPN versus desktop TUN

Android VPN mode also uses a virtual network interface to capture traffic, but Android manages its permissions, per-app controls, and system restrictions. Desktop TUN settings don't apply directly. If the connection drops when the screen locks, another VPN takes over, or the app list has no effect, check Android's own settings. The two modes have a similar role as inbounds, but their setup differs; Android doesn't need to offer the same switches as desktop.

Part 8 · Keep a reproducible setup

Maintenance: speed tests, logs, and updates

The goal of maintenance is to keep your configuration understandable, not to chase the smallest number in a server list. A test depends on your local network, remote server, destination, and testing method. Client updates, subscription updates, and rule-resource updates are also different: the client update changes the program and its capabilities, the subscription update changes connection profiles, and the rule update changes matching criteria. Handle one type of change at a time so you know what to roll back if something goes wrong.

What to look for in a V2Ray speed test

A TCP connection test mainly shows whether a connection can be made to a destination port; it doesn't prove that the full protocol handshake or a webpage will work. A test request through the proxy is closer to real-world use, but still reflects only that destination and the conditions at the time. Throughput also depends on the test file, concurrency, server limits, and local bandwidth. Compare profiles using the same method, around the same time, and on the same network. Don't rank results from different test types as if they were equivalent.

For everyday use, first check whether the destinations you care about are reliable, then look at connection time and sustained throughput. If pages are slow but file transfers are normal, DNS, connection setup, or page dependencies may be involved. If just one site is slow, consider its route first. Don't delete every profile because of one timeout, or assume a problem is gone because of one successful request. A small set of repeatable test destinations is more useful than constantly switching test tools.

Read logs along the connection path

Use logs first to check whether a request reached the core, then to investigate the outbound. Find entries that match the test time, destination, and inbound. A local listener error points to a port or permission issue; a resolution error points to DNS; a connection refusal, timeout, or security handshake failure calls for checking different things: address, network, protocol, and security settings. The same error message can have several causes, so read its context instead of applying a canned fix based on one line.

If you temporarily increase log detail, return to the normal level when testing is done to avoid accumulating sensitive browsing records. Before sharing logs, remove subscription URLs, user IDs, tokens, personal domains, and account-identifying information. Screenshots may also show clipboard notifications or other profile names, so review them carefully before posting. Public troubleshooting doesn't require full credentials; sharing them only creates more work later.

Keep a recoverable baseline before updating

Before updating the client, note the core, proxy mode, and custom rules in use, and back up essential settings using a method supported by the client. Store the backup somewhere private, not in a public synced folder. After updating, keep the same mode and verify a connection that worked before enabling new features. If one profile fails only after the update, compare the relevant capabilities and generated configuration rather than changing all the remote settings at once.

Write a useful problem report

“It won't connect” can mean a subscription update failed, the service won't start, a request never reached the inbound, the outbound handshake failed, or a particular destination is having trouble. Record the operating system, client, core, current mode, conditions, and most recent change. Note whether disabling the proxy restores access. This makes the issue reproducible and helps identify what to change next. For speed issues, continue with a layered check of servers, routes, and local settings.

Part 9 · Add features as needed

Advanced setup: from a working profile to verifiable rules

Advanced setup isn't about turning on every switch. Add one verifiable capability only when you have a clear need. After the first eight sections, you should have a stable baseline and understand how requests enter, how routing works, where DNS resolution happens, and how to restore the original setup. From there, explore protocols, custom routing, DNS strategies, and configuration management one step at a time. For each test, note the goal, expected result, and rollback plan instead of memorizing settings without knowing what they solve.

Understand the connection parameters first

For protocols, start by comparing VMess and VLESS. Understand the roles of authentication, encryption, and transport security, then learn what TLS or REALITY requires from the server. A protocol name doesn't guarantee performance, and removing a field doesn't necessarily make a connection faster. Transport, network path, and server implementation all matter. Read how VMess and VLESS configurations differ, then explain each field in your own profile.

Security settings must match the server. Server names, public-key-related fields, fingerprint options, and transport paths all have specific purposes; don't assemble them from unrelated examples. For certificate or handshake problems, check the system clock, name matching, and profile source first. Don't use certificate verification bypasses as a permanent fix. If the provider changes security settings, get a complete updated profile rather than replacing only the field that looks different.

Treat custom routing as a small experiment

Start with a single exact domain: decide whether it should connect directly or through the proxy, add one rule, check the match, and confirm that other destinations are unchanged. Only then expand to a domain suffix or IP range. Broader rules need a clear reason for covering more connections; the number of rules doesn't determine configuration quality. Document the purpose of rules you keep, and review old exceptions so you don't forget why one sits ahead of the default rule.

When rules conflict, reduce the test to the smallest possible set, then restore them one at a time and observe the result. Importing a large rule set you don't understand makes it hard to tell whether it suits your core and DNS path. Presets, custom rules, and full configurations in a GUI may override one another, so first find out how the client combines them. If the client rewrites a generated file after an edit, you probably changed the wrong persistent setting—not necessarily a file permission issue.

Learn DNS strategies and FakeDNS later

For DNS, learn ordinary domain resolution and address matching before exploring FakeDNS. FakeDNS uses mapped IP addresses to preserve domain associations, which must later be restored correctly and coordinated with the inbound and routing. It's not a universal option you can enable independently of your setup. App caches, connections that bypass the client, or an incomplete mapping path can all cause failures. Consider this mechanism only when you can explain where domain information is being lost.

When testing DNS strategies, use one fixed destination and observe the DNS result, actual outbound, and failure stage separately. Don't assume a cached lookup makes every request faster, or apply a change to every device because it helped one site once. Desktop and Android may use different inbounds and system DNS environments. The concept may be shared, but each settings combination needs its own test. When moving a setup, copying the goal and verification method is more reliable than copying every switch.

Keep personal configuration notes

Date your notes and record the purpose of each change, settings page, old and new values, test destination, and result—but never include real subscription URLs or account credentials. Keep client settings, connection profiles, and rules organized separately so you can decide what to reimport or restore manually when moving devices. If something breaks, return to the last working state before repeating experiments one at a time. That's easier to maintain than relying on an old full-screen screenshot.

When something goes wrong, return to the section that matches the symptom: import errors to subscriptions, apps that bypass the proxy to proxy modes, incorrect outbounds to routing and DNS, and problems after enabling a virtual interface to TUN. To set up a basic connection again, use the quick-start guide. To switch platforms, check the client and architecture on the downloads page. Mastery means being able to explain and verify a configuration—not using the most complex combination.