V2Ray Configuration Guide:
From Core Concepts to Routine Maintenance

Core Concepts: Clients, Cores, and Connection Paths

What the Interface Sets vs. What Actually Runs

Before configuring anything, distinguish the graphical client, proxy core, and remote server. The client displays nodes, stores subscriptions, generates configuration, and manages system integration. The core reads that configuration, accepts local requests, and selects an outbound route. The remote server handles the protocol connection and onward access to the destination. A client window opening only confirms that the client is running; it does not prove that the core has started or that the remote settings are correct.

Project V is a useful starting point for understanding the ecosystem. V2Fly and Xray are related core families. v2rayN, v2rayNG, and v2flyNG are graphical clients, not protocol names. The fields a client supports depend both on its interface and on the capabilities of the core it runs. If a subscription imports but the client will not start, check the active core and generated configuration rather than assuming every feature is available based on the client’s name.

Inbound, Routing, and Outbound

Break a connection into three parts: inbound, routing, and outbound. The inbound accepts traffic from a browser or another app, commonly through a local HTTP or SOCKS listener. Routing selects an outbound based on conditions such as the destination domain, address, or port. An outbound can proxy, connect directly, or block. A failed remote connection is different from a request that never reaches the local inbound. For the first, check the node and network; for the second, check whether the app is using the right inbound.

Tags in a configuration link these components; they are not arbitrary comments. If a rule specifies an outbound tag, the outbound list must contain an entry with the same name, including matching capitalization. A client may hide these relationships and generate tags automatically. When reading core examples, understand their structure before pasting a snippet into a text field. Check in advance which settings are managed by the custom configuration and which by the graphical interface.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

Protocols and Transports Have Different Roles

VMess, VLESS, and Trojan describe proxy protocols. The transport layer determines how a connection is carried over the network, while TLS and REALITY concern connection security and handshake requirements. These components cannot be combined arbitrarily. When importing a node, treat the address, port, identity fields, transport type, and security settings as a set. A mismatch with the server can prevent the connection; changing only the protocol name usually will not fix it.

DNS is not a separate add-on outside this connection path. An app might resolve a domain first and pass the resulting address to the proxy, or keep the domain for the core or remote server to handle. Whether routing can see the original domain depends on the request format, proxy protocol, and related settings. If the destination appears as an address, do not assume the domain rule is broken. First check where resolution happened and whether the request still includes a domain that can be matched.

For initial testing, use one app to access one known destination. Record the inbound, active node, current mode, and result, then identify where the request stopped. The configuration above is a direct-connection-only example showing how components fit together; it does not provide remote proxy access. Get authentication details for a real service from a trusted source. Do not copy a seemingly complete set of fields from another guide if it does not match your service.

Choose a Client: Platform, Core, and Management

Choose by Device, Then Check Capabilities

For desktop devices, start with v2rayN and choose an installer that matches your operating system and processor. It is suited to managing subscriptions, reviewing connection logs, and adjusting routing in one place. For Android, consider v2rayNG with the Xray core; if you need V2Fly ecosystem configurations, evaluate v2flyNG. Choose based on the capabilities your nodes need, your system, and your preferred workflow—not just the interface or assumptions about performance based on a client’s name.

Before installing, check the protocols and security settings your node actually requires. A successful import does not mean the client recognized every extension field. Pay particular attention to REALITY, public keys, server names, fingerprints, and flow control. Confirm the target client and core requirements with your configuration provider, then compare them with the imported node’s edit screen. If the interface has no matching field, do not substitute an unrelated one or delete the field and try to use the node anyway.

Desktop installer type and processor architecture

The Windows download page offers Desktop and classic WPF editions. Desktop uses a newer cross-platform interface, while WPF retains the classic interface. Menus and workflows may differ. For your initial setup, choose one edition and establish a baseline; running both at once can cause conflicts over local ports. When migrating, check subscriptions, routing, and system proxy settings individually. Copying the program folder alone does not migrate all configuration.

