The Complete V2Ray Guide
Advanced v2rayN Setup and Configuration

Core Concepts: Client, Core, and Server

How the Connection Works

The graphical client stores server settings, manages subscriptions, configures the system proxy, and passes your selections to the proxy core. The core listens on local ports, applies routing rules, establishes remote connections, and handles the protocol. The server provides remote access and must use compatible protocols and settings. Installing v2rayN only prepares the local software; it does not give you access to a working remote server. A subscription URL is not a software download link.

A typical request flows like this: your browser reads the system proxy settings and sends the request to a local listening port. The core matches the destination domain or IP against its routing rules, then chooses a direct connection, a proxy, or a block. Only the proxy route uses the selected server's protocol to establish a remote connection. Troubleshoot each link in this chain rather than assuming a server is down whenever a webpage fails to load. A browser that isn't using the proxy and a failed remote handshake are different problems.

Project V provides useful background on this software ecosystem. V2Fly and Xray are related core families, while v2rayN and similar apps are graphical clients for end users. Their names may be similar, but their roles are different. When reading a guide, first identify whether it describes client controls, core configuration fields, or server deployment settings. Importing core JSON as a subscription URL, or asking another app to parse a client backup, usually won't work as expected.

Protocol, Transport, and Security Settings Must Match

VMess and VLESS are proxy protocols; TCP, WebSocket, and gRPC are transport options; TLS and REALITY involve specific security settings. A working connection depends on more than the protocol name: the address, port, user ID, transport path, and security parameters must all match. Start with the settings provided by your subscription. Don't replace an option just because another one looks newer.

Be especially careful to distinguish the connection address from the server name indication. The connection address determines where the request goes; the server name in TLS is used during the handshake and certificate checks. These values can differ in some deployments. The Host header, path, or service name used by a transport also has its own purpose; don't put the profile name in those fields. If the server requires a specific value, leaving it blank or entering the wrong one can cause a handshake failure. Disabling certificate verification is not a general fix for an incorrect address or server name.

Start with a Testable, Minimal Setup

Keep your first configuration simple: use one app that respects the system proxy, one known configuration, and one specific destination. Leave TUN off, avoid complex routing, and don't change DNS at the same time. Establish a working baseline before adding split routing. If several settings change together, even a successful connection won't tell you what fixed the problem—and the next failure will be harder to diagnose.

Note the client name, operating system, proxy entry point, protocol, and one test result. You don't need to save subscription credentials or full share links; record enough to reproduce the setup. If a term is unclear, check the glossary before changing settings. By the end of this section, you should be able to explain how a request reaches the core and whether it goes direct or through a remote proxy—not memorize every protocol name.

Choose a Client: v2rayN for Desktop, Android Clients by Core

Check Your OS and Processor Architecture First

For desktop use, start with v2rayN, which supports Windows, macOS, and Linux. Check your system's processor architecture before downloading rather than guessing from numbers in the filename. x64 generally means a 64-bit Intel or AMD desktop environment; arm64 is for compatible ARM systems. An incompatible package may not install or may rely on a compatibility layer—neither is a good default for a first setup.

The Windows download section offers a desktop edition and a classic WPF edition. The desktop edition uses a cross-platform UI, while WPF retains the classic Windows interface. Choose based on your preferences and system compatibility; these are not different proxy protocols. Menus, configuration folders, and migration steps may differ. If you already have settings, back them up and use the client's import options rather than replacing the entire application folder.

On macOS, choose the Apple Silicon or Intel download. Check your chip or processor in About This Mac. On Linux, consider both architecture and package format: Debian- and Ubuntu-based systems typically use deb, while Fedora-based systems typically use rpm. The package format determines which package manager installs it; it says nothing about protocol support. Don't force a package from another distribution onto your system just to use a particular protocol.

Choosing Between the Android Clients

For Android, v2rayNG is the primary choice and uses the Xray core; v2flyNG is an alternative for the V2Fly core. If the server documentation requires a specific core implementation, check that the client supports the required settings instead of judging compatibility by protocol name alone. Importing the same share link doesn't guarantee that every extension field is applied correctly. Check the security and transport settings after import.

Android packages are available for arm64 and as a universal build. Most recent phones use arm64, but check your device's actual architecture; use the universal build if you're unsure. Don't run both clients with VPN mode enabled to compare them: Android generally allows only one active VPN connection, so starting one app may replace the other and make results seem inconsistent.

