V2Ray Setup
Guide for All Platforms

Before You Start: Devices, Subscriptions, and Configuration

Know the Difference Between the Client, Core, and Server

The client displays your server list, stores subscriptions, and changes system proxy settings. The core handles protocol connections, routing, and local listeners. v2rayN is a desktop GUI client; v2rayNG and v2flyNG are for Android. Installing a client does not provide a server connection—you also need a valid subscription URL or a complete configuration for an individual server. Project V is part of the broader technology ecosystem. V2Fly and Xray are core families, not subscription service names.

Before configuring a client, make sure your server details come from a trusted source and that you understand the terms of use. Subscription URLs often contain access credentials; treat them like account information and never post them in public forums, screenshots, or online conversion tools. When asking for help, share only the protocol, transport, and error type. Redact server addresses, user IDs, and subscription query parameters. Client logs may also include destination domains, so review them line by line before sharing.

Check Your Device Architecture and Package Type

Devices with the same operating system can use different processor architectures. On Windows, check System type under Settings → System → About. On macOS, check the chip or processor under About This Mac. On Android, check your device information; if you can't confirm the architecture, choose a universal package. On Linux, use the command below to check. Don't guess based on a device's appearance or age, and don't confuse a distribution name with a processor type.

uname -m

Check the download page and installer prompts for minimum system requirements and required runtimes. Desktop clients include multiple components, such as the UI and core, so moving only the main executable may leave required files behind. Install in a directory your account can write to. For a portable setup, move a supported configuration backup along with the client instead of copying a handful of files from an old installation into a new one.

Start with a Reproducible Setup

Close other proxy clients, network accelerators, and duplicate instances first. Keep one program in charge of routing traffic. Note your existing system proxy, DNS, and VPN settings, especially on a managed work device. For your first test, don't enable the system proxy, TUN, custom DNS, and a large set of routing rules all at once. Start with the defaults and confirm one server connection works, then add features one at a time. That gives you a clear point to roll back to if something breaks.

Choose two test sites: one that normally works without a proxy and one HTTPS site to verify the proxy route. A page loading in your browser only confirms that browser's current connection path; it doesn't prove every app is being routed. Check the client logs for the corresponding requests, then compare behavior with proxy routing turned off. Use the same browser window for each test to limit differences from extensions, caches, and other apps.

Finally, check the system clock, whether your network requires a sign-in, and whether the device is on a managed network. Certificate validation depends on the correct time, and an incomplete captive portal sign-in can make subscription updates time out. First confirm that a regular browser can access the internet with the proxy off, then continue to the relevant platform section. If you just want to make your first connection, return to the user guide; there's no need to change every advanced setting at once.

Windows: Install and Configure v2rayN

Choose the Desktop or Classic WPF Version

Choose v2rayN in the Windows downloads section. The Desktop version uses a cross-platform interface; the Classic WPF version retains the Windows UI. This is a difference in implementation, not an indication that a server will work with only one version. First check that the x64 package offered on the download page matches your device, then follow the installer prompts. If Windows reports a missing runtime, install the component it specifies. Don't download DLLs from unknown websites.

If no window appears on first launch, check whether an instance is already running in the notification area, then see whether Windows has blocked the program. You don't need to run as administrator indefinitely just to test the system proxy. An installation in a protected directory may have different write permissions than one in a regular folder. If settings disappear after every restart, check directory permissions and security software logs instead of repeatedly importing the subscription.

Import a Subscription and Choose a Server

Go to “Subscription Groups → Subscription Group Settings,” add a group, and enter a label you can recognize. Paste the complete subscription URL into the address field, save, then select “Update all subscriptions (without proxy).” For initial setup, use the direct update option because you don't have a working proxy yet. Once the update finishes, select the group, confirm that servers appear in the main list, and choose one as the active server.

If the list doesn't change, clear the search filter and switch to “All,” then check the update log. A login page returned in place of the subscription, an expired subscription, or an incomplete URL can all leave the client with nothing it can parse. Import a single share link through an option such as “Import bulk URLs from clipboard”—don't enter it as a subscription URL. Saving a configuration doesn't mean it's complete; verify the protocol, port, and transport settings.

Start with the System Proxy; Try TUN Only If Needed

