V2Ray Configuration Guide
From Installation to Routing

Core Concepts: The Interface, Core, and Connection Path

What the GUI Client and Proxy Core Each Do

V2Ray is a core project in the Project V proxy ecosystem. The tools used for everyday configuration—v2rayN, v2rayNG, and v2flyNG—are GUI clients that manage servers, subscriptions, routing, and startup options. The core handles the actual connections. V2Fly and Xray are related core families, but their feature development and configuration support are not identical. An option in the interface does not guarantee that every core can run the corresponding configuration. To check compatibility, consider the client, core, and server requirements together.

A typical connection path works like this: an app makes a request, traffic enters a local proxy, and the core uses its rules to choose a direct connection, proxy, or block before establishing the next connection. Seeing “Start” in the GUI only means the client has attempted to launch the core; selecting a server only sets the default proxy exit. Reaching the destination also depends on whether the app uses that local proxy, whether its domain resolves, whether the server settings are correct, and whether the destination accepts the connection. Troubleshoot each step of this path in turn.

Keep Protocols, Security Layers, and Transports Separate

VMess, VLESS, Trojan, and Shadowsocks are different proxy protocols. TCP, WebSocket, and gRPC describe transport methods, while TLS and REALITY involve connection security. A share link combines settings from these layers, so you cannot reliably recreate a node by protocol name alone. Two VLESS configurations may not work together if they use different transports, security settings, or service names. Import the same combination provided by the server instead of trying common options one by one.

In particular, distinguish the server address, TLS server name, and HTTP Host. The server address identifies the connection endpoint; the server name is typically used during the TLS handshake and certificate verification; Host may be used for application-layer forwarding. These values may match or differ, depending on the server setup. REALITY may also require a public key and short ID, among other paired parameters. Do not fill in missing fields with values from another configuration. Check with the configuration provider instead of disabling verification to work around an error.

How Subscriptions, Share Links, and Local Configurations Differ

A share link usually describes one server configuration, while a subscription URL lets a client periodically retrieve a collection of configurations. A subscription is not a proxy connection or an account. Successful import means the client could parse the content, not that every connection in it works. Some subscriptions target a specific client or format, so opening one in a browser does not mean it can be imported directly. A full configuration file may also include inbounds, DNS, and routing, covering more than a single share link. Check what you are importing before proceeding.

The chapters that follow use the same troubleshooting order: check the configuration, confirm the core starts, verify that the app connects, and then inspect the routing exit. Change one layer at a time and keep the last working setup. This makes it easier to tell whether a connection failure comes from the import format, connection parameters, or the way traffic is captured locally. Protocol, subscription, and client names describe different things; none alone tells you the speed, reliability, or quality of a service.

Choose a Client: Desktop and Android

Use v2rayN on Desktop; Choose an Android Client by Core

For Windows, macOS, and Linux desktops, start with v2rayN. Its GUI brings server management, subscription updates, routing choices, and core settings together, making it useful for checking connection status, managing multiple configurations, and adjusting routing. The Windows download page offers a desktop edition and a classic WPF edition. The former uses a cross-platform interface; the latter uses the classic interface. These are not performance tiers, and the newer interface does not necessarily mean broader protocol support. Check the included core and release notes for actual compatibility.

For Android, v2rayNG is the primary choice and uses the Xray core; v2flyNG, which uses the V2Fly core, is an alternative. Choose based on your configuration requirements, device compatibility, and required core features—not by running both clients at once on the same device. Android VPN capture is usually handled by one active service at a time, and another VPN, work profile, or security tool may compete with it. To compare clients, stop the current service first, then launch the one you want to test on the same network with the same server configuration.

Architecture and package format determine whether an installer will run

The installer must match your processor architecture. On macOS, check About This Mac: choose arm64 for Apple Silicon or x64 for Intel. On Linux, package format also matters: Debian and Ubuntu typically use deb, while Fedora and similar distributions use rpm. Matching the file extension alone does not guarantee compatible dependencies. The Windows downloads listed here are x64, not universal installers for every processor. If the architecture does not match, choose the correct package rather than repeatedly trying to launch it.

On newer Android devices, arm64 is usually a good first choice. If your system uses another ABI, choose a compatible package. The universal build includes more architectures and can help when you are unsure, but its larger size does not improve connection performance. The device’s release date is only a rough guide; check the architecture listed by the system or device for a reliable answer. If installation reports an incompatibility, check system requirements, ABI, available storage, and possible conflicts with an older signing key.

