v2rayN Setup GuideFrom First Connection to Advanced Setup

1. Core Concepts: Map the Traffic Flow

What the client, core and server each do

Start by separating the graphical interface from the program that handles the connection. v2rayN stores server details, manages subscriptions, selects routes and launches the core. The core listens on local ports, parses its configuration and establishes connections. An open interface does not mean the core started successfully. If a connection fails, check the startup logs first instead of repeatedly changing browser settings. Configuration errors, port conflicts and missing components can leave the interface working while the proxy listener never starts.

Project V provides the broader ecosystem behind these proxy technologies. V2Fly and Xray are distinct core families within it. Protocol support, configuration fields and feature behavior can vary by core; similar names do not guarantee identical behavior. A graphical client typically turns interface settings into a core configuration. You do not need to write a complete configuration file by hand to get started, but you should know which core is in use. When reading documentation, check client settings and core parameters separately rather than pasting fields from a different implementation.

Server details describe the remote endpoint: its address, port, credentials, protocol and transport settings. The client does not provide these details, and installing it does not automatically give you access to a remote service. A share link usually contains the fields for one connection; a subscription URL retrieves and refreshes a set of entries. Both may contain sensitive information. Posting a subscription URL publicly can expose access to the service. Before sharing a screenshot, hide credentials and the full URL.

Follow the traffic from the app to the outbound connection

A typical connection works like this: an app sends traffic to a local proxy listener, the core selects an outbound route based on its rules, then connects to a remote server or directly to the destination. “Inbound” means how traffic enters the local core; “outbound” means how the core connects onward. A direct connection is still an outbound route, not a bypass of all processing. A local source address in the logs is not the remote server address. Likewise, seeing a destination domain does not prove it was resolved by the DNS server you expected.

System proxy settings tell apps that honor them where to send traffic. TUN uses a virtual network interface to capture traffic that matches the system routes. Routing rules decide what happens after traffic reaches the core; they do not determine how it gets there. If an app ignores the system proxy, changing a “bypass mainland China” routing rule will not make its traffic enter the proxy listener. Troubleshoot in order: first ask whether the connection reached the core, then which outbound route the core selected. Reversing that order can lead to the wrong diagnosis.

Keep protocol, transport and encryption separate

VMess, VLESS and Trojan are protocol names. TCP, WebSocket and gRPC describe transport methods, while TLS and related security settings are another layer. After importing an entry, check that these fields work together rather than assuming entries with the same protocol are interchangeable. For example, if the server requires a particular path or service name and the client is missing it, authentication can fail even when the credentials are correct. Do not replace server-provided transport settings based on guesswork.

DNS is part of the connection path too. An app may resolve a domain to an address first, or pass the domain to the proxy for remote resolution; the behavior depends on the app and proxy protocol. Whether a rule can match a domain depends on what information the core actually receives. “The website won’t load” alone does not tell you whether DNS, authentication or routing failed. Note the destination type, how the app connects and the error stage shown in the logs so each troubleshooting step has a clear target.

2. Client Comparison: Choose by Device and Core

Start with v2rayN on desktop

For desktop use, start with v2rayN. Check your operating system first, then your processor architecture, and finally the right installation format. The Windows desktop release uses a cross-platform interface, while the classic WPF release has a different desktop interface; neither uses a different proxy protocol. For a first install, follow the download page and choose one. If your current setup is stable, there is no need to switch just for a different interface. Running both clients at once while troubleshooting can cause conflicts over listening ports and system proxy settings.

For macOS, identify whether your Mac uses Apple Silicon or Intel rather than guessing from its appearance. Check About This Mac for the chip information, then download the matching build. On Linux, check both your distribution’s package format and your processor architecture. Whether you need a deb or rpm package depends on the distribution, not personal preference. An architecture mismatch or missing dependency is an installation issue, before the connection stage; changing subscriptions or server parameters is unlikely to help.