Keep Server Settings Consistent, Not Every Client Setting

Across desktop and Android, supported subscription URLs or individual server share links are usually the easiest settings to reuse. Local paths, proxy entry points, and routing files are the least portable. Desktop system proxies, Android's VPN interface, and desktop TUN all handle traffic entry, but use different permission models. After syncing across devices, verify each device's entry point, DNS, and routing separately. One working device doesn't prove the others are configured correctly.

Find downloads in the Download Center, and compare client options in Client Comparison. For this stage, choose one primary client and one installer, and keep the default core for now. If the basic connection works and you have no specific compatibility issue, switching cores isn't a routine optimization. Keeping variables to a minimum makes your setup easier to verify than repeatedly changing tools.

Installation: Confirm It Starts Before Changing Network Permissions

Prepare the Folder, Processes, and Existing Settings

Before installing, quit other proxy apps and check the system tray or menu bar for old instances still managing the system proxy. When updating v2rayN, clear the system proxy and exit the old client first, then back up its settings. Don't overwrite files while the app is running or mix old and new installation folders. This helps prevent hard-to-spot cases where a new window is running alongside an old background core.

Install to a stable location that the current user can read and write as required by the client. Temporary extraction folders, removable drives, and directories that are automatically cleaned can cause settings or rule files to disappear after a restart. Check the client's documentation or its open-configuration-folder option to find out whether settings live in the application folder or the user data folder; don't assume every installation is the same. Back up the actual data location, not just a desktop shortcut.

On first launch, check that the main window appears correctly, the logs aren't reporting continuous errors, and the core starts. You haven't configured a remote server yet, so failing to reach a destination doesn't mean installation failed. Missing runtime components, quarantined files, or a configuration folder that can't be written to are local installation issues. If security software raises an alert, check which file and action triggered it rather than disabling all protection to bypass the problem.

Grant Platform Permissions Only When Needed

On Windows, everyday system proxy use usually doesn't require running the whole client as an administrator. Grant permissions when enabling TUN or installing a required network component, following the prompts. If startup changes ports or loses settings, first check whether you have both a regular and an administrator instance running. Elevated permissions can change the process environment; being able to open the app after elevation doesn't mean the underlying problem is solved.

On macOS, if developer verification blocks an app, check the relevant option under Privacy & Security and follow the system's instructions after confirming the source. Don't remove security restrictions from unknown files in bulk. System proxy settings and other network controls may require different permissions; opening the window doesn't confirm that all network permissions are in place. See the macOS installation and network permissions guide. The wording may differ by macOS version.

On Linux, use your distribution's package manager to install the appropriate deb or rpm package so dependencies remain managed. If a component is missing, check the installer or startup logs rather than manually copying unknown library files. Desktop system proxy settings may not apply to every desktop environment or command-line program. A successful installation only means the app can run; verify separately whether each app reads the proxy settings.

Establish Your First Installation Baseline

Once the client starts, check its local listening address and port. A common mixed-protocol port is 10808, but use the value shown in your current settings; older or custom configurations may differ. The listening address controls who can access the local entry point. For personal use on one device, keep the loopback address; don't expose it to your local network just to troubleshoot. If the port is occupied, identify the process first and check whether it's a duplicate instance before exiting it or changing the port.

At the end of this section, keep a configuration that starts without persistent local errors. Leave TUN and auto-start disabled until you've verified the full connection. If the core won't start, see Diagnosing Core Startup Errors in the Logs, and check ports, configuration syntax, field compatibility, and rule files in that order. Don't change remote server settings during installation; otherwise local and network issues will be mixed in the same logs.

Importing Subscriptions: URLs, Share Links, and Backups

Identify the Content Type First

A subscription URL is usually an updateable web address that returns server information when the client fetches it. A single share link describes one server connection. A client backup may also include groups, routing, interface preferences, and local settings. Each type has a different import flow. Check the provider's instructions first so you don't paste a management page URL into the subscription field or treat a full configuration file as a single server link.

In v2rayN, start by creating a subscription group. Give it a recognizable name, paste the address into the subscription URL field, and save. The name is for local organization and won't fix an invalid address. Check for leading or trailing spaces, line breaks, quotation marks, or characters changed by a messaging app. Subscription URLs may contain credentials, so treat them as sensitive. Don't include a full URL in public screenshots, log discussions, or online conversion tools.

