Advanced V2Ray Configuration Guide

Subscription Groups & Server Filtering

Manage subscription URLs separately from connection settings

In v2rayN, open Subscription Group Settings, create a separate group, then enter the subscription URL. The group stores the update source, notes, and filter conditions; each server entry stores the protocol settings imported from that source. Editing a group note does not change remote connection details, and updating a subscription does not switch the active server. After an update, check which entry is selected in the main window.

Name groups by purpose and source, such as “Daily use” or “Compatibility testing.” Never put subscription URLs in notes, screenshots, or shared documents. URL paths and query parameters may grant access. When troubleshooting, record only the URL type, response status, and error text; redact the actual URL. Preserve its original encoding when copying it—do not remove parameters that merely look redundant.

For the first update, turn off filtering and confirm that the server list loads. Then add filters one at a time. Distinguish an empty response from a response whose entries were filtered out. For an empty response, check whether the subscription is valid, the network is reachable, and the response format is supported. If entries were filtered out, check the filter expression. Repeatedly refreshing will not fix an invalid filter and may obscure the actual response.

Narrow the filter by field and match type

Before filtering servers, check the setting’s description: does it match server remarks, protocol type, or another field? Does it use literal text, substring matching, or regular expressions? Do not assume different clients behave alike. If the field explicitly supports regex, the expression below matches remarks containing “test” or “backup.” It defines a match condition; whether matching entries are kept depends on how the filter works.

(test|backup)

Avoid starting with a complex combination of exclusions. Test against one remark that should match, another that should not, and then an empty remark. Parentheses, pipes, and periods have special meaning in regular expressions; escape a period with a backslash to match it literally. Check how the current field handles case rather than inferring it from the letters shown in the interface.

If subscription sources use different naming conventions, set filters for each group instead of putting every name into one expression. A source may change its remarks and suddenly cause an existing filter to hide every entry. Before updating, note a name pattern that should remain; after the update, check that it is still present. A change in list size alone does not indicate a service problem—the source may have changed its contents.

Understand update overwrites and connection-setting differences

Subscription entries are generally regenerated from remote data. If you need to keep transport settings customized, first check whether the client can save a separate copy or convert an entry to a manual one. Put any copy in a separate group and note that it will no longer inherit subscription updates. Do not assume edits to a subscription entry will survive the next refresh. Perform a controlled update and check which fields are overwritten.

If import succeeds but the connection fails, check the protocol, server address, port, transport, and TLS-related fields. A successful import only means the client can parse the format; it does not mean the current core supports every feature. v2rayNG and v2flyNG use different core families, so similar-looking interfaces do not make their configurations interchangeable. Confirm the protocol requirements before choosing a client.

If a subscription update fails, keep the configuration that still works; do not immediately clear every group. Check the URL, system time, certificate errors, and whether updates are routed through the proxy. See How to troubleshoot failed v2rayN subscription updates for detailed steps. Fix the source first, then restore filtering so you do not change the URL and filter logic at the same time.

Finish with a minimal test: update one group, select an entry with a known purpose, start the core, and check the logs for configuration parse errors. Enable automatic updates only after the test passes. This separates subscription format, filtering, and connection settings so a bulk change does not wipe out your working baseline.

DNS Configuration

Map the actual resolution path first

Check DNS at the application, operating system, client, and remote-outbound layers. A browser may use its own Secure DNS; the system may use a local resolver; the core may keep a separate cache; and the proxy server may resolve the final destination. Changing “DNS settings” affects only queries handled by that configuration. Do not assume every app will start using the new server immediately.

First confirm whether the app sends a domain or an IP address to the proxy. With a proxy method that supports remote resolution, the app can pass the domain to the proxy. If the app resolves it first and sends an IP to the client, domain-based routing may no longer have the original name. Check the app’s proxy settings or traffic-capture method; adding a DNS rule alone will not restore all the missing context.

Distinguish two key lookups: resolving the proxy server’s own address and resolving the destination. The first happens before the proxy connection is established, so it needs an independently available route. If the only bootstrap resolver is accessible only after the proxy is up, startup can deadlock. If an encrypted DNS service is configured by domain name, also consider how that name is resolved initially.

Choose resolvers by purpose

The following simplified built-in DNS snippet is for V2Fly or Xray configurations that support these fields. It uses a public resolver for general queries and delegates local domains to the system resolver. The example illustrates domain conditions and query strategy; public resolvers are not reachable on every network. Replace them as needed for your network and check whether the client overwrites this section.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      "1.1.1.1",
      {
        "address": "localhost",
        "domains": ["domain:localhost"]
      }
    ]
  }
}

Intranet services often rely on private records in the local DNS server. Sending every query to a public resolver may make those records unavailable or return addresses that do not work on the current network. Keep a clear local resolution path for corporate domains, router names, and self-hosted services. Do not treat every single-label name as a public domain, or disable all DNS routing to fix one internal name.