When choosing a client, consider whether your apps only need browser proxying, whether you need to capture apps that ignore the system proxy, and whether you have permission to install a virtual network interface. Start with the fewest features that meet your needs, then add advanced settings as needed. The presence of a toggle does not guarantee it will work on your device: operating system permissions, core support and network conditions all affect the result.

For Android, start with v2rayNG; choose v2flyNG when needed

For Android, v2rayNG is the usual first choice and uses the Xray core. v2flyNG uses the V2Fly core and is suited to cases that specifically require its behavior. Check the protocols and transport combinations each app supports; a successful import does not guarantee a connection. Most newer phones use arm64, but the phone’s age is not a reliable way to identify its architecture. If you are unsure, check the device information and download page before choosing an architecture-specific or universal package.

On mobile, the app uses the system VPN interface to create a local traffic-capture tunnel. A system confirmation prompt the first time you connect is a normal part of the permission flow. Another service using that interface may prevent both from running at once. An app showing that it has started only confirms the local service is running; it does not prove the remote connection or destination access works. Verify both with logs, an actual app request and the resulting routing behavior.

Check compatibility before switching

When switching clients, transfer the subscription URL or standard share links first rather than copying the entire application folder. Interface settings, routing templates and local database formats may not be compatible. Even when two clients support the same protocol, they may recognize different extension parameters. After switching, select one known-good entry, keep its transport settings unchanged and test basic access. Then restore your custom rules and per-app routing.

Check whether the subscription contains standard share links or a complete configuration intended for a specific app. A complete configuration may include proprietary fields, scripts or templates; changing its file extension does not make it a standard subscription. If the format is unsupported, ask the provider what format it exports instead of converting it at random. The best client is not the one with the most features, but the one that works reliably with your connection details, device permissions and maintenance needs.

By the end of this chapter, you should be able to name your device’s operating system, processor architecture, client and core. Keep these details in your troubleshooting notes so you can follow the right platform documentation later. For a side-by-side look at three clients, see the client comparison. Get installers from the download center, not from an overview article that may not list specific files.

3. Installation and First Launch: Check the Local Service

Install the app and complete its first launch

Before downloading, check your operating system and architecture. After installation, start with the default settings. If you downloaded an installer, follow its prompts to choose a location and complete setup. If you downloaded an archive, extract all its contents to a fixed, writable folder before launching the main program. Do not run it from an archive preview or extract only the executable. The core, resources and configuration may be in neighboring folders; without them, the interface can open while background components fail.

Choose an application folder that is easy to back up, not a temporary download cache or a location that gets cleaned automatically. If you sync configuration across devices, avoid letting the sync tool modify a live database. If the system says the folder is not writable, check its permissions and location rather than disabling all security features. Use a standard user account for routine startup; grant elevated permissions only when a feature, such as a virtual network interface, specifically requires them.

On macOS, install according to the download format and check for trusted-source prompts under Privacy & Security. On Linux, use the installation method for your distribution and read the package manager output if dependencies are missing. Do not apply instructions from one distribution to another without checking. After the first launch, confirm that the app closes and restarts normally and that settings are saved. This can reveal a read-only folder, incomplete installation or missing runtime before you start troubleshooting subscriptions.

Check ports, the core and logs

Check the local listener details in v2rayN settings and runtime logs. Common defaults are SOCKS port 10808 and HTTP port 10809, but releases and existing configurations may use different ports or a mixed listener. Trust the current interface and startup logs, not a number copied from a guide. The remote server port comes from your connection details; it is not the same as a local listening port, and changing one does not update the other.

If the logs report that an address is already in use, check whether another client instance or local service is running. Close duplicate instances and try again, or set a non-conflicting listener port and update the app’s proxy settings to match. Do not just hide the error. Without a working listener, a browser pointed at the local address still cannot connect. Changing servers will not help because traffic has not yet left the local proxy entry point.