After saving the group, update the subscription and check the logs and server list for the expected changes. A success message only confirms that the client completed a step; verify that it actually parsed the servers and retained their transport and security settings. If the list is filtered to another group, the new entries may be hidden. Select the correct group or all servers before deleting and recreating anything.

Separate Network Failures from Content Errors

If the logs report that the subscription domain can't be resolved, the request timed out, or a certificate error occurred, start by checking the path used to fetch the subscription. Confirm that the device is online and its system clock is correct, then check whether the update request needs to go through an existing proxy. On a fresh install, requiring a proxy before one is available can create a loop. If you already have a working configuration, choose the update route using the client's actual options rather than guessing from a button label.

If the request succeeds but parsing fails, check whether the response is a login page, an error page, or a format intended for another client. Some subscription converters regenerate connection details, but may omit client-specific fields. Use a converter only when there's a confirmed format incompatibility, and prefer an option provided by the source. Don't submit a credential-bearing subscription URL to a service whose data handling you can't verify.

A single share link is useful for testing one known configuration. Import it from the clipboard, then check the address, port, protocol, user ID, transport, and security settings one by one. A QR code carries the same kind of text; scanning it successfully doesn't prove the connection parameters are valid. Before editing an entry generated by a subscription, check whether the next update will overwrite your changes. Keep long-term custom settings in a separate manual group and note why you changed them.

Select an Active Server and Keep a Fallback

After importing, set the target server as active and check the main window and logs for the configuration reload result. A server appearing in the list doesn't mean the core is using it. Latency checks, connection tests, and browsing are different tests: passing one only confirms that particular test path. Verify the configuration with the app you'll actually use. If a test fails, check where it failed before changing a batch of settings.

Keep a working configuration before routine updates. After updating, verify the active server before removing old entries. Don't delete everything before backing up your only working configuration. Multiple devices can use a supported subscription, subject to the provider's device and connection rules, but manage routing separately on each device. For migration details, see Sharing Subscriptions and Exporting Configurations Across Devices. This stage is complete when you have a server with verified settings, selected as active, and independently tested.

Proxy Modes: Check the App Entry Before the Outbound Policy

The System Proxy Doesn't Control All Network Traffic

v2rayN's system proxy options typically include Clear system proxy, Set system proxy, and Do not change system proxy. Setting the system proxy points supported apps to the client's local listening entry; clearing it removes those settings; leaving it unchanged preserves the current system state. These options determine how an app reaches the proxy. Routing and outbound settings determine whether a domain ultimately goes direct or through a proxy.

The system proxy mainly affects apps that actively read that setting. Some command-line tools use environment variables, some apps have their own proxy settings, and others connect directly. So a browser working while a terminal doesn't isn't necessarily a server problem. Check whether the target app supports the system proxy, then choose an in-app setting, explicit proxy option, or TUN as appropriate. Don't keep changing remote servers before checking how the app connects.

Browser extensions can override the system proxy too. Temporarily disable proxy-related extensions, check that the browser doesn't have separate settings, then test with the system proxy. If one browser works and another doesn't, check their secure DNS, cache, and extension behavior. A simpler test setup makes it easier to tell whether requests are reaching the core. Running multiple proxy managers can cause them to overwrite each other's system settings.

Test the Local Listener with an Explicit Proxy

If the current mixed-protocol port is 10808, use the command below to send one HTTPS request explicitly through the local HTTP proxy. The destination is a reserved example domain and must be reachable for the test to work. The connection output can help identify whether the failure is at the local entry point, the remote connection, or the destination response. One successful request doesn't mean every app is using the proxy.

curl --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

If the command immediately fails to connect to the local port, check that the client and core are running, the port matches, and the listening address allows loopback connections. If it reaches the proxy but the handshake fails, check the server settings, system time, and security parameters. If the command gets a response but the browser doesn't, check the browser's proxy entry point first. In some Windows terminals, use curl.exe explicitly to avoid differences caused by a command with the same name.

With explicit SOCKS requests, check where DNS resolution happens. In curl versions that support it, socks5h://127.0.0.1:10808 sends the domain name to the SOCKS proxy for resolution instead of resolving it locally first. This difference can help diagnose DNS issues, but not every app supports the same syntax. If an app has separate host and port fields, fill them in separately; don't paste the full proxy URL into the host field.