The resolver’s transport and the actual query route are separate concerns. Encrypted DNS protects the relevant transport link, but whether it goes through the proxy depends on the core, outbound rules, and how the client generates its configuration. Some local resolution modes bypass normal routing. Check the runtime configuration and connection logs to confirm behavior; an encrypted protocol in the server address does not tell you which path the query takes.

Conditions such as “expected IP” check whether a response falls within the rule’s expected range; they are not a general speed setting. If enabled and a valid response is rejected, fallback queries may make troubleshooting harder. First confirm that basic resolution works, then add result constraints. Keep a test domain and its expected address range as a reference for every added condition.

Test address families and caches separately

On networks that support both IPv4 and IPv6, check resolution and connectivity for each separately. Getting an IPv6 address does not mean the current outbound has a working IPv6 route. If the logs show an address being selected followed by a connection failure, check the system route and outbound support before changing query strategy. Removing all IPv6 settings may temporarily change the symptom, but does not prove the DNS service was at fault.

After changing resolvers, the browser, operating system, and core may each retain cached results. Close existing connections, restart the test app, and clear the relevant cache as needed. Do not change the server and query strategy at the same time, or you will not know what caused the result. System lookup tools test the system resolution path, not necessarily the core’s built-in DNS, so different results from a browser do not automatically mean the configuration failed.

Keep one simple resolution path as a baseline during troubleshooting. Disable complex fallback and result filtering first, and confirm that a basic query completes. Then restore domain categories, address-family preferences, and encrypted transport one at a time. If local names work but external names fail, check whether the external resolver is reachable. If the query completes but the destination is unreachable, return to the routing section and check the outbound rather than adding more resolvers.

Finally, consider the privacy implications of DNS logs. Debug logs may contain full domain names and can become a detailed record of browsing activity if retained. Restore the normal log level after testing, and redact internal names and subscription details before sharing errors. The goal of DNS tuning is a clear, understandable query path—not the largest possible list of upstream servers.

FakeDNS

Understand virtual addresses and domain mapping

FakeDNS does not return the destination’s real address. Instead, it assigns a virtual address from a dedicated pool and stores the domain-to-address mapping. When the app connects to that address, the traffic-capture component uses the mapping to recover the original domain before routing and outbound handling. FakeDNS helps identify domains in traffic that uses IP addresses; it is not a public resolver that replaces the entire DNS chain.

FakeDNS works only when the loop is complete: queries reach FakeDNS, the returned virtual addresses are captured by the same traffic-capture chain, the mappings are still available, and the inbound restores the correct domain. If any part is missing, the result may be “DNS resolved, but nothing loads.” Verify regular DNS and TUN first, then add FakeDNS. This avoids layering address mapping onto a traffic-capture path that is not yet stable.

Do not route virtual addresses directly to the real network. They do not identify the destination server and usually cannot be reached over a normal network. If logs repeatedly show attempts to connect to an address in the pool, check mapping recovery and traffic-capture scope rather than looking for a proxy server that can reach it. Domain rules and remote resolution need the original domain as input.

Align core support with inbound configuration

The following shows the FakeDNS settings used by a compatible Xray configuration: the address pool, DNS server, and sniffing settings for the target inbound. Merge them into the correct locations in the same runtime configuration; they are not three top-level objects to append arbitrarily. If the client already generates these sections, use its corresponding settings to avoid duplicate declarations or overwriting required options.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

The second snippet is a sniffing object inside an inbound; it must not replace the entire inbound configuration. If the inbound also needs HTTP or TLS sniffing, merge the lists according to the core’s documentation rather than mechanically deleting the existing options. Virtual-address and sniffing implementations differ between cores. Before using this in v2flyNG, confirm that the selected core and client support it.

The example address pool is intended for virtual use, but check whether your device or local network already uses it. Test environments, other proxy components, and network diagnostic tools may use the same range. Overlapping addresses make routing ambiguous. Do not pick a seemingly unused public range at random. If the client allows changes, follow the implementation’s address-pool requirements and check route exclusions as well.

Pool capacity determines how many mappings can be retained; it does not determine the number of reachable servers or connection speed. A small pool may evict old mappings sooner when many domains are in use. Increasing it arbitrarily may consume more resources. Start with the implementation’s recommended default and adjust only if logs and a reproducible test point to mapping eviction. One slow-loading app is not proof that the pool is too small.

Handle caching and apps that bypass the proxy

After enabling or disabling FakeDNS, apps and the system may continue using cached results. If an app still has a virtual address after its mapping was lost on restart, failures may be intermittent. When testing a change, close the relevant app connections, clear the appropriate DNS cache, and make a fresh request. Restarting only the core while the browser reuses an old address or connection mixes old and new state.