Keep the initial setup minimal

For your first setup, leave TUN, LAN sharing and custom routing disabled. Keep only the local listener and one connection entry. This limits the variables to core startup, authentication and remote reachability. Add features one at a time after the basic connection works. If you start by importing a large rule set, changing DNS and enabling multiple traffic-capture methods, a failure will be much harder to trace to the layer that caused it.

On Android, open the app after installation to complete setup, import one entry, then start the connection and approve the system prompt. Do not keep tapping the connect button instead of waiting for the logs. If the connection stops after switching apps, check background activity and battery settings, but change them only when necessary. Background restrictions, system permissions and remote authentication are separate layers; record them separately rather than calling everything a “node failure.”

Initialization is complete when settings save, the core starts, the local listener has no port conflict and you know where to find the logs. You do not need every app to use the proxy yet. Record the listener address, port and default routing profile as your baseline. If a later change fails, return to that baseline first. If the baseline will not start, check the application files and system environment. For common startup errors, see the FAQ.

4. Subscriptions: Add, Update and Manage Entries

Identify the input before choosing an import option

First identify what you have: a subscription URL, a single share link or a complete configuration. A subscription URL is a network address used to retrieve content. A share link uses a protocol-specific prefix to represent one entry. A complete configuration contains structures such as inbounds, outbounds or routing rules. Do not paste all three into the same field. Watch for spaces, line breaks and punctuation added by chat apps. A long link split across lines may look complete while missing fields.

To manage subscriptions in v2rayN, open “Subscription Groups,” add a group, enter a recognizable name and subscription URL, then save and choose “Update All Subscriptions” or update the relevant group. Saving the URL and fetching its contents are separate steps. An empty list immediately after saving does not mean the URL is invalid. First confirm that you ran an update, then check the logs to see whether content was retrieved. Keeping different providers in separate groups makes updates and retention easier to manage.

To import a single share link, use “Import share links from clipboard”; desktop versions that support it may also accept Ctrl+V. After importing, open the entry and check the protocol, address, port and transport. Seeing an entry name in the list does not mean every parameter was recognized. For links with extra transport options, verify the security settings, server name, path or service name against the original details. Do not fill in blank values with common examples just to make them look complete.

Separate subscription fetch errors from parsing errors

Subscription updates have two main stages: reaching the URL and parsing the response. Timeouts, certificate errors and DNS failures occur during retrieval. If the URL is reachable but the format is unsupported, the problem is with parsing the content. A login page, expired-link notice or ordinary webpage is not a valid subscription, even if the server returned a success status. If the logs show only a brief error, check where the URL came from and whether it is still valid. Do not send the full URL to people who do not need it.

Some interfaces let you choose between direct updates and updates through a proxy. Proxy updates only help if a working proxy is already available. On a fresh install with no working connection, relying on that connection to fetch a subscription creates a loop. Use an access method supported by the provider, or import a valid share link first to establish a basic connection. After changing the update method, retry one group at a time so concurrent requests do not obscure the cause.

Entries in a subscription may be added, removed or renamed during an update, and local edits may be overwritten at the next refresh. Manage important custom entries separately and check whether the client offers a way to preserve or copy them. Do not rely on editing generated subscription entries as a long-term solution. Before deleting a group, check whether its entries will be removed too. Clearing the list is not necessary to fix an update failure; keeping working entries makes recovery easier.

Verify imported entries and protect sensitive details

v2rayNG and v2flyNG on Android follow the same basic flow: save a subscription URL, then update its contents. Use the app’s current menu to find the relevant options. After importing, select an entry, connect and check the runtime logs. List order, speed-test results and the currently selected entry are separate things; the first entry is not necessarily the one in use. After switching entries, check that the connection service applied the new settings and restart it using the app’s controls if needed.