Track Entry Mode and Routing Mode Separately

“Global” and “Rule” usually describe outbound policy, while the system proxy and TUN describe how traffic enters the core. These are separate concepts and can be combined. TUN can still use rules to send some traffic direct; with only the system proxy enabled, requests that reach the core can still use a proxy by default. When checking a setup, write down both which apps enter the core and how their traffic is routed afterward. This avoids confusion between differently named modes in different clients.

Clear the system proxy before quitting so apps don't keep sending requests to a local port that has stopped listening. If the network breaks after exiting, check for leftover system proxy settings and other apps that may have set a proxy before resetting the whole network. Once the basic connection is stable, configure auto-start and confirm that the core is ready before the system starts using the proxy. For quick steps, see the proxy modes section of the Getting Started guide; this section explains why the outcomes differ.

Routing: Rule Order, Match Types, and DNS

Set Expectations with a Simple Rule Set

Routing selects an outbound for requests that have already entered the core. Common outbound tags include direct, proxy, and block; they send traffic directly, through a proxy, or block it, and must refer to outbounds that are actually defined. Rules are generally checked from top to bottom, and the matching action is applied. A broad rule placed too early can prevent more specific rules below it from ever being reached.

For your first setup, choose a routing preset that suits your needs and inspect its rules before importing a large rule set. A common approach is to route private addresses directly, send destinations that must be direct to direct, and let a fallback policy handle the rest. Blocking ad categories is optional, not a prerequisite for a working connection. If blocking breaks sign-in, images, or payment pages, check the matched requests for false positives.

The following Xray routing object illustrates rule order; it isn't a complete, runnable configuration. It assumes that outbounds with the same tags are defined and that the required geosite and geoip data is available. The final rule covers TCP and UDP in this example and acts as a fallback. A client may generate default outbounds through a preset or other mechanism, so don't append this mechanically without understanding the existing configuration.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

Domain Rules and IP Rules Aren't Interchangeable

Domain matching requires the routing stage to have access to the destination domain. IP matching relies on the destination IP or on a resolved address that the policy permits. If an app connects directly to an IP, domain rules may not apply. Conversely, a request containing a domain name doesn't mean every domain policy will resolve it immediately and check IP rules. The example above uses AsIs; don't expect it to resolve every domain before checking its region classification.

geosite and geoip are classification data, not online lookup services. Whether rules can use them depends on core support, file availability, and the data itself. If an error says a category is missing or a file can't be read, check the rule data and configuration path; changing remote servers won't fix it. Classifications may not perfectly match how services are hosted. For a specific service, prefer a narrowly scoped, explainable domain rule over assuming regional classifications are always accurate.

DNS affects which address a request gets and may also affect subsequent routing. An app's encrypted DNS, system resolver, and core DNS aren't guaranteed to use the same path. Before making a change, record the current resolution method, change one thing, then check whether resolution succeeds, the connection destination changes, and routing matches expectations. A public DNS address isn't automatically reachable, and successful resolution doesn't prove the remote proxy connection works.

Test Rules Against Real Use Cases and Limit Changes

For testing, choose one destination that should go direct, one that should use a proxy, and one local network service. Check the relevant logs and actual results for each. A page loading only confirms that its request completed; an IP-check page can't show how every connection from an app is routed. A page may use multiple domains for its main content, static assets, and sign-in API, each matched separately. For partial failures, inspect the specific destination instead of widening the rules for the entire site.

Document what each custom rule is for and place it appropriately. To fix a work domain, first test with a clearly defined domain match before widening the scope. Save and reload the rules, then retest the same destinations and keep the previous version for rollback. For definitions of DNS, domain matching, and outbounds, check the glossary. Advanced routing means being able to predict which requests a rule will affect—not making the list longer.

TUN Setup: Expand the Traffic Entry and Check Routing and Permissions

Decide Whether You Need TUN

TUN receives traffic through a virtual network interface and system routes. It's useful for apps that ignore the system proxy or when you need to handle multiple types of network traffic in one place. TUN changes how traffic enters the core; it won't fix incorrect server settings or guarantee that every protocol and destination will work. If the basic connection doesn't work with the system proxy, finish the earlier checks first so remote connection and virtual interface issues don't get mixed together.