An app’s own encrypted DNS may bypass the expected query path; a fixed-address connection does not involve a domain lookup at all. Neither flow automatically gets a FakeDNS mapping. Identify the app’s actual behavior, then decide whether to change its DNS, proxy method, or traffic-capture scope. Other apps working does not mean the problem app uses the same resolution path.

Keep regular DNS available for local names and apps that depend on real addresses. Some services pass a resolved address to another process that is not captured; that process may not be able to use a virtual address. For these cases, set an explicit resolution exception for the relevant name rather than exposing the virtual address range more broadly. Consider the app’s architecture when diagnosing address handoffs between processes.

To roll back, restore regular resolution, disable virtual mapping, clear stale caches, and reconnect—in that order. If the app still connects to a virtual address, address the cache first rather than changing server settings. FakeDNS is useful when preserving domain information in IP-based traffic is necessary. If a regular domain-based inbound meets your needs, there is no reason to enable it just to add complexity.

Custom Outbounds

Connect routing rules to outbounds with tags

Outbounds define how connections leave the core, and routing selects one by its tag. A tag is only an internal reference name; it has no special behavior. Naming an outbound direct does not make it a direct connection—the protocol and its settings determine what it does. Check the outbound object first, then the routing reference. Matching tag names are necessary, but not sufficient, for a valid configuration.

A GUI client usually generates a proxy outbound for the selected server, along with direct and blocking outbounds. Before adding a custom object, check whether the client expects an appended snippet, a complete configuration replacement, or a dedicated custom-configuration entry. A partial snippet in a full-configuration field will be missing required sections such as inbounds. Conversely, putting a full configuration in an append area may create duplicate definitions.

The following are common direct and block outbound snippets for native V2Ray or Xray configurations. They illustrate the tag structure; check for existing tags before merging. The example contains no proxy-server credentials and is not a complete client configuration. Generate proxy outbounds from a verified server entry to avoid omitting transport or security settings when writing them by hand.

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

Test one route before adding more

After adding an outbound, start with one narrow, explicit rule that references it. Choose a test target you can control, confirm that the core starts, the tag exists, and the rule matches, then consider expanding its scope. Do not replace the route for all traffic at once. If the configuration is wrong, every app failing at the same time leaves fewer clues and may also cut off subscription updates and help pages.

Direct outbounds still depend on DNS and the system network. They do not bypass the firewall or guarantee use of a particular physical interface. If you need to bind an interface or specify a source address, confirm that the current core supports the option and that the system permissions are sufficient. Verify that the address belongs to this device. Copying an interface name or address from another device will usually break the connection, not reproduce its route.

A proxy chain is not created simply by defining multiple proxy outbounds. Connections pass through multiple stages only when an explicit handoff is configured; ordinary routing generally selects one outbound. Before building a chain, verify each stage independently, including its DNS resolution, transport protocol, and authentication requirements. Any failed stage affects the whole chain. Read logs stage by stage rather than looking only at the final timeout.

Pay particular attention to UDP and multiplexing. An outbound that carries web traffic may not support every datagram flow, and a protocol that supports multiplexing does not mean it benefits every app. Keep the defaults initially; test changes only when you have observed connection-setup overhead or a compatibility issue. Mux is not a guaranteed speed boost, and multiplexing fields from different cores are not interchangeable.

Handle default outbounds, loops, and compatibility

Without an explicit fallback rule, the default outbound may depend on object order. Inserting an object can change the route for unmatched traffic even if no existing rules changed. Note the default behavior before editing, then test a target that should not match any earlier rule. To make the intended default reliable, use a fallback method supported by the current core rather than relying on incidental ordering.

Avoid circular references between outbounds, and make sure an outbound’s connection is not captured again by the local proxy inbound. The first issue is caused by handoff relationships in the core configuration; the second may come from the system proxy, TUN, or app proxy settings. Both can appear as repeated connection attempts and timeouts. Map each next hop until you reach the actual network exit, and account for any arrow that points back to the start.

Save the configuration before switching cores, then check the protocol, transport, security options, and resource formats one by one. V2Fly and Xray share some configuration concepts, but not every extension is compatible. v2rayNG and v2flyNG are not the same runtime environment just because their names are similar. If a core reports an unknown field, correct the configuration for the features it supports; do not simply delete the line without accounting for its purpose.

When maintaining a custom configuration, keep each tag’s purpose in a separate note; comments in strict JSON can cause parse errors. Check brackets, commas, quotation marks, and duplicate keys when saving. Change one logical unit at a time, then verify network access after the core starts. Passing syntax checks does not mean the outbound is reachable. To choose a different client, see the downloads page for platform and core details.

To remove a custom outbound, first remove or update rules that reference it, then delete the object and check the default route. Removing an outbound while leaving its tag in a rule can make startup or rule matching fail. After rolling back, reconnect the test app and confirm that the client is generating the expected configuration; the interface may look restored while the runtime file still contains the old settings.