Choose Based on What You Need to Do

If you want to use one subscription on both a computer and phone, check that both clients support its format and the server’s required protocol; the client names do not have to match. A share link can carry connection parameters, but desktop system proxy settings and Android app routing are local settings that usually need to be configured separately. If the server requires REALITY, confirm that the client and core support the required fields. “Supports VLESS” does not mean every VLESS configuration is supported. For a closer look at protocols, read the protocol comparison.

Before installing, check the platform and download option on the client downloads page, then use the client comparison to confirm which option suits your needs. Keep one client as your primary choice and use another only when you need it for comparison or troubleshooting. Compare performance with the same server, network, and destination; differences may come from the remote setup rather than the client. Note the installer type you chose and use the same branch for future upgrades to keep configuration paths, startup behavior, and migration steps consistent.

Installation and Setup: Prepare a Working Local Environment

Before Installing: Check Permissions, Paths, and Existing Settings

Before installing, close any similar client that is already running and confirm that the download matches your operating system and architecture. If you have used a portable folder or a different installation branch, back up your settings first; do not mix old and new files in the same directory. The installation folder and user configuration folder may be separate, so deleting program files does not always remove settings. If a reinstall keeps the old configuration, check the client’s configuration location or the system’s app data folders to find where it is stored. Avoid deleting files belonging to other apps.

After installing on Windows, launch the app and check that the main window opens normally, then review the runtime log. Put portable versions in a stable folder you can write to; do not run them from a compressed archive preview or a temporary directory that may be automatically cleared. Ordinary system proxy use usually does not require running as administrator. TUN or related services may require elevated permissions. If security software quarantines a file, check its source and the specific detection details before taking action; do not disable system protection wholesale.

Complete the First Launch on Each Platform

On macOS, choose the package for your chip as directed on the download page, move the app to a stable location, and launch it. If macOS blocks it, read the specific reason under Privacy & Security and follow the system’s authorization steps. Avoid broad commands that disable security checks for all apps. When prompted for network or helper-component permissions, confirm that the request comes from the client you just installed. If no window appears, check the menu bar or Dock to tell whether the app is running in the background, its window is hidden, or the app has quit.

On Linux, install the deb or rpm using your distribution’s supported package manager. Resolve any dependency issues reported by the manager before launching the GUI. System proxy support depends on the desktop environment; a success message in the client does not mean every app is using the proxy. On Android, open the main screen after installation and import your configuration. The first time you start the proxy, you will usually need to approve VPN access. This prompt lets the system create a local traffic-capture service; it does not verify the subscription or confirm a remote connection.

Check the Local Proxy Before the Server

For the first run, leave TUN off and temporarily disable other proxy tools. In settings, check the local listening address, port, and inbound type: HTTP, SOCKS, or mixed. There is no universal local port, and example ports should not override your actual settings. If the log says the address is already in use, close any leftover instance or choose a different listening port. If you change the port, update any apps with manually configured proxy settings; otherwise they will keep sending requests to the old endpoint.

Start by keeping the listening address on the loopback interface for local use only. “Allow LAN connections” exposes the proxy to a wider network; it is not the same as sharing files. If you need it, restrict access with firewall rules and appropriate access controls. You do not need LAN access or every advanced option for an initial test. You can test the interface, save settings, and open logs before adding a server. If the core will not start, fix its path, permissions, or dependencies first; updating a subscription will not repair the local runtime environment.

Keep a brief setup baseline: operating system, client edition, configuration location, local inbound, and current permission model. Do not include account details, subscription URLs, or server credentials. These notes can help you tell the difference between an app that will not start and a proxy connection that will not work during future upgrades or migrations. Installation alone is not a complete setup; a stable environment gives you a reliable starting point for each change. For the exact button sequence, see the quick start guide.

Import Subscriptions: Groups, Updates, and Configuration Checks

First, Identify Whether You Have a Subscription URL or Share Link

A subscription URL is usually a link the client can use to fetch configurations online. Share links commonly start with vmess://, vless://, trojan://, or ss://. Check which type you were given before copying it. A subscription management page URL is not a subscription URL, and a login page is not a list of servers. Treat URLs containing account IDs or access parameters as sensitive; do not post them in public comments, screenshots, or group chats.