Before enabling TUN, record your working server, routing preset, DNS settings, and local network access, and make sure you know how to turn it off. Be especially careful when using remote desktop or remote management, as route changes could interrupt your session. Run your first test when you can access the device directly. Keep the existing network setup and don't change Wi-Fi, gateway, subscription, and core settings at the same time.

When enabling TUN, grant administrator or network permissions as required by the client. Check the logs for interface creation failures, route write errors, or permission denials. Implementations vary by platform and client; don't copy a driver setup from one platform to another. An enabled switch still needs to be verified in the logs and with the target app. The switch shows the intended setting, not that every system operation succeeded.

Prevent Routing Loops and Check Local Network Exceptions

Connections from the proxy core to a remote server mustn't be routed back into the same entry point, or a loop will occur. Clients usually manage the necessary routes or exclusions, but custom system routes, other VPNs, and security software may interfere. If enabling TUN causes repeated log entries or immediately breaks all access, turn it off to restore your baseline, then check for conflicts and custom settings. Don't rely on repeated restarts.

Test local network access separately, including the router admin page, printers, shared folders, and development servers. Direct-routing rules for private addresses help determine outbound behavior, but system routes, DNS, and app discovery can involve additional paths. One rule won't necessarily restore every local network feature. Test a specific local IP first, then determine whether a failure is due to name resolution, the connection path, or access restrictions on the service itself.

Understand DNS handling according to the current client's implementation. Some settings change the system DNS path; others handle only specific requests. Apps using their own encrypted DNS may behave differently. If an IP works but a domain doesn't, check resolution first. If the domain resolves but the connection fails, check routing and transport next. Don't copy DNS fields from a different core; similar field names can have different meanings.

Test UDP, Sleep, and Other Network Tools Separately

Traffic entering TUN doesn't mean the remote server supports every UDP use case. Voice and real-time communication also depend on server capabilities, transport, and local network conditions, so test the actual app. Don't blame client performance just because a browser works while a real-time app fails. If only one type of app has problems, identify its protocol, destination, and outbound first, then decide whether it needs a direct route or a compatibility adjustment.

After sleep, a network switch, or reconnecting to Wi-Fi, check that TUN is working again and system DNS is available. Enterprise VPNs and other virtual network tools may both change routes, and startup order can affect the result. Once you confirm a conflict, choose a clear traffic-control setup rather than piling on exclusions. This section is complete when the target app works, local network behavior is as expected, and disabling TUN restores the previous working state.

Maintenance: Close the Loop with Backups, Updates, and Logs

Manage Backups Separately from Subscription Updates

Subscription updates fetch server information from the source; they don't back up the entire client. Routing rules, DNS, proxy entry points, group preferences, and manual entries may not be included. Keep backups when your basic connection is stable, after important rule changes, and before upgrades. Label them with the OS, client edition, and purpose. Don't sync a backup folder publicly; it may contain subscription credentials, connection identifiers, and other sensitive settings.

Before restoring, make sure the target client supports the backup format, then restore only what you need. Don't assume local paths, permissions, or listening settings can be reused across platforms. To migrate servers, use a subscription or supported share link where possible. Restoring a full client setup also requires checking routing and DNS. A success message means the file was read; retest the connection and network behavior after quitting the client.

Automatic subscription updates can save time, but don't clear your existing working entries after a failure. Check the error and confirm the active configuration still exists before retrying or contacting the provider. Watch for updates overwriting manually edited subscription entries. For special settings you need to keep, record the exact changes and why you made them; that's more useful for migration and troubleshooting than a screenshot alone.

Change Only What You Need When Upgrading

Before upgrading the client, quit it and back up your settings. Read the release notes for features you use, especially changes to configuration formats, routing data, or permissions. Don't upgrade the client, switch cores, replace the subscription, and rewrite DNS all at once. Fewer variables make post-update problems easier to diagnose. Confirm how to roll back before replacing the old setup so you don't end up with neither a working new installation nor a recoverable old configuration.

After upgrading, test the same set of targets each time: a browser using the system proxy, an explicit proxy request, the local network services you need, and any apps that actually use TUN. Use the same tests as before the upgrade; don't just check whether the window opens. If only a new feature fails, turn it off temporarily and keep the basic connection. If the basic path fails too, use the logs to check configuration compatibility and the local runtime environment.