For verification, start with one entry from a known source with complete parameters. Do not import several sources at once and guess which one is active from its name. If a connection fails, record the error stage without sharing credentials. A subscription URL may contain an access token, a share link may include an identity, and an exported configuration may contain server credentials. Treat backups as sensitive too; a text file does not belong in a public folder or an unreviewed sync location.

5. Proxy Modes: Check How Apps Reach the Core

Three system proxy options are not three routing modes

On desktop, start by using the system proxy to test a basic connection. v2rayN’s “Set system proxy” writes the local proxy listener to the relevant system settings for apps that honor them. “Clear system proxy” removes those settings. “Do not change system proxy” leaves the existing settings untouched. It does not restore defaults or guarantee a direct connection. If another program set a proxy earlier, its settings may remain in place.

System proxy settings and routing choices such as “Global” or “Bypass mainland China” belong to separate layers. The system proxy determines whether an app sends traffic to the local listener; routing determines which outbound the core uses after traffic arrives. Setting routing to Global does not capture every app. If a browser works but another app does not, first check whether that app reads the system proxy or has its own network settings. Do not start by changing the protocol or rebuilding the entire subscription.

Some apps read the system proxy only at startup, so you may need to fully quit and reopen them after changing it. Existing long-lived connections may not switch paths immediately either. To test a change, close the relevant connections or restart the app, then make a new request. Do not treat an old tab still showing content as proof the connection works; the page may be cached. An existing connection can also survive after the new settings have taken effect.

For manual proxy settings, match the protocol and listener

If an app has its own proxy settings, enter the local address and actual listening port. When the app and client run on the same device, the loopback address is usually 127.0.0.1. The proxy type must match the listener: HTTP and SOCKS are not interchangeable just because both use a port. If the current core provides a mixed listener, check which protocols it supports. If HTTP and SOCKS listen separately, enter the port for the matching protocol.

An app’s “remote DNS” option or equivalent controls whether the local machine or the proxy path resolves domain names. If the app has no such option, do not assume where resolution happens. If domains fail but direct address tests behave differently, note the app protocol and DNS behavior, then investigate DNS. Testing a website by IP address has limits: HTTPS certificates and virtual hosts may depend on the domain, so a failure does not automatically mean the network is down.

Verify connections and exit cleanly

To test, make a new request in a regular browser and check the client logs at the same time. Confirm that a new connection reaches the core, then look for authentication, transport handshake or destination connection errors. Browser extensions, proxy add-ons and in-app settings can override the system proxy; use one clearly defined entry method during testing. If the logs show no corresponding activity, check how the app reaches the proxy before assuming the remote server is at fault.

Before closing the client, clear the system proxy it set, then exit normally. If the app closes unexpectedly while the system still points to its stopped local port, apps that honor the system proxy will keep failing to connect. To restore service, reopen the client and clear the setting, or check the proxy address in your system network settings. Do not erase existing corporate proxy settings without understanding them. Record the original values so you can restore them after testing.

Android typically does not use the desktop system proxy options. It captures traffic through a VPN interface created by the app, so check per-app routing and bypass settings in the client. By the end of this chapter, you should be able to say whether your test app uses the system proxy, its own proxy or a virtual interface. If you are unsure, go back and check the entry point. You need to understand that before routing order and direct-connection rules can be tested reliably.

6. Routing and DNS: Keep Rules and Resolution Aligned

Start with a built-in profile, then add exceptions

For your first routing setup, start with a profile built into the client and add only the exceptions you actually need. “Bypass mainland China” generally sends matching domains or addresses directly and routes other connections according to the profile, but rule sets and templates can work differently. After selecting one, read its notes and check the logs to confirm how local services, destinations in mainland China and other destinations are routed. A profile name in the interface confirms that it was selected, not that every domain was categorized correctly.

Rule order matters. In a first-match rule list, an earlier match can prevent later rules from taking effect, so specific exceptions usually belong before broad rules. When adding a rule, check both its match conditions and its outbound tag. A correct domain will not work if the tag does not exist; a valid tag will not help if an earlier broad rule catches the traffic first. Add one target at a time, save and apply the change, then make a new connection and check which rule matched before expanding the list.