In v2rayN, open subscription group management, create a clearly named group, then enter and save the subscription URL. Update that group and check the result and server list instead of repeatedly clicking import. In v2rayNG, add the URL in subscription settings and update it from the relevant menu. Menu names can vary between versions, but the essential steps are the same: save the source, then fetch its contents. Import a single share link from the clipboard; there is no need to create a network subscription for one server.

After Import, Check the Fields That Affect Connections

Once servers appear in the list, select one and review its settings. Check the address, port, user ID or password, protocol, transport, and security settings. For WebSocket, check the path and Host; for gRPC, check the service name; for TLS, check the server name and certificate verification option; for REALITY, check the public key, short ID, and required fingerprint. Required fields depend on the server configuration. Do not fill an empty field with a commonly used value just because it is blank.

If import fails with an unsupported format error, check whether the copied content includes explanatory text, leading or trailing spaces, or truncation by a messaging app. A subscription that returns a login page, an error message, or a format intended for another client may also fail to parse. Treat opening a page in a browser and parsing a configuration as separate checks. If you need to convert formats, use a trusted method with clearly documented compatibility. A conversion service may be able to access the entire subscription, so do not submit sensitive URLs to an unknown website.

A Failed Subscription Update Does Not Mean Every Server Is Down

A subscription update is a separate HTTP request and may be affected by DNS, certificates, network status, or access permissions. If existing servers still connect, keep them and check the subscription update log. Some clients let you fetch subscriptions through a proxy, which can help when direct access to the source is unavailable but an existing proxy works. On a fresh install with no working connection, that option cannot solve everything. Also check the device clock; an incorrect time can disrupt secure connections.

Before updating, understand how the group handles replacements. Subscription-generated entries may be rebuilt on the next update, so manual changes to names, parameters, or order may not persist. For temporary changes, copy an entry into a separate manual group and label its purpose clearly; keep experimental entries out of your main list. Removing a subscription source and deleting its imported servers may be separate actions, so read the confirmation prompt before cleaning up. Organizing groups by source or purpose is easier to maintain than relying on symbols in server names.

After importing, choose one server with clearly defined parameters as your baseline and avoid switching through the list in bulk. Confirm the group, selected server, and subscription source and update time before moving on to check app access. A compatible subscription can be shared between desktop and Android, but local routing, app lists, and permissions still need separate checks. See the guide to syncing configurations across devices for migration tips. A successful subscription update does not prove the full proxy path works.

Proxy Modes: Configure App Access and Exit Routing Separately

System Proxy Only Covers Apps That Use It

A desktop system proxy tells apps that follow system settings which local proxy to use. Browsers typically read these settings, but command-line tools, games, and some desktop apps may use their own connection methods. If an app still connects directly after you enable the system proxy, that does not automatically mean the server is down. Check whether the app supports the system proxy, has its own proxy or bypass settings, and then decide whether to configure it in-app or use TUN in a later section.

Common v2rayN system proxy options include Clear, Set system proxy, and Do not change system proxy. “Clear” removes the related system proxy settings; “Set system proxy” points apps that support it to the local inbound; “Do not change” means the client does not actively change the current system settings—it does not guarantee that no proxy is configured. Another app may have set a proxy address that remains in place. If web pages stop loading after you exit the client, check whether the system is still pointing to a local port that is no longer active.

Global and Bypass Rules Determine the Exit

Routing is a separate layer. A typical global proxy mode sends traffic that reaches the core through the proxy exit; presets such as bypassing mainland China use domain and IP classifications to choose direct or proxied connections. “Global” does not guarantee that every process on the operating system is covered: traffic that never reaches the core cannot be captured by its rules. The system proxy determines whether traffic enters; routing determines where it goes once inside. Together they determine the result. Check the rule list provided by your client to see exactly what a preset does.

A direct connection does not mean the client is off. A rule may send traffic through the core and then connect directly to the destination from the local device. A block rule explicitly rejects a matching request; that is different from a connection timing out. For troubleshooting, you can temporarily compare results with a simpler routing mode, but restore your original settings afterward. Do not treat a temporary global mode as a permanent fix. If global proxy works but split routing does not, check the rules and DNS before importing the same subscription again.

Use a Repeatable Test to Confirm App Access