After selecting a server, choose “Set system proxy” under “System Proxy” and start with the “Bypass mainland China” routing mode. The system proxy affects apps that follow Windows proxy settings; some command-line tools and apps use their own network configuration. A working browser connection doesn't mean those apps will follow the system proxy. Check the local listener details at the bottom of the client. Ports depend on your settings; common examples are SOCKS 10808 and HTTP 10809, but verify the values before entering them in another app.

Consider TUN when traffic from apps that ignore the system proxy needs to pass through the client. TUN relies on a virtual network interface, routing, and the required permissions, so enabling it may prompt for authorization. First disable other VPN or virtual adapter traffic-capture features, then switch on TUN in the client. If initialization fails, check the logs for permission, adapter, or routing errors. TUN and the system proxy don't have to be enabled together; when troubleshooting, test one traffic-capture method at a time.

Port Conflicts, Exiting, and Startup

If the log says a port is in use, first close any duplicate client. To investigate further, run the command below in Command Prompt. It only shows connections and process IDs; it doesn't change network settings. Match the process ID against the “Details” tab in Task Manager. Don't terminate an unfamiliar system process just because it owns a port. If you change the port, update any browsers, terminals, and other apps configured to use it.

netstat -ano | findstr ":10808"
netstat -ano | findstr ":10809"

Closing the window may only minimize the client to the notification area; it may still be running. To test a full exit, choose “Clear system proxy” in the system proxy menu, exit from the tray menu, then check Settings → Network & Internet → Proxy for a leftover manual proxy address. Enable startup on boot only after manual launch and normal exit both work reliably. Otherwise, after a reboot, other apps may still point to a local proxy port even though the client isn't running, making it look like the browser has lost internet access.

macOS: Architecture, System Permissions, and Proxy Settings

Choose a DMG for Your Chip

Open “About This Mac” from the Apple menu. If it shows an Apple chip, choose the Apple Silicon package; if it shows an Intel processor, choose the Intel package. Then get the matching v2rayN DMG from the macOS downloads section. Open the disk image, drag the app to Applications, and launch it from there. Avoid running it from the mounted disk image long-term: updates, permission records, and the app location may become inconsistent, and the app shortcut will stop working when you eject the image.

If a security prompt appears on first launch, confirm the download source and app name, then check the options macOS provides under “System Settings → Privacy & Security.” Don't disable system-wide security protections just to launch one app. If the app's architecture is incompatible, return to the download page and choose the correct package. If your macOS version isn't supported, update to a supported system or runtime rather than modifying package files to bypass startup checks.

Configure a Subscription and Select a Server

In v2rayN, open the settings related to “Subscription Groups,” add a group, and save the complete subscription URL. Then use the option to update without a proxy. Button placement may differ between the cross-platform Desktop interface and the classic Windows version, but the steps are the same: save the group, request the subscription, then select an active server. If the list is empty afterward, check the selected group and filters, then review the update result. A menu layout difference doesn't mean the subscription is incompatible.

For your first connection, keep the TLS, server name, and transport parameters supplied by the subscription. The server address is used to establish the network connection; the TLS server name is used for certificate and handshake identification. They may differ, so don't change them to match just for the sake of consistency. Once the subscription is imported, select a server, enable the system proxy, and test a site. If it fails, check the core log before changing multiple transport options.

How System Proxy Settings Map to Network Services

macOS proxy settings are tied to network services. To check the active settings, go to “System Settings → Network,” open the current Wi-Fi or Ethernet service, then select “Details → Proxies.” The client may ask for authorization when it changes the system proxy. If you decline, the setting shown in the client may not match the actual system state; check again. Note the current values before making manual changes. Don't remove organization-managed proxy settings or automatic configuration URLs without first checking your device's management requirements.

When switching from Wi-Fi to Ethernet, or adding a network service through a dock, first confirm which service is active. The browser may follow the new service's proxy settings even while the client is running, making it look as if the client is working but no requests are reaching its logs. If pages stop loading after you exit, check whether that network service still points to a local proxy port. Undo only the change you made; don't clear all network settings.

TUN Permissions, Sleep, and Network Changes

TUN creates a virtual network interface and changes routes. The authorization required depends on the client and system environment. Disable other VPN traffic-capture tools first, then grant the permissions requested by the client. If authorization is canceled, a background helper isn't running, or route creation fails, resolve the initialization error first. Not every permission prompt is a standard notification request, and granting permission once may not cover later changes to the installation location.

