V2Ray for Windows Download v2rayN and Setup Guide

Subscription Groups › Subscription Group Settings › Add

Manage subscription URLs separately from the server list

In “Subscription Group Settings,” enter a name and subscription URL, then save and update it from “Subscription Groups.” First try updating without a proxy; use a proxy only if the URL requires one. Managing subscriptions is easier than importing links one by one, but a successful update only means the content was retrieved—not that every server will connect. After importing, select a server, set it as active, and test the connection. Subscription URLs often contain access credentials, so don’t share them in public screenshots or paste them into untrusted conversion sites.

{
  "outbounds": [
    { "tag": "proxy", "protocol": "vmess" }
  ]
}

This snippet shows only the Xray outbound structure; the server address, user information, and transport settings come from the imported subscription.

Settings › Routing Settings › Preset Rules

Use rule order to decide what connects directly and what goes through the proxy

Start with the preset rules in “Routing Settings.” Check which outbound is used for mainland China domains, private addresses, and all other traffic before adding custom rules. Rules are generally matched from top to bottom, so a broad rule near the top can shadow more specific rules below it. Unlike a global proxy, split routing preserves the usual path for local network services, but depends on domain classification data and DNS results. When troubleshooting a website, check which outbound matched before changing the server, DNS, and rules all at once. Outbound tags in the snippet must exist in your actual configuration.

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

Main Window › System Proxy › Automatically Configure System Proxy

Check the local port before enabling the system proxy

After selecting an active server, set “System Proxy” to “Automatically Configure System Proxy” in the main window. This changes the system proxy settings but does not force every app to use the proxy; check apps with their own proxy settings separately. Under “Core: Basic Settings” in “Settings,” confirm the local mixed port, then configure apps to use that same port. Compared with TUN, this route makes browser traffic easier to inspect and is a better starting point for initial testing. Clear the system proxy before closing the client so the system doesn’t keep pointing to a local address that is no longer listening.

{
  "inbounds": [
    {
      "tag": "http",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "http"
    }
  ]
}

This Xray HTTP inbound illustrates a local proxy entry point; it is not a complete representation of all listeners configured by the graphical interface.

Settings › Settings › TUN Mode Settings

Route traffic from apps that don’t use the system proxy

TUN uses a virtual network interface to capture traffic, making it useful for apps that don’t support manual proxy settings. First confirm the server works with the system proxy. Then review “TUN Mode Settings,” grant the required network permissions for your platform, and enable TUN. TUN affects more traffic than the system proxy and is more likely to conflict with other virtual adapters or corporate networking software. For your first test, keep the default settings and check that direct-access sites and local network services still work. If the network goes down, disable TUN to restore the baseline, then check routing and DNS separately. Avoid stacking multiple traffic interception tools.

{
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "address": ["172.19.0.1/30"],
      "auto_route": true
    }
  ]
}

This is a sing-box TUN inbound snippet; do not paste it into an Xray configuration.

Settings › DNS Settings

Check DNS and traffic routing together

DNS determines which address a domain resolves to; routing determines which outbound handles the connection. In “DNS Settings,” first confirm which core you’re configuring—don’t combine fields from different cores. Choosing DNS servers by domain can help avoid issues caused by sending every query down the same resolution path, but the DNS servers themselves must be reachable. Encrypted DNS does not guarantee that queries go through the proxy; check how those connections are routed too. If a domain fails but its IP address works, check the DNS logs and cache before changing the remote DNS server.

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "https://dns.google/dns-query"
    ]
  }
}

Xray DNS example. Test the DNS servers and their routing against your current network.

Settings › Settings › Core Type Settings

Protocol compatibility matters more than the core’s name

The graphical client manages servers; the core actually establishes the connection. In “Core Type Settings,” check the protocol, transport, and security parameters used by the server before choosing a core. Similar names don’t mean configuration fields are interchangeable. Multiple cores support different configurations; switching does not guarantee a faster connection. After changing cores, reconnect and check the logs for unsupported fields or protocols. Keep the last working configuration and test one change at a time. That makes problems easier to pinpoint than replacing all your settings at once.

{
  "log": {
    "loglevel": "warning"
  },
  "outbounds": [
    { "tag": "direct", "protocol": "freedom" }
  ]
}

Xray log and direct outbound snippets; use the corresponding configuration syntax for other cores.