For the test, keep TUN off, start the core, enable the system proxy, and use a browser known to follow system settings to visit a known destination. Then check the log or connection details for that destination. Reused connections, caches, or the browser’s own secure DNS settings can affect the result; open a new connection or restart the app and compare. To test a specific local HTTP inbound, you can use the command below. Replace the port with the one your client actually listens on and confirm that the inbound supports HTTP proxying.

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

This command only tests a request through the specified inbound; it does not change the system proxy. The example port is not a universal default. If the proxy connection is refused, check the local listener. If the proxy connects but the request times out afterward, check the server, DNS, and remote access. The destination may respond unusually to a HEAD request, so an HTTP error status does not necessarily indicate a proxy failure. Check the connection details. If you do not have a command-line tool, you can make the same comparison using an app’s own proxy settings.

Android normally routes traffic through the system VPN interface; per-app proxy and LAN bypass options can change which traffic is covered. Do not apply the desktop system proxy options to Android as if they were equivalent. If only some apps have problems, check whether they are included in the proxy scope, restricted from running in the background, or competing with another VPN service. For more on these modes, see system proxy vs. routing modes. Get a repeatable result before fine-tuning split routing.

Proxy Routing: Rule Order, DNS, and Outbound Tags

Understand Match Order Before Adding Rules

Routing rules are usually checked in order: the first matching rule selects an outbound, and unmatched connections use the default policy. Check the core documentation for how rule fields combine and match; the rule list is not just a collection of labels. A broad proxy rule near the top may prevent later, more specific direct-connection rules from ever matching. Start with a short rule set: necessary LAN handling, specific domain exceptions, regional rules, and a default outbound. Verify each rule before adding more.

Domain and IP rules rely on different information. A client can match a domain directly when it knows the original domain; if it only sees the destination IP, there may not be enough information for a domain rule. DNS results also affect IP classification, so check DNS and routing as a single system. Do not classify a site as direct just because its content is in Chinese: a site's domain, CDN, and server location do not have a fixed relationship. Regional rules rely on maintained datasets, not live measurements.

Place Configuration Snippets at the Correct Level

The following Xray routing object is an instructional snippet, not a complete, runnable configuration. It shows the order for direct connections to private addresses, specified domains, and regional rules. Before using it, confirm that the current configuration has an outbound named direct and that the required geosite and geoip data files are installed. If your GUI client offers a rule editor, use it rather than editing the runtime-generated configuration. Without the full context, including the default outbound, this snippet does not show where all traffic will go.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

geosite:cn → direct matches the relevant domain set and sends it to the direct outbound; geoip:cn applies to the address set. domain:example.com matches a domain suffix and usually covers that domain and its subdomains; it is not a substring match anywhere in a string. AsIs does not resolve domains to IPs specifically for routing matches, so requests that arrive with a domain may not be affected by regional IP rules alone. Before choosing another resolution strategy, understand when it runs and the cost of its queries.

Sniffing, DNS, and the Limits of Exceptions

Traffic sniffing can help recover domain information for certain protocols, but it cannot identify every request and is not a general way to bypass app encryption. Apps using their own DNS, encrypted DNS, or direct IP connections may expose different information to routing. After changing sniffing or DNS settings, check how the matching rule changes for the same destination; do not judge only by whether a page loads. If the client shows connection details, check the actual destination, matched rule, and outbound. Normal logging may not capture everything.

When adding exceptions, use the narrowest possible domain or address range and place the rule appropriately. Directing an entire address range may affect unrelated services; proxying a broad domain category may disrupt LAN access. After changing the configuration, save and apply it, then establish a new connection; existing connections may not be re-evaluated immediately. If split routing fails, remove the last rule first, then check that the data files exist, the outbound tag is correct, and the domain does not include a protocol or path. Rule fields typically take a domain, not a full web address.

TUN Mode: Broader Traffic Capture and Loop Prevention

When Do You Need TUN?

TUN captures IP traffic through a virtual network interface. It is useful for apps that do not read system proxy settings or are difficult to configure individually. It changes how traffic enters the client; it does not fix incorrect server parameters or make the server support a new protocol. If your browser and proxy-aware developer tools already work, you can keep using the system proxy. Add TUN only when you have a clear traffic-capture issue; that keeps troubleshooting manageable.

