v2rayN Downloads
Setup Guide

A subscription gathers multiple server configurations behind one update point. Create a group, paste a URL you’re authorized to use, and confirm that configurations appear in the list after updating. If a regular update fails, try updating through the proxy if you already have a working connection. Subscription URLs may contain access credentials, so don’t include them in screenshots or public logs. Groups make it easier to track sources and update boundaries than adding servers one by one. Back up custom labels, ordering, and routing rules separately; a remote update is not a permanent archive of local settings. The example on the right shows how a URL is stored in JSON, not the client’s subscription file format.

{
  "url": "https://example.com/sub"
}

VMess, VLESS, and Trojan are distinct outbound protocols, not interchangeable labels. After importing a configuration, check the port, transport, and security settings such as TLS. The same protocol doesn’t guarantee that every parameter is compatible. A GUI client makes it easier to save and switch between configurations, but whether one works depends on the selected core. Start with the complete parameters provided by the server, then consider changing transport options after the connection works. The example on the right shows basic direct and block outbounds to illustrate how routing references a tag. It doesn’t include remote server details and cannot replace a working proxy configuration.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

Routing determines which outbound handles a connection. Rules are evaluated from top to bottom, so exceptions usually belong before broader rules. geosite matches domain collections; geoip matches address ranges. Both rely on the corresponding databases. Start with a few clear rules, such as sending local network addresses direct, then add specific domains as needed. Routing traffic through different outbounds can reduce interference with local services, but you’ll need to maintain rule order and outbound tags. The example’s direct outbound must exist in the outbound configuration. After editing, test a specific destination to confirm which rule matches; saving a rule doesn’t mean it’s working.

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

DNS configuration involves more than entering a resolver address. It also determines who makes the query, which route it takes, and how the result affects routing. A core’s built-in DNS doesn’t automatically handle lookups for every app on your system. If a domain won’t load, first distinguish a DNS resolution failure from a connection failure, then check the query policy and actual outbound. Rather than constantly switching resolvers, keep the boundaries between the app, system, and core clear. The example shows how to configure a server list and an IPv4 query strategy; these values aren’t right for every network. Record the original settings and change one thing at a time so you can identify what made a difference.

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "localhost"
    ],
    "queryStrategy": "UseIPv4"
  }
}

The system proxy lets apps that follow system settings use a local proxy entry point. TUN handles traffic through a virtual network interface. They have different permission requirements and affect different traffic. For a first setup, verify the connection using the system proxy, then explore TUN if you need it. The example on the right is a local SOCKS inbound, not a TUN configuration. Listening on the loopback address accepts connections only from the same device. This is easier to control than exposing a listener to the local network. If other devices do need access, also check the firewall, authentication, and network boundaries; changing the listen address to all interfaces isn’t enough.

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

The client interface and proxy core have different roles. An option in the interface doesn’t mean the active core can interpret the corresponding field. Before switching cores, check which protocols, transports, and security features your configuration uses, then review the core’s supported features. Startup logs are more useful than names alone for identifying unsupported fields or parameters. Keep a working copy of your configuration, run a minimal connection test after switching, and then restore your custom routing and DNS settings. The example on the right shows common log levels; it isn’t a core selector. Choose a core in the client settings, not by adding an invented field to JSON.

{
  "log": {
    "loglevel": "warning"
  }
}