The Xray-style routing snippet below shows a complete match for a reserved test domain. It is not a standalone configuration file; it requires an outbound named direct. full: matches an exact domain, while domain: matches the domain and its subdomains. Do not treat the example domain as a list of real services, or paste a routing object into the graphical interface’s share-link import field.

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

DNS affects reachability and rule matching

Start DNS setup by deciding who resolves which domains. A resolver reachable over the local network may work for some direct destinations, while others may need to reach a resolver through a specific route. The question is not just which server address to enter, but how the DNS request reaches it. If accessing the resolver depends on a proxy, while the proxy server’s address is waiting on that same resolver, you can create a startup dependency loop. First make sure the server address can be resolved, then handle destination domains separately.

The domain-resolution strategy used by routing rules is not the same setting as the DNS module’s query strategy. The first determines whether a domain needs to be resolved to an address for routing decisions; the second affects behavior such as which address types to query. The DNS snippet below only demonstrates syntax for assigning a server by domain and restricting query types. It is not a recommended setup for every network. Before using it, confirm that the resolver is reachable and check the outbound path for DNS traffic in the full configuration. Copying a snippet does not prove DNS is being intercepted.

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["full:example.com"]
      }
    ],
    "queryStrategy": "UseIPv4"
  }
}

Check IPv6 separately. An app may prefer IPv6 addresses, and a proxy or direct route tested only over IPv4 can fail intermittently or take a long time before working. Check system addresses, DNS results, outbound support and rule coverage independently. Disabling an address family is not a permanent fix for every situation. Temporarily restricting query types may help diagnose the issue, but note why you did it and reassess later so you do not mask a fixable network or routing problem.

Test rules with specific destinations

Choose one destination that should connect directly and another that should use the proxy. Make a new request to each and check the logs. Browser, connection and system DNS caches may preserve old results, so reopen the app or wait for the relevant caches to expire if needed. Do not clear the entire configuration just to test one rule. If only a subdomain fails, check the exact-match and suffix-match scope before rerouting an entire domain category.

Domain sniffing can sometimes help when an app provides only an address, but it is not a universal protocol detector and cannot guarantee recovery of the original domain. For LAN services, preserve local DNS resolution and access to private addresses too. The more rules you add, the more important it is to record their source, purpose and priority. For a fuller explanation of the fields, see the DNS routing and resolution guide. Start with a small set of rules you can verify.

7. TUN Mode: Capture More Than Proxy-Aware Apps

Make sure you actually need TUN

Consider TUN when an app ignores the system proxy or you want to handle more connections through a consistent network path. TUN captures traffic through a virtual network interface and system routes; it is not a speed boost for the remote server. First confirm that the regular local proxy works. Then, if you enable TUN, the new troubleshooting scope is limited to permissions, the interface, routing and DNS. If the basic connection already fails, TUN usually adds more variables without solving the underlying problem.

The “Enable Tun” option in v2rayN may depend on the selected core component and client configuration. Do not assume that a standard Xray inbound snippet is a universal TUN setup. First check in the interface that the required components are available, then grant permissions as prompted. If the system asks for authorization, make sure the prompt comes from the client you are using. If startup fails, check the logs for interface creation, route setup or permission errors instead of repeatedly installing unrelated components.

TUN capture does not guarantee that every protocol will work. An app’s use of UDP, server support, network paths and the current core’s forwarding capabilities can all affect the result. If websites load but a real-time app fails, investigate the protocol that app actually uses rather than relying on a browser test. Note whether the issue is limited to UDP or a particular destination. That is more useful than simply saying “it stops working when enabled.”

Avoid routing loops and DNS dependencies