After waking from sleep or switching networks, existing connections may fail, and DNS or the default route may have changed. Turn the active traffic-capture mode off and back on, then check whether new requests connect. Restart the app only if the interface or core is actually malfunctioning. If permissions fail after changing the install location, system account, or restored backup, recheck the app directory and system authorization status. Change one thing at a time; this is usually more effective than repeated reinstalls.

When moving to another Mac, migrate the subscription source and essential routing records first, then check the new machine's chip, listener ports, and permissions. A full export from the old device may include local paths and network-service details that shouldn't be reused without review. After migration, test the system proxy and TUN separately, then confirm that exiting normally restores the network. This isolates issues to a specific traffic-capture method.

Linux: Packages, Desktop Proxy, and Permissions

Match the Architecture and Package Format

On Linux, check two things: the processor architecture and the distribution's package format. Debian and Ubuntu commonly use deb packages; Fedora and related distributions commonly use rpm. x86_64 generally maps to x64, and aarch64 to arm64. Confirm using system information or the command below, then choose v2rayN from the Linux downloads section. Don't rely only on the file extension or assume architecture output from a container tells you everything about the host desktop.

uname -m
cat /etc/os-release

After downloading, open the package with your distribution's software installer so the package manager can handle dependencies and app shortcuts. If dependency resolution fails, check which components are missing and whether your system is supported. Don't copy library files from another distribution into system directories. A graphical desktop client needs an active desktop session; installing it on a remote, terminal-only system doesn't mean the GUI, tray, or system proxy integration will work.

Set Up a Working Configuration as a Regular User

Launch v2rayN from the app menu and save the subscription as your regular user. Under “Subscription Groups,” add the URL, use the direct update option, and select an active server after the list appears. Don't run the entire GUI as root just to avoid a permission prompt; that may change ownership of the configuration files and prevent your regular user from saving settings later. If saving fails, first check whether your user directory is writable.

Before updating, make sure the basic network can reach the site hosting the subscription. A browser in the desktop session may already use a proxy, while the client's subscription request may take a different route. So being able to open the subscription page in a browser doesn't prove that a direct update will work. For the initial import, use a subscription source you can reach directly. Once an active server is available, test updates through the proxy if the source requires it, and record the results for each method separately.

Desktop System Proxy Isn't a Universal Per-Process Switch

Proxy support varies across Linux desktop environments. GNOME and KDE network settings are separate from environment variables used by terminal processes. Some apps read desktop settings; others use their own configuration or environment variables. After the client reports that the system proxy is set, verify it in the desktop network settings and test with the app you care about. If a terminal command still connects directly, first check which proxy method that tool supports rather than assuming the client is broken.

After confirming that the local HTTP listener is on port 10809, use the command below to check whether it can handle an HTTPS request. The proxy option applies only to this curl request; it doesn't configure the whole terminal or system. The example uses a reserved documentation domain. Replace it with an approved target when testing real services. If the client's port differs, update the command. If curl isn't installed, you can run a similar test using a browser's per-app proxy settings.

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

An HTTP proxy can carry HTTPS requests using CONNECT, so an HTTP proxy address doesn't mean the destination site loses TLS. If an app requires SOCKS, use the SOCKS port the client actually provides; don't just change the protocol prefix while keeping the HTTP port. Tools can also handle remote DNS resolution differently, so record both the proxy type and where DNS resolution occurs when comparing results.

TUN, Routing, and Desktop Sessions

TUN involves device access, network-management permissions, and system routes. A client running as a regular user may need additional authorization. Follow the method recommended by the client and your distribution; don't copy privilege-escalation commands from unknown sources or grant excessively broad permissions indefinitely. If startup fails, check whether access was denied, virtual interface creation failed, or an existing VPN route conflicts before investigating further. Not every failure is caused by the server.

A missing tray icon may mean your desktop environment doesn't support or enable it; it doesn't prove the core isn't running. Startup also differs between autostarting in a desktop session and running as a system service, which use different users, environment variables, and permissions. First confirm that manual startup, network switching, stopping traffic capture, and exit recovery all work. Then configure autostart. After updates, recheck permissions and startup entries so an old shortcut doesn't point to a path that no longer exists.

Android: v2rayNG and v2flyNG

Choose and Install a Client

In the Android downloads section, v2rayNG is the recommended choice and uses the Xray core. Choose v2flyNG if you need a V2Fly core environment. Don't connect both clients through VPN at the same time. Most newer devices use arm64; if you're unsure, choose a universal package. A universal package supports more architectures—it doesn't provide a better connection. Don't choose solely by phone brand.