Desktop TUN often involves a virtual interface, routing table, DNS capture, and elevated permissions, with the details depending on the client and core. The v2rayN GUI may coordinate different cores or helper components, so do not assume TUN is a single setting that works with every Xray configuration. Before switching cores, check that the new core supports your server, security settings, routing, and DNS. Being able to import a configuration does not mean it will behave the same at runtime. In particular, do not directly swap raw configuration files between different core families.

Enable TUN in Stages, Not All at Once

Before enabling TUN, confirm that the same server works through the system proxy or an explicit in-app proxy. Back up your settings and close other VPNs and traffic-capture tools. Follow the client prompts to install any required service or grant permissions, then turn on TUN. For the first test, keep the recommended stack and automatic routing settings; do not also change the MTU, DNS address, and app exclusions. If the interface fails to start, check permissions, leftover processes, and driver status before switching subscriptions or testing servers in bulk.

Some setups can use TUN and the system proxy together, but for troubleshooting, avoid overlapping methods so you can tell which path a request takes. After enabling TUN, test a regular webpage, then the app that did not use the proxy before, and finally LAN devices and internal services. One working app does not prove that UDP, IPv6, and every DNS request are handled as expected; support depends on the client, core, server, and network path. Test actual functionality separately for voice calls or games.

DNS, Loops, and LAN Exceptions

When capturing DNS, make sure queries can reach their upstream and that connections to the upstream are not repeatedly captured by the same rules. Traffic from the proxy client to its server also needs the right exclusions or outbound interface; otherwise, it can form a routing loop. Symptoms may include connections piling up after startup, unusually high CPU usage, or total network failure. First turn off TUN to restore your baseline, then check automatic routing and outbound exclusions. Do not mask the problem with a growing list of arbitrary direct-connection rules.

Printers, shared folders, router admin pages, and corporate addresses may need explicit bypass rules, but decide whether private-address traffic should go direct based on your network. Corporate networks may provide internal routes through a specific VPN, so a simple bypass does not guarantee access. Check IPv6 capture separately: success over IPv4 does not prove that IPv6 traffic follows the same path. If some sites fail, compare DNS results and address families before investigating MTU or path issues; do not assume every problem is DNS-related.

After turning off TUN, check direct connections, LAN access, and network behavior after waking from sleep. An abnormal client exit may leave a service or system setting behind; use the client’s normal shutdown process first, then follow the operating system’s network management steps if needed. Android VPN capture uses different permissions and routing from desktop TUN; do not copy desktop driver, service, or interface instructions. Use TUN day to day only after confirming that the target app is captured, internal resources remain reachable, and the network recovers when the client stops.

Maintenance: Logs, Speed Tests, Updates, and Backups

Isolate the Layer That Is Failing

When something goes wrong, note when it happened, the network you were on, the affected app, and your last change. Confirm that the client is running, the core has not exited, and the local inbound is not in conflict; then check the selected server and routing. A log entry such as connection refused usually means a connection target rejected the connection, but that target could be local or remote. Check the address. i/o timeout means a request waited too long; by itself, it does not prove that an account is invalid, a server is down, or DNS has failed.

For a handshake failure, check protocol parameters, security settings, device time, and server requirements. A log error may come from a background check or an old connection that has already closed, so interpret it in context. You can temporarily increase the log level, reproduce the issue once, then restore the normal level to prevent logs from growing indefinitely. Before sharing logs, remove server addresses, user IDs, subscription parameters, and personal information from requests. For more help, see how to read runtime logs.

Match Speed Tests to the Problem

TCPing mainly shows whether a connection to a destination port can be established; it does not verify proxy authentication or access to the destination. A real connection latency test uses more of the proxy request path, but still depends on the test destination, DNS, handshake, and current network load. Download tests measure throughput and use actual data, but do not represent performance for every destination or app. Results from different methods are not directly comparable, and one failed test is not enough reason to delete a configuration. First make sure the test conditions match.

For a fair comparison, keep the device, network, test destination, and proxy mode the same. Avoid updating subscriptions while running batch speed tests. First check whether a real connection can be established consistently, then measure the throughput and response time your app needs. Background sync, changes in Wi-Fi signal, and server-side limits can all affect results; the order in the client list is only a snapshot. For more on the metrics, see the difference between latency and download speed tests. Frequent full-list testing is rarely useful; retest a small selection to investigate the current issue.

Make Updates and Backups Reversible