Before enabling TUN, stop other services that change the default route or use a virtual interface, and note the current network state. The proxy process still needs to reach its remote server through the underlying network. Otherwise, its connection may be routed back into the virtual interface, creating a loop. The client usually handles the required exclusions, but complex multi-adapter, corporate or static-route setups may need additional checks. Do not delete system routes without evidence in the logs.

DNS is another common complication. TUN can capture network traffic, but the system, apps and core may each maintain their own DNS cache, and some apps use their own resolution mechanism. Check where system queries go, how the core handles them and which outbound route reaches the resolver. If you use a fake-IP mapping feature, make sure the correct interface handles its address range. After disabling it, stale DNS results may remain until you reconnect the app or the cache refreshes.

Test LAN access separately. Printers, file shares and local admin pages often use private addresses or local domain names. Broad rules can capture them by mistake, leaving internal services unreachable even when external websites work. Check how private subnets and local DNS are handled before adding exclusions. LAN proxy sharing and TUN solve different problems: enabling TUN does not automatically expose the local listener to other devices. Do not enable sharing just to fix local access.

Enable TUN and test rollback in stages

Test in three stages: first make a new browser connection, then test an app that ignores the system proxy, and finally check LAN services and recovery from sleep. Watch the logs and app behavior at each stage. Running the system proxy and TUN together makes the traffic path harder to follow. For an initial test, you can temporarily clear the system proxy and test only TUN, provided doing so will not disrupt your existing setup. Decide on a day-to-day combination after you have verified each path.

If all network access stops, disable TUN and exit the client normally, then check whether the default connection works again. If not, look for leftover system proxy settings, a virtual interface or changed DNS settings rather than stacking another proxy service on top. Sleep, network changes and adapter reconnects can alter the underlying interface, so test again after recovery. Before relying on TUN, test at least one transition from wired to wireless or a disconnect and reconnect to confirm it works beyond the first startup.

8. Maintenance: Backups, Updates and Troubleshooting Notes

Save a state you can restore

Once connections, routing and app capture are stable, save a configuration baseline. Record the client, core, local ports, routing profile, DNS changes and TUN status. Export options and configuration folder locations vary by installation type, so use the client’s backup feature when available and check exactly what it includes. A subscription URL alone cannot restore local rules, and screenshots cannot restore credentials. Neither replaces a complete recovery plan.

Back up after the client has saved its settings. If needed, exit normally first to avoid copying a database while it is being written. You can include the purpose and backup date in the filename, but never put a subscription token there. Test your recovery process too: find the import option, understand what it will overwrite and know how to preserve the old configuration. An untested backup only proves the file exists; it does not prove you can restore the same behavior after reinstalling.

Treat subscription URLs, share links and exported files as sensitive information. When asking for troubleshooting help, keep the error type and relevant field names but hide identity details, full server credentials and private addresses. Logs may also include destinations and subscription requests, so do not publish them unreviewed. If someone needs to inspect a format, share only a sanitized structural example and state which values you replaced instead of exposing real connection details.

Update one layer at a time

Client, core, subscription and rule-data updates are separate operations. A client update may change menus and how configurations are generated; a core update may change supported fields; a subscription update mainly changes remote entries. In a stable setup, update each separately, back up first and repeat the basic tests afterward. Changing everything at once makes failures harder to trace. Do not replace a running application just to keep up with releases if you are not ready to recover the setup.

Before updating the client, exit normally and make sure no background process is using its files. Follow the steps for your installation type. If you have multiple installation folders, check which copy you actually launch; an old shortcut may still open an older configuration. After updating, check the logs first, then test the system proxy, routing and TUN. If settings have moved, read the interface notes and verify your custom values rather than assuming a changed default means the remote server is at fault.

Rule data can become outdated too. Changes to domain categories or address lists can alter which rules match, but do not replace every rule with data from an unknown source just because one destination behaves differently. First check which rule matched, then determine whether the category, DNS result or destination itself changed. Remove exceptions you no longer need, and note why before deleting them. This prevents rules from accumulating until no one can explain their priority.