For macOS, distinguish Apple Silicon from Intel. Check your device’s system information for the chip type, then choose the matching installer rather than guessing from the year you bought the machine. On Linux, match both the processor architecture and the package format used by your distribution, typically deb or rpm. Architecture and package format are separate requirements: a package manager accepting a file does not guarantee its executable will run on your processor.

The arm64 Android package suits most newer mainstream devices; the universal package is an option when the architecture is unclear or broader device compatibility is needed. Always check your system’s support. If installation fails, check the architecture, available storage, and signing relationship with an existing app instead of repeatedly downloading different files. If an update fails because of a signature conflict, export your settings and verify the backup before deciding whether to uninstall the old app.

Configuration Management Also Matters

If you use the same subscription on multiple devices, sync the subscription source and any required parameters; do not expect client databases to be portable across platforms. System proxies, virtual network interfaces, app exclusions, and file paths vary by platform. Custom scripts and paths that work on a desktop cannot be copied unchanged to a phone. When migrating, import the nodes and test one first, then recreate local proxy modes and routing. This helps avoid hidden dependencies on the old environment.

Client and core updates do not always happen together. An option in the interface does not mean the active core supports that behavior; conversely, the core may support fields the interface does not expose. For advanced features, read the current client’s settings documentation and check the runtime environment in the startup log. If in doubt, keep the default and use a verified protocol combination as your baseline. Do not switch programs frequently just to get a longer list of options.

Find platform-specific installers on the client download page, and compare the options in the client comparison. Before downloading, note your operating system, processor architecture, required core capabilities, and configuration source. Use the same checklist after installation. Switch clients only if the current one truly lacks a required capability. If the issue is a port, subscription, or system permission, switching clients is likely to repeat the same configuration error.

Installation and Baseline: Check Your Local Environment First

Record Your Environment Before Installing

Before installing, note whether your network is working, whether the system already has proxy settings, and whether other software is running virtual interfaces. Close old clients you do not need, but do not delete network adapters or change system services without a reason. Save the existing proxy address, port, and auto-configuration state so you can restore them if something goes wrong. On a managed device, confirm which installation and network settings are allowed; do not repeatedly escalate privileges to bypass restrictions.

Choose the right installer from the platform links on the download page, then launch only one client for the first run. The program, user configuration, and cache may be stored in separate directories. Find the actual data location before upgrading or moving the program. Do not place configuration containing subscriptions or identity information in a public shared folder. A desktop sync tool may upload the entire directory, including connection details intended to stay on your device.

First Launch and Permission Levels

On first launch, confirm the main window opens, then check whether the core starts. A standard local proxy usually does not require running the client with maximum privileges for everyday use. TUN and route changes may need separate permissions or a helper service. Grant permissions for specific features instead of assuming every startup failure is caused by insufficient access. When the system prompts you, read which capability is being requested and allow it only if it matches what you are doing.

On Windows, check whether another tool keeps overwriting the system proxy. On macOS, distinguish permission to launch an app from network-related permissions. On Linux, check that the graphical session, tray environment, and package dependencies meet requirements. These differences affect system integration, not the node fields themselves. If the main window works but the tray icon is missing, configure the client from the window first; do not mistake an interface integration issue for a remote connection failure.

On Android, the first connection usually requires VPN permission. Save the node before granting access, then check that the app is running. If another VPN session is active, the system may ask you to switch; confirm what each session is for before doing so. Note the background execution policy, but keep the app in the foreground for the first test to rule out battery management. Once the basic connection works, check lock-screen and background behavior.

Listener Addresses and Port Conflicts

Use a loopback address for local listeners so they accept requests only from the device. Consider listening on the LAN, with appropriate authentication and firewall limits, only when other devices need access. A local port identifies an inbound; it is not a copy of the remote server’s port, and the two can differ. If the log says an address is already in use, exit the other client or identify the process using it before changing the local listener port. Update any apps configured to use the old port.