When installing a downloaded package, Android may ask you to allow “Install unknown apps” for the browser or file manager you used. Grant permission only to the source you're installing from, and turn it off again afterward if you prefer. If installation fails, check for an older app with the same name, available storage, and system compatibility. If you already have a configuration, export a backup using the client before upgrading; uninstalling to fix an update can also remove subscriptions and custom rules.

Import a Subscription or a Single Server

In v2rayNG, open “Subscription Group Settings” from the menu, add a group label and subscription URL, save, then update the subscription. Depending on the build, the update option may be in the main screen menu or the group menu; look for the feature name. After a successful update, return to the list, select the server you want, confirm it's the active entry, and start the connection. Saving a group without updating it won't add any servers.

Import a single share link from the clipboard using the add option on the main screen. Scanning a QR code requires camera permission. Other apps may replace clipboard contents, so after importing, check that the type, address, and port look right. If Android restricts background clipboard access, bring the client to the foreground and import again instead of repeatedly granting unrelated permissions. v2flyNG has a similar workflow, but check its core separately for support for the specific protocol options you need.

Android VPN Permission and App Coverage

The first time you tap Connect, Android displays a VPN connection request. Confirm it's from the client you just installed, then authorize it. This permission lets the client route traffic through Android's local VPN service; it doesn't provide a remote server. After connecting, check the system VPN status and client logs. Android generally allows only one active VPN service, so work profiles, other VPN tools, and local traffic-filtering apps may replace one another.

Android clients generally use the VPN service to route app traffic; don't follow desktop instructions for “Automatically configure system proxy.” To control which apps are included, check the client's per-app proxy settings. First determine whether the mode means “only proxy selected apps” or “bypass selected apps”—these do the opposite. Reconnect after changing the setting and test apps both inside and outside the list; checked boxes alone don't confirm the scope is correct.

Background Operation, Private DNS, and Network Changes

If the connection drops when the screen locks and returns when it wakes, check the system's battery optimization, background activity, and autostart restrictions for the client. Settings names vary by manufacturer; check the client individually rather than disabling power saving for the entire device. Background restrictions usually stop the process or remove the VPN status. If the process is still running but the log shows connection timeouts, investigate network changes, server reachability, and DNS instead of adjusting battery settings again.

Switching from Wi-Fi to mobile data changes the local address and default route, which may break existing connections. Stop and restart the connection, then check whether a new handshake succeeds. If it fails only on one network, note the network type and time, then compare the same server on another connection. Android's Private DNS setting and the client's DNS settings are separate. Changing both at once makes troubleshooting harder. If name resolution fails, first note the current Private DNS setting, then test one change at a time.

A client's latency test doesn't reproduce the full app connection; some tests check only limited stages. If a server passes its test but apps still fail, check per-app rules, routing, and DNS. If a test fails while a webpage loads, the test target or method may be the issue. When moving to another device, transfer the subscription source first. Android VPN permissions and battery settings must be configured again on the new device; they aren't carried over by a configuration backup.

Subscriptions: Updates, Parameters, and Migration

Subscription URLs vs. Single Server Links

A subscription URL points to an updatable collection of configurations; a single share link describes one server. Use the appropriate import flow for each. Don't judge by URL length—check how the source describes it. Treating a web page share URL as a subscription often returns HTML that the client can't parse. Entering a single-server link as a subscription can also fail during an update. Identify the source type first, then choose subscription group settings or clipboard import.

Create groups by source or purpose, with labels you can recognize. More groups aren't always better; duplicate subscriptions create similar entries and make it harder to match the active server to test results. If entries disappear after an update, don't assume the client deleted them. Check whether the source changed its contents, the account expired, or the client is hiding a group. Review list filters separately from the actual subscription contents.

Update Through a Proxy or Directly

“Update all subscriptions (without proxy)” sends subscription requests without relying on the active proxy. It's a useful option during initial setup, but it doesn't guarantee the subscription source is reachable directly. Updating “through proxy” requires a selected, working server. If the active server came from an expired subscription, using it to update that same subscription can create a loop. Keep the original source details so you can recover, and use a direct update when the basic network allows it.