Configure launch at startup only after the client is stable. Distinguish starting the graphical client, starting the core, and automatically setting the system proxy. Linux desktop autostart runs in the user session; see deb/rpm Installation and Autostart. Don't run the entire graphical app as an unsuitable high-privilege service just to start it automatically. A mismatch between permissions and the user session can create differences in configuration paths and network state.

Keep Log Context; Remove Sensitive Data Before Sharing

When reading logs, find the first relevant error near the time the problem occurred, then check the preceding startup, configuration reload, or connection entries. Repeated errors afterward may be consequences of the same root cause. Connection refused, timeouts, certificate failures, and unknown fields point to different issues; they aren't all generic network problems. Note what you just did, which app you're testing, and whether the system proxy and TUN are enabled.

Temporarily increasing log detail can help with diagnosis, but restore the normal level once you've found the problem so unrelated entries don't obscure the important ones. Before sharing logs, remove subscription URLs, user IDs, full server details, and private browsing information; keep only the error type and necessary context. Make sure log timestamps match the system clock. A sound maintenance process has a backup, a test, and a record for each change, plus a clear rollback when it fails—not just the memory that restarting once fixed it.

Advanced Topics: Learn Protocols and Troubleshooting Through Real Problems

Follow a Layered Troubleshooting Order

Advanced configuration isn't about enabling more options; it's about identifying the right layer for a problem. Follow a consistent order: check the local network, whether the app enters the proxy, whether the core starts, whether server settings match, whether DNS works, whether routing matches the expected rule, and finally whether the destination service is working. At each step, look for evidence that confirms or rules out your explanation instead of skipping ahead on an untested guess.

For example, if a browser can't load a page, compare it with an explicit proxy request. If the local port can't be reached, check the process and listening settings. If the port is reachable but the remote handshake fails, check the protocol, security settings, and system time. If the proxy request works but the browser doesn't, check extensions, separate proxy settings, and name resolution. Breaking “can't connect” into these branches avoids reinstalling the client every time.

When one destination fails, compare it with several known destinations. If they all fail, check the shared entry point or remote connection first. If only one domain fails, focus on resolution, routing, the destination service, and its access requirements. Don't mistake a region notice, account status, or service restriction on one page for a proxy protocol failure. Establishing a connection and being allowed to use a service are different outcomes.

Study Protocols and Cores Around Real Needs

When learning protocols such as VLESS and VMess, first understand which fields must match between the client and server, then learn how transport and security settings work together. A protocol name alone doesn't determine speed, reliability, or suitability; deployment and network path matter too. A setup that works on one network may behave differently on another. Record the actual configuration conditions, not just a protocol label.

Before switching cores, check whether the target core supports your server settings, custom routing, and DNS fields. A client's interface can simplify common operations, but it can't guarantee that every advanced field behaves identically. Confirm a basic connection with a minimal setup, then restore custom settings one at a time. If an error reports an unknown field, correct it according to that core's configuration semantics instead of changing capitalization or deleting the line at random.

When editing JSON, check brackets, commas, quotation marks, and array structure first. JSON doesn't allow arbitrary comments or a trailing comma after the last item. Once the syntax is valid, check the meaning: do the outbound tags exist, can the referenced rule data be read, and is the listening port available? Valid syntax is only the first hurdle; a successful startup is the second. The configuration is ready only when it handles real requests as expected.

Turn Targeted Optimizations into Repeatable Tests

When investigating DNS, UDP, or compatibility with a specific app, define one question at a time—for example, “Does this app bypass the system proxy?” or “Does this domain match the direct rule?” Record the original result, change the smallest relevant setting, and test the same target again. Don't apply several supposed optimizations at once: if things improve, you won't know why, and if they get worse, you won't know the smallest change to roll back.

Understand what each test can and can't tell you. A connection test only reflects the method it uses; it doesn't replace extended real-world use. A fast response once doesn't predict every later request. Home, mobile, and office networks may use different DNS, proxy, and routing policies, so document the conditions when comparing them. Don't risk a stable setup that meets your needs just to chase a single number.

Keep a personal runbook: how to start and quit the client, the current entry point and port, which destinations should go direct, where backups are stored, and which logs to check first. If the main window is unfamiliar, see the v2rayN Main Window Overview. To rebuild the basic connection path, return to the Getting Started guide. The goal of this complete guide is a configuration you can explain, verify, and restore—not enabling every advanced feature at once.