{
  "inbounds": [
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

This is an inbound snippet, not a complete proxy configuration. It shows how the listening range, port, protocol, and tag relate; the client should generate the complete configuration, including the outbound. Do not enter an HTTP inbound in an app field that accepts only SOCKS, or assume adjacent port numbers are interchangeable. If an app has its own proxy settings, check the proxy type, address, and port together; all three must match.

To establish a baseline, leave complex routing, traffic probing, and TUN disabled. Check that the logs show no startup errors, then import one known-working node and test it with an app that follows the system proxy. Record the working settings and keep a way to restore them. If you need to change several options, note the reason for each in order. Otherwise, after an upgrade or migration, it will be hard to tell which settings are required and which were temporary troubleshooting changes.

Import Subscriptions: Sources, Formats, and Node Checks

Subscription URLs vs. Share Links

A subscription URL retrieves a set of node details; a share link usually describes a single node; native JSON describes a core configuration structure. They are not interchangeable. Pasting full JSON into a subscription URL field, or treating a share link as a subscription that can be refreshed, can cause import failures. Identify the content type first, then use the client’s subscription manager, clipboard import, or custom configuration entry point as appropriate. This prevents a format error from being mistaken for a network problem.

Subscription URLs often contain access credentials that can identify your account, so treat them as sensitive. Do not post the full URL in public screenshots, log discussions, or shared documents, and do not upload it to an unfamiliar conversion site. When asking for help, describe the protocol and where the error occurs, but hide identity fields, identifying parts of domain names, and query parameters. Encoded text may still reveal the original content; encoding is not access protection.

Create a Group and Run the First Update

Add a group in the client’s subscription manager, enter a recognizable name and source URL, then run an update. Menu labels vary, but the process is the same: save the source, then fetch and parse its contents. After updating, confirm the nodes appear in the expected group rather than relying on a success notification. If the group is empty, first check whether the source returned valid content, then review the parsing log. Do not immediately reinstall the client or change all network settings.

Updating a subscription and connecting through a proxy are separate network requests. An update may connect directly or use the current proxy, depending on client settings and the system environment. If updates depend on an active node that has stopped working, you can end up unable to fetch replacement nodes. Check which route the update uses, then adjust it under the available network conditions while keeping the existing group. Do not clear all nodes first; you will lose a useful reference for troubleshooting.

After parsing, open a node’s edit screen and check the server address, port, protocol, identity fields, transport, and security settings. The display name is only for identification and does not determine whether the connection works. Note that the server name may differ from the connection address, and that the transport path and request headers serve separate purposes. Do not delete fields just because they look redundant: some are used for network addressing, handshake verification, or application-layer requests.

Verify Imports and Understand Update Limits

Set one node as the active configuration, confirm the core restarts, then test with a fixed app and destination. A result in the client’s test list applies only to that test method; it does not cover every app’s behavior. If the client test succeeds but a browser fails, check the browser’s inbound. If startup itself reports an error, check field compatibility first. Observing imports, startup, and actual access separately makes issues easier to locate than repeatedly switching nodes.

A subscription update may overwrite node entries generated from the subscription. Before editing a node manually, find out which fields will be reset by the next update. For lasting customizations, use the client’s separate configuration or copy feature and give the copy a clear name. Keeping the original subscription entry separate from a local copy helps prevent accidental overwrites. Before deleting a group, check whether the active node belongs to it so an update does not leave your selection pointing to a missing entry.

Handle authentication failures, empty content, and unrecognized formats separately. For authentication failures, check the source credentials and account status. For empty content, check whether the response actually contains nodes. For format errors, confirm that the client supports the import type. A full configuration may also include local paths and specific outbound tags, so it cannot be reused like a single-node link. See Subscription Link Formats Explained for more on how the formats relate, then decide whether conversion is appropriate.

Proxy Modes: App Connectivity and Core Routing

System Proxy Does Not Capture All Traffic

A system proxy tells apps that support the mechanism which proxy address to use. Browsers usually follow it, but some programs have their own settings and others do not use the system proxy at all. If only some apps behave differently after enabling it, check how each app connects before switching nodes. Separately verify that the local proxy is running and that the system points to it: the core may work while the system still points to an old port, making everything appear broken.

A manual proxy lets you enter the local inbound directly in an app. This is useful for isolated testing or connecting just one app. The system proxy can remain unchanged, but the app’s protocol, address, and port must match the core listener. If the app has auto-configuration, proxy extensions, and manual settings, check which one takes precedence. For troubleshooting, temporarily use one clearly defined inbound to avoid layers of overrides making the interface disagree with actual behavior.

Separate Traffic Capture from Outbound Selection

Names such as Global, Rule, and Direct in a client usually describe outbound selection. System proxy and TUN primarily affect how apps send traffic to the client. These are two separate dimensions. Global mode does not make every app use the system proxy, and TUN capture does not mean every destination must go through a remote proxy. First decide which apps need to connect, then decide how their traffic should be routed. This prevents repeated routing changes when the real issue is the inbound.

For an initial test, use a simple proxy outbound policy so the connected test app can reach its destination through the selected node. Once that works, switch to your normal routing rules and compare the logs for the same destination. If the simple policy works but the rule-based one does not, check rule order, the default outbound, and DNS conditions. If both fail, go back to the node and inbound checks instead of adding rules to hide an unresolved connection problem.

Test with Real-World Actions

Keep the test app, destination, and active node fixed. Observe domain resolution, connection establishment, and whether the content actually loads. One page opening does not prove that other apps’ UDP requests or long-lived connections work. Likewise, one unreachable destination does not mean every connection has failed; compare it with a known-working destination. Change only the mode or the node at a time so you can link the result to a specific setting.

For desktop apps with built-in proxy settings, check whether they pass the domain to the proxy for resolution. Depending on the request format, the core may see a domain or only an already-resolved address, which affects domain rules. Do not change system-wide DNS just to make one app work. First check the app’s proxy and resolution behavior. If needed, use the client log to confirm whether the request reached the local inbound and whether the destination was recorded as a domain or address.

Test LAN access separately. Printers, file shares, and local services may rely on private addresses or local domain names. If routing sends these requests to a remote proxy, external sites may work while local resources fail. First confirm the resource works without the proxy, then configure direct access for the specific local range. Do not send every unknown address direct or use a broad rule to fix one device; that could change the expected route for other destinations.

Before exiting the client, restore or clear any system proxy settings it changed, then stop the core. This reduces the chance that the system will keep pointing to an inactive port. If the program exits unexpectedly, restart it and check the proxy state, restoring the previous settings in the system controls if needed. By the end of this chapter, you should be able to say whether an app is connected, which inbound it uses, and which outbound its traffic takes. If you cannot answer any of these, gather the missing information before enabling more complex traffic capture.

Routing: Match Order and DNS Conditions

Write Rules in an Order You Can Explain

Routing rules are generally checked in order, and the first match selects an outbound. Put specific exceptions before broad rules. Start by writing down the intended behavior: connect directly to local resources, send specified domains through a chosen outbound, and handle everything else with a default policy. Do not collect a large set of rules and guess what they will do. For each rule, be able to explain what it matches, which outbound it selects, and why it exists. If two rules cover the same destination, know why the earlier one should take precedence.

The configuration below is a complete direct-connection-only example for illustrating rule structure; it does not include a remote proxy node. The first rule handles private addresses, the second handles categorized domains, and the last provides a fallback for other requests entering this inbound. To set up real direct/proxy routing, have the client create a valid proxy outbound and point the relevant rules to its actual tag. Do not specify a proxy tag without defining the outbound, and do not assume tag names are identical across clients.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

Domain Strategy Is Not DNS Server Configuration

domainStrategy belongs in the routing object, not in an individual rule. It controls when domains are resolved during route matching so that address rules can be evaluated. AsIs keeps the original destination form. IPIfNonMatch tries address matching if domain matching finds no result. IPOnDemand may trigger resolution when a rule needs address information. The precise behavior depends on the active core and the full rule set.

Routing’s domain strategy does not independently specify which DNS server to query, and it is not the same as an app’s resolution settings. If an app has already resolved a domain to an address, the core may not be able to recover the original name. Conversely, if the core resolves a domain to evaluate an address rule, that does not mean the actual connection uses the same resolution path. When troubleshooting DNS, check separately who initiated the query, which route it took, what response it received, and the final connection target. Do not collapse these stages into one vague conclusion.

geosite and geoip rely on the corresponding data files and category definitions. If a category is missing or data fails to load, first check the data location used by the client, whether the files are present, and whether the core recognizes their format. Categories change and may not cover every new domain. For services that need predictable handling, add an explicit rule with a clearly scoped match. Record why each exception was added and review it periodically to prevent temporary rules from accumulating and masking one another.

Verify Rules in the Logs, Not Just in a Browser

Prepare separate tests for a local address, a known domain, and a destination that should not match any rule. Check which outbound tag each request selects. A webpage often requests several domains, and different resources may match different rules; a page loading does not prove all requests took the same route. To isolate a rule, first test a clearly scoped destination, then return to the full page. Comparing logs before and after a rule change reveals more than comparing perceived speed.

Check the fallback behavior too. Some core configurations use the first outbound in the list when no rule matches, while a client may generate an additional fallback rule. The order in the editor may not match the final configuration, especially when presets are enabled, so check the generated result. Do not reorder every outbound to change the default route. Use the client’s default policy setting where possible, then confirm the behavior after restarting.

If the configuration behaves unexpectedly, return to a minimal rule set: keep the rules needed for local resources and one explicit fallback, then add exceptions one at a time. If the issue returns after adding a rule, focus on its match conditions and position. For combinations of domain categories, address categories, and default proxy outbounds, see Practical Guide to V2Ray Routing Rules. Before expanding the rule set, make sure each layer can be observed and rolled back.

TUN and Multiple Platforms: Traffic Capture and Recovery

Confirm You Need TUN Before Enabling It

TUN uses a virtual network interface to handle traffic routed to it by the system. It can help with apps that cannot use proxy settings directly, but it adds dependencies between the interface, routes, DNS, and permissions. Do not use it as the default troubleshooting step for a first connection. First verify the node through a standard inbound, then decide which apps actually need traffic capture. If the original issue is a wrong system proxy port, TUN will add variables without fixing it.

Before enabling TUN, record the current default network, DNS settings, and purpose of any other virtual interfaces, then close similar traffic-capture tools you do not need. Multiple programs trying to change the default route can overwrite one another or create a loop. If they must coexist, define which handles the inbound, which handles DNS, and which destinations bypass capture. If responsibilities are unclear, run one program independently and verify it before evaluating coexistence.

Permissions, Routing, and Connection Loops

Desktop environments may require administrator privileges, a helper service, or a virtual interface component, depending on the client and system. If setup fails, check the stage reported in the log: interface creation failures point to permissions or components; route write failures point to permissions or conflicts; an interface that exists but carries no traffic calls for checking routes and exclusions. Do not repeatedly reinstall because one permission prompt was missed, and do not enable multiple related options at once to mask the error.

Traffic from the proxy core to the remote server must not be sent back into the inbound indefinitely by the client’s own capture rules. Clients usually handle the necessary bypasses, but custom routing, interface binding, and other network tools can disrupt them. If the standard proxy works but connections time out as soon as TUN is enabled, first check for loops and the routes used to reach the outbound network and remote address. Do not route all traffic directly as a test; that changes both the test conditions and what TUN captures.

Test DNS and LAN Access Separately

After TUN is active, verify the path taken by DNS queries. Depending on the environment, system queries may be captured or may rely on a specific DNS mode or client setting. If a known IP address is reachable but domain names do not resolve, investigate name resolution first rather than ruling out the remote node. If synthetic addresses are enabled, check that mappings, domain exclusions, and routing work together. Do not mistake an address returned by this mechanism for the destination server’s real address and reuse it in other rules.

Check LAN devices, local services, and remote management connections separately. Before enabling traffic capture, save any essential work and make sure you have a local recovery path. Do not test settings that may change the default route over your only remote connection. Configure private-address bypasses to match your actual network, rather than copying someone else’s exclusion list. Test both external destinations and local shares, device management pages, and system network functions you need to keep.

What to Check on Android vs. Desktop

Android clients usually capture app traffic through the system VPN interface, which does not map one-to-one to a desktop TUN switch. Focus on system permission, per-app selection, and background restrictions. If you use app scoping, confirm whether the setting includes only the selected apps or excludes them. Save the setting, reconnect, and test. Do not infer the meaning from checkmarks alone; check the description and verify actual requests in the logs.

If connections drop after the screen locks, compare foreground and background behavior first, then check battery management, background restrictions, and network changes before switching nodes. On desktop, moving from wired to wireless or resuming from sleep may also require rebuilding the virtual interface and routes. Test one environmental change at a time and record whether the connection recovers. If the issue occurs only after switching networks, focus on interface state and outbound network changes instead of repeatedly editing authentication fields you have already verified.

Routine Maintenance: Backups, Updates, and Troubleshooting

Keep a Recoverable Configuration Baseline

Routine maintenance starts with keeping a working configuration you can understand, not adding more settings. A backup should cover subscription groups, manual nodes, custom routing, DNS choices, and essential interface preferences. Record which parts the client generates automatically. Exports may contain access credentials, so store them somewhere controlled and limit sharing. After backing up, confirm you can identify the format and the clients it applies to. Do not count a file you cannot restore as a reliable backup.

Before updating, record the current working state and key settings, then close important connections before updating the client or related components. Afterward, repeat the same basic tests to confirm startup, subscriptions, inbounds, and routing still work before enabling new features. If the interface changes and you cannot find a menu, check whether the settings have been reorganized rather than re-entering every parameter. If an update causes a problem, keep the logs and configuration differences, then use your prepared recovery method.

Read Logs by Failure Stage

Troubleshooting starts with the sequence of events: Did the program start? Was the configuration generated? Is the core running? Did the request arrive? Was a remote connection established? Did the destination return content? The earliest relevant error in the log is usually more useful than later errors caused by it. Keep the surrounding context rather than copying just one red word. If you need more detailed logs, enable them only while reproducing the issue, then return to the normal level. This also limits the accumulation of sensitive request data.

If the core will not start, check JSON syntax, field placement, outbound tags, data files, and local ports first. Network traffic has not reached its normal processing stage, so switching remote nodes may not help. For a port conflict, identify the local process using it. For missing category files, check the data path. For unsupported fields, verify core capabilities. See Troubleshooting V2Ray Core Startup Failures for more log patterns. Fix one confirmed error at a time, then restart and check again.

Troubleshoot Slow Speeds in Layers

If a connection works but feels slow, distinguish node load, the network path, and local settings. Keep the app and destination fixed, compare nodes under similar conditions, then check whether the issue occurs only at certain times or on certain networks. Do not change the node, transport settings, and DNS all at once; even if performance improves, you will not know why. A test result applies only to the method and conditions used and is not a long-term measure of every app’s performance.

On the local device, first check other downloads, resource usage, and duplicate proxies, then consider advanced options such as connection reuse. Reuse is not always better for every protocol or app, and enabling it blindly may change how a problem appears. For a detailed three-layer troubleshooting sequence, see How to Troubleshoot Slow Connections in Layers. There is no need to test every node repeatedly. Keep your everyday setup stable and run targeted comparisons when a specific issue arises.

When sharing troubleshooting details, include the client name, operating system, failure stage, and a redacted error message. Remove subscription URLs, identity information, and unnecessary access logs. Screenshots may also reveal group names, server addresses, or account details, so review them before sending. A timeout message alone is hard to diagnose without knowing the inbound and mode. A short, well-structured reproduction is more useful than a large set of unsorted screenshots.

A plain-text maintenance log is enough: note what changed, why, the test destination, the result, and how to roll back. Remove temporary settings when they are no longer needed so you do not end up relying on exceptions no one understands years later. Periodically check that subscription groups are still in use, backups still work, and system proxy settings match the current client. The goal is to keep issues easy to isolate and changes easy to explain—not to keep adding settings.

Advanced Topics: Add Complexity to Solve Specific Problems

From a Working Connection to a Verifiable Configuration

After completing the earlier chapters, build your advanced skills around real requirements. For precise control over traffic paths, study routing and DNS. For managing multiple devices, learn the limits of configuration migration. For unusual protocol parameters, first check core support. Turning on every advanced option at once is not a measure of progress. A simple configuration where each rule has a clear purpose, tests are repeatable, and changes can be rolled back is easier to maintain than a collection of unverified settings.

For each experiment, record four things: the current baseline, the hypothesis to test, the single change, and the expected result. For example, to check whether a domain rule takes priority, leave the node and inbound unchanged, add one clearly scoped rule, and inspect the outbound in the logs. If the result differs from expectations, explain the discrepancy before making another change. This turns learning into a repeatable experiment and prevents crediting one of several simultaneous changes for a successful outcome.

Protocol Capabilities and Core Differences

When exploring VLESS, XTLS Vision, or REALITY, first understand which layer each parameter belongs to, then check support in the client and active core. Do not swap fields such as server address, server name, flow control, public key, and short ID just because their names seem similar. Protocol names alone do not determine whether a node will work; the transport combination and server configuration matter too. If an existing service works, do not rewrite all its verified settings just to try a new feature.

For more on the relationship and capability differences between V2Fly and Xray, see Comparing the Features of the Two Cores. The goal is not to rank cores broadly, but to identify which component implements a feature, how the configuration differs, and how the current client exposes it. Before switching cores, prepare a compatibility checklist. After switching, retest startup, handshakes, routing, and DNS; success with the old core does not guarantee the new setup will work.

Where Custom Configuration Ends and the GUI Begins

Before using custom JSON, determine whether it replaces the full graphical configuration or merges only a section. Different entry points may handle it differently, and duplicate inbounds, outbounds, or tags can conflict. Learn the structure with a minimal direct-connection example, then add your own valid nodes and rules one at a time. Do not import a full configuration containing someone else’s local paths and specific tags. If you cannot confirm the merge order, do not maintain two overlapping sets of settings at once.

A configuration generated by the graphical interface is useful for inspecting the final result, but may not be a suitable place for permanent manual edits. The client may regenerate the file and overwrite changes the next time you save or switch nodes. Put persistent advanced settings in an entry point the client explicitly supports. If there is no such entry point, assess the maintenance cost instead of relying on manual edits after every launch. Track how source data, generation, and the final configuration relate so you can tell whether an edit was saved and actually took effect.

Build a Small Regression Test

As a configuration grows, keep a fixed set of checks: a regular domain is reachable, local resources still connect directly, a specified rule selects the expected outbound, unmatched destinations use the right fallback, and the connection recovers after sleep or a network change. Run the same checks after every update or routing change. You do not need to test every website. A small set that represents your key use cases and points to a module when something fails is already useful.

Automation should come after the workflow is stable. Scheduled subscription updates, automatic startup, and background traffic capture reduce repetitive work, but can also change nodes or system state when no one is watching. Before enabling them, check what happens on failure: Does an unsuccessful update keep the old content? Does startup overwrite the system proxy? Can the system recover after an unexpected exit? Complete the full process manually and test the recovery path first. Otherwise, an unresolved problem may become a recurring background failure.

The goal of this guide is a repeatable troubleshooting sequence: check the environment, verify the inbound, confirm the node, inspect routing, check resolution, then evaluate traffic capture and advanced settings. To rebuild a minimal connection, return to Quick Start. For installers for another device, visit the client download page. For more examples, browse the relevant topics in Guides and Tips. Make each new setting address a specific problem and record how you verified it to keep the configuration maintainable.