When an update fails, check three stages: whether a connection was established, whether the response has the expected format, and whether the parsed entries work. A connection timeout and a returned login page are different problems. Successful parsing only means the fields could be read; it doesn't prove the server can complete a handshake. Special characters, trailing parameters, and letter case in a subscription URL may all matter. Don't edit the URL to make it shorter. When copying it, watch for line breaks, full-width punctuation, and text added by chat apps.

Don't Change Protocol Fields on a Guess

Common fields fall into four groups: connection target, authentication, transport, and TLS. The address and port determine where to connect; a user ID or password is used for authentication; the transport type and path determine how data is carried; and the TLS server name, ALPN, and related security settings are involved in the handshake. Whether a field can be omitted depends on the protocol and server configuration. Don't reuse parameters from another working server or guess defaults based on field names.

The server address, Host, and TLS server name may differ because they operate at different layers. If a certificate name doesn't match, check the source parameters and system time; don't disable certificate verification to hide the error. A recognized protocol doesn't mean the core supports every extension. When switching between v2rayNG and v2flyNG, check support for the specific protocol and transport options instead of comparing server labels alone.

Backups and Cross-Platform Migration

Migrate in two stages: first preserve the subscription source, group labels, and any essential custom rules, then consider a full backup provided by the client. Local paths, listener ports, TUN permissions, and UI settings may not transfer between operating systems. On the new device, install a client for the right architecture, import the subscription, and establish a basic connection before restoring routing and DNS settings one at a time. This helps distinguish migration problems from existing configuration issues.

Updating a subscription may rebuild the server entries it manages, so direct edits to those entries may not persist. If you need to test parameters, make a separate test configuration if the client allows it, and label it clearly to avoid using it by mistake later. After migration, check whether the old device still needs access. If subscription details have been exposed, change the credentials at the source; deleting a group from the client doesn't revoke a leaked URL.

Proxy, Routing, and DNS: Test Each Layer

The Traffic-Capture Method Doesn't Determine the Final Route

The system proxy, an app's own proxy, and TUN send requests to the client; routing rules then decide whether to connect directly, use a proxy, or block the request. Turning on TUN doesn't mean every destination goes through a remote server, and choosing global routing doesn't mean every app is being captured. Test these as separate steps: first confirm the request appears in the core log, then check which outbound it uses. A switch's color alone doesn't reveal the actual network path.

For an initial test, use the system proxy with a preset routing mode. In v2rayN, “Routing → Bypass mainland China” is a useful starting point for separating common direct and proxied traffic. “Global” can help compare how the same destination behaves through different routes. Presets may change with your configuration, so inspect the actual rules instead of relying on their labels. If an app's requests don't appear in the log at all, check traffic capture before changing domain rules.

Rule Order and Match Scope

Core routing usually evaluates rules in order, and the first match determines what happens. Put specific domain rules before broad ones. Direct rules for private addresses help prevent local services from being sent to a remote server. Domain and IP matching are different paths: if the core only receives an IP address, some domain rules may never match. If it receives a domain, whether it resolves the domain and then checks the IP depends on the domain strategy and configuration.

The Xray routing snippet below illustrates this order: send private local addresses directly, send the documentation domain directly, and use the proxy for other TCP and UDP traffic. It isn't a complete, standalone configuration; the existing setup must include outbound tags named direct and proxy. GUI clients usually generate the core configuration. Direct edits to temporary files in the runtime directory may be overwritten at the next launch, so use the client's routing editor when possible.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:example.com", "domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

full:example.com matches the exact domain, while domain:example.org matches that domain and its subdomains. Rule tags must match the actual outbound; don't copy these names without checking. If you use geosite or geoip data, make sure the relevant resources are available. Valid syntax only means the structure can be parsed—it doesn't guarantee the rules are in the right order. Review each rule using custom routing syntax and priorities.

DNS Resolution Can Change the Result

DNS translates domain names into addresses and affects which information is available for routing decisions. System DNS, secure DNS in the browser, app-level resolution, and client DNS may all be in use at once. If a site reports a DNS error, first identify which component made the request. Changing system DNS may not affect a browser using its own encrypted DNS. Changing DNS servers also isn't a general fix for certificate, authentication, or port errors.

FakeDNS uses virtual addresses mapped to domain names to help preserve domain information. It's common with TUN or transparent traffic capture, but isn't required for a first connection. If an app caches a virtual address, you may need to reconnect or clear that app's cache after disabling the feature. If you don't understand how long the mapping remains valid, start with standard DNS settings. Read how FakeDNS works for details, and don't replace all system and client DNS settings at once.