Trace the connection path instead of reinstalling repeatedly

At a minimum, record when the issue occurred, which app was affected, the entry method, selected connection, error message and most recent change. First determine whether every destination fails or just one, and whether every app is affected or just one. For a system-wide failure, start with core startup, the local entry point and basic network access. For a single destination, check the domain, routing and destination service. Narrowing the scope produces more repeatable results than repeatedly switching entries.

Increase the log level temporarily only when necessary. Restore the usual level after troubleshooting to keep logs readable and avoid retaining sensitive destination history. For authentication errors, check the connection details and system time. For handshake errors, check security and transport parameters. For connection refusals, check the address, port and service availability. A timeout alone says little; use the stage where it occurred to determine whether the issue is more likely local or server-side.

9. Advanced Setup: Make Configuration Changes Testable

Start by reading the generated configuration

Advanced setup does not mean abandoning the graphical interface. First see which inbounds, outbounds and rules the client generates from your current settings, then learn how they map to the interface. Generated files may be overwritten the next time settings are applied, so they are not a reliable place for permanent edits. For custom changes, use a method the client explicitly supports and check whether it adds fields, replaces part of the configuration or takes over the entire file. These modes have different scopes; the fact that each editor accepts text does not make them interchangeable.

Read a configuration in a consistent order: first check which address and port each inbound listens on, then review outbound tags and protocols, and finally see how routing refers to those tags. Next check DNS, logging and other supporting modules. Start with the path of one real connection; you do not need to understand every field at once. A missing parameter may rely on a core default or be handled by another component, so its absence does not automatically mean the feature is disabled.

The complete minimal Xray configuration below illustrates the structure. It provides a local SOCKS listener and a direct outbound, with no remote proxy. It shows how inbound tags, routing references and outbounds relate, but should not replace a full proxy setup. Before running it, check that the port is available and use a custom configuration entry point supported by the client. With this example, traffic still goes directly through the local network; that is the expected behavior.

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

Give each experiment one clear question

A useful experiment has a clear question, one change and an observable result. For example, to check whether a domain uses a direct route, keep the client and connection entry fixed, change one domain rule and observe the outbound selected for a new connection. Do not change DNS, enable sniffing and alter the transport at the same time. If the test fails, restore the original value and confirm the baseline still works before testing another explanation. This builds an understanding of cause and effect, not a complex configuration that happens to work.

A practical learning sequence is rule matching, domain resolution, app capture and LAN sharing. Verify each feature on one device before expanding to more. For example, allowing LAN connections requires checking the listener address, firewall and network the client is on; flipping a toggle is not enough. Other devices need the computer’s LAN address, not their own loopback address. If the computer’s address changes, update the settings on the devices that use it.

LAN sharing also creates an access boundary. Open only the ports you need on a trusted network, and do not expose an unauthenticated listener to untrusted networks. Keep firewall restrictions in place and check what happens after sleep, disconnection or an address change. Turn sharing off when you do not need it. For detailed steps, read the guide to allowing LAN connections. Understand the listener’s scope before deciding to leave it enabled.

Understand protocol differences and keep a way back

Learn protocols by examining the actual fields and the stage where a connection fails. VMess and VLESS differ in authentication, time requirements and security options; changing the protocol name does not convert a connection. Transport, security and server parameters must all match. Understand the details you already have before trying another setup. For a quick introduction, see VMess vs. VLESS, then check what your client supports rather than assuming the protocol name tells you everything.

The goal is a configuration you can explain, verify and restore: know why each exception exists, where DNS requests go, how apps reach the core and what system settings should look like after you close the client. For a new requirement, start from your working baseline, add the fewest settings possible and keep them only after testing. Review the quick start guide for a first connection, or return to the download center to choose an installation format. There is no need to repeat every stage to fix one issue.