Before upgrading, export the client settings and save your working routing, DNS, and custom groups. Backups may contain active credentials, so store them somewhere protected rather than syncing a full configuration as an ordinary screenshot or document. Prefer the client’s built-in export or backup feature. Stop the client before copying files manually to avoid backing up data while it is being written. Program files, user settings, and automatically generated runtime configurations are different things; keeping only the installation folder may not be enough to restore your setup.

Upgrade from the download page using the same operating system, architecture, and interface branch. Keep your old backup, then test core startup, subscription updates, routing, and TUN. A new version may migrate the configuration structure. If something goes wrong, do not have an older version read the migrated data; restore the pre-upgrade backup instead. Verify client and core updates separately so you can identify the source of an issue. Unless you have a specific need, there is no reason to switch cores repeatedly in pursuit of an abstract idea of “faster.”

Keep routine maintenance brief: check that subscription sources work, remove test entries you no longer need, confirm that your backup opens, and look for unusual log growth. Enable auto-start and scheduled subscription updates only after the setup is stable; check how they behave after sleep, network changes, and system updates. After restoring a configuration, verify a real connection rather than just checking the number of entries. A setup you can reproduce, explain, and roll back is more valuable than one full of untested switches.

Advanced: Reproducible Setups and Cross-Device Migration

Establish a Working Baseline Before Performance or Protocol Tests

After completing the first eight stages, write a credential-free summary of your setup: client edition, core, server protocol and transport combination, app connection method, routing preset, DNS strategy, and TUN status. The goal is not to copy every field, but to retain enough context to troubleshoot later. Use a verified working configuration as your baseline. Change one variable at a time and record what you expect, what happened, and how to revert, rather than switching several options from memory.

Advanced protocol setup starts with understanding how the fields constrain one another. VLESS does not provide the same built-in encryption mechanism as some other protocols; security depends on the selected security layer and complete configuration. Trojan is commonly paired with TLS; Shadowsocks requires the same encryption method and password at both ends; VMess behavior also depends on the implementation and parameters. Do not infer performance or security from the protocol name alone. The right choice also depends on device resources, network path, server implementation, and how the service is operated. Evaluate the complete setup.

Check Compatibility Before Tuning REALITY and Transports

A REALITY setup requires the client and server to agree on security parameters. Confirm the server name, public key, short ID, fingerprint, and any other required fields using a trusted source, and check that the core supports them. If the handshake fails, first look for missing parameters, an incorrect device time, or an unreachable endpoint, then check the transport combination. Disabling certificate verification is not a normal fix for incorrect parameters, and you should not copy fields from another server. After switching cores, verify that all these fields were preserved correctly.

Tune transports to solve a specific problem. Connection reuse, concurrency, MTU, or DNS caching may help in some situations, but can also consume more resources or change how failures appear. First identify whether you want to reduce repeated handshakes, improve response times in a particular app, or fix a path issue, then choose the relevant option. Test against the same destination and workload over a period of real use rather than relying on one unusually good result. If a change does not produce a repeatable improvement, return to a simpler, easier-to-maintain configuration.

Sync Only What Belongs on Multiple Devices

Desktop and Android can share a compatible subscription, but app routing lists, local listeners, system proxy settings, TUN permissions, and configuration folders are device-specific. Do not overwrite a phone’s configuration with a desktop runtime configuration, or assume the same subscription automatically gives both devices the same routing. Install the client independently on the new device, import from the same trusted source, and test one server before recreating routing and DNS settings. Keep the old device working until the new one passes real app tests.

Share links are useful for transferring a few servers, QR codes for importing nearby, and full backups for restoring the same client type; all require the same care. Check the recipient, transfer method, and storage location, and remove temporary files and screenshots when migration is complete. Routing rules can be documented separately with the supported core, outbound tags, and required data files. Store sensitive parameters separately. If formats differ, compare what the fields mean rather than removing security settings you do not understand just to make an import succeed.

Finish Every Configuration Change with Verification

After each change, run the same checks: the core starts, the specified app connects, traffic follows the expected route, LAN resources work, and the network recovers after the client stops. Add focused tests for UDP, IPv6, or TUN when relevant. If you cannot explain a result, save the logs and setup summary, revert to the working baseline, and narrow down the reproduction steps. One webpage loading is not a complete test, and temporary success does not mean every app is configured correctly.