Use Controlled Tests Instead of Changing Settings at Random

To test a custom rule, choose one specific target and note the current traffic-capture method, routing mode, and outbound shown in the logs. First confirm the connection with a preset mode, then add one rule and make a new request. A browser may reuse an existing connection and keep using the old route, so close that site's connection before retrying if needed. If one rule fixes the issue, expand it to similar targets. Avoid importing a large set at once, or you won't know which rule changed the behavior.

Common Configuration Issues: Troubleshoot by Layer

Find the Layer Where the Failure Occurs

Troubleshoot in this order: basic network, client startup, local listener, traffic capture, remote connection, routing, and app. Turn off traffic capture to confirm the regular network works, then start the client and check that the core is running, followed by the local port. Only after those steps should you investigate the server handshake and destination site. This avoids treating a port conflict as a subscription issue or repeatedly switching servers when the system proxy isn't active.

Keep a short record of the operating system, client, traffic-capture method, time of the error, and logs from startup through the first failure. Test with one client and one active server; don't switch repeatedly and then take a screenshot of logs you can't match to a specific attempt. Before sharing, redact subscription URLs, identity fields, and sensitive destinations. Include only enough information to identify the failing layer; there's no need to publish the full configuration.

Empty Server List, Startup Failure, and Port Conflicts

If the server list is empty, switch to all groups and clear filters, then confirm the subscription update actually succeeded. If the update log reports a parse error, check the response, data format, and URL. If it reports a network error, check the basic connection and whether the update request went through a proxy. If servers are present but the core won't start, check configuration generation, resource paths, and port conflicts instead of updating the subscription again.

An “address already in use” log usually means the address or port the client needs is already occupied. Close other clients and duplicate instances, then restart the service. Changing the listener port can resolve some conflicts, but you must also update every app that references it. If the conflict involves a TUN interface or route, changing the SOCKS port may not help. Check the virtual network and permission settings instead; these are separate resources.

Handshake Failures, Timeouts, and Certificate Errors

A timeout means a particular stage didn't finish within the allowed time; it doesn't automatically mean the server is down. Identify whether the timeout occurred while fetching the subscription, connecting to the remote server, or reaching the destination, then compare the same configuration on another working network. If every server times out on one network, investigate that network first. If only one server fails, check its details and server status. Don't change the protocol, port, and transport all at once just to get a latency reading.

For TLS or certificate errors, check the device date, time, and time zone, then verify the server name, connection address, and source details. For authentication failures, check the user ID, password, or subscription expiry. A mismatched WebSocket path, Host, or service name can also cause a connection to drop immediately after it starts. A warning in the log isn't necessarily fatal; check whether startup continues and match the actual failure to the relevant request.

Web pages load, but apps fail; or internet stops after exit

If a webpage loads but an app fails, check whether the app follows the system proxy, is excluded by per-app rules, or needs UDP. HTTP proxy, SOCKS, and TUN cover different types of traffic; one browser test can't prove that every protocol works. If the app's requests appear in the log, check the routing outbound and remote response. If they don't, fix the traffic-capture entry point first. Global routing can't fix an app whose traffic never reaches the client.

If internet access stops after exit, check for a leftover system proxy pointing to a local address or a system policy that blocks connections outside the VPN. First restore the proxy and traffic-capture settings changed during this session, then confirm the client has actually exited. Don't reset all network settings right away; that could remove work network settings, static addresses, and other required configuration. If you need to restart the device, save the error details first. A restart may clear some temporary state, but it won't explain the original cause.

Restore a Working Baseline, Then Add Settings Back One at a Time

If the cause is still unclear, export the necessary configuration, keep the subscription source, and return to one server, a preset routing mode, and a single traffic-capture method. Temporarily remove custom DNS and added rules. Once the baseline works, restore settings one at a time and repeat the same test after each change. Before reinstalling, check whether the issue is tied to your user configuration; reinstalling and restoring the same broken setup usually won't change anything. If the same setup works on another device, that only shows it works in a different environment—it doesn't rule out local network differences.

For other issues, see the FAQ. To understand specific log fields, read how to diagnose v2rayN core logs. After troubleshooting, note the final listener port, proxy method, and routing mode. Remove temporary rules created for testing, then verify that a normal exit and restart both work. Keeping this small working baseline is more useful than accumulating settings you can't explain.