config.json Client Download and Configuration Index
A practical reference for v2rayN and v2rayNG clients, config.json configuration, and routing rules, covering package selection, subscription imports, and proxy mode changes step by step.
routing / rules
Browser or system traffic first enters a local listening port. routing then checks the domain, IP, protocol, and originating process before sending it to the selected outbound. Once this path is clear, the relationship between system proxy settings, LAN bypass rules, direct connections, and remote connections is much easier to understand.
download / platforms
Choose the section for your current operating system first, then select a client based on processor architecture and how you plan to use it. The homepage provides platform navigation only; package types, system requirements, and direct download links are documented on the download page.
desktop / v2rayN
For desktop use, start with v2rayN. The download page explains the interface differences, supported systems, and installation steps for the cross-platform desktop edition and the classic WPF edition, making it easier to choose for newer systems or existing devices.
Go to downloads →desktop / v2rayN
v2rayN desktop builds are available for Apple Silicon and Intel. Check the chip name in system information to choose the right one. The download page also covers first launch, configuration imports, and where to switch the system proxy.
Go to downloads →mobile / v2rayNG
For Android, v2rayNG with the Xray core is the default choice; v2flyNG is available if you prefer that core. Most current devices use arm64. If you are unsure of the architecture, see the download page’s guidance on choosing a universal package.
Go to downloads →desktop / v2rayN
v2rayN provides packages for common Linux distributions, separated into x64 and arm64 builds. Check whether your distribution uses deb or rpm, then select the matching architecture on the download page to avoid package-format errors during installation.
Go to downloads →config / anatomy
A configuration is made up of top-level fields with distinct responsibilities. Select a section in the directory to see what each field does, common values, where the setting appears in graphical clients, and the dependencies most often missed during edits.
config > inbounds
inbounds defines how the client accepts traffic from browsers, the system, or other applications. Common settings include
listen, port, protocol, and tag:
the listening address controls which devices can connect, the local port must match the system proxy settings, and the protocol is usually SOCKS or HTTP.
In v2rayN, this corresponds to the local listening port in parameter settings; in v2rayNG, it maps to the local proxy and VPN service entry points.
After changing the port, update any browser or application with a manually configured proxy address. Otherwise, the client may start successfully while traffic still bypasses the core.
config > outbounds
outbounds describes how traffic is handled after it leaves the local machine. A configuration usually includes remote proxy, direct, and blocked outbounds. Each receives a stable name through tag, which routing rules then reference. Remote outbounds also carry the protocol, server address, port, user parameters, and transport options. After importing a subscription, graphical clients generate the main outbounds automatically; users usually work with active server selection, transport settings, and core selection. When editing manually, first verify that tags match the routing rules so an existing outbound is not left unused.
config > routing > rules
routing determines which outbound receives a piece of traffic. Rules can match domains, IP ranges, ports, network types, inbound tags, or process names, then use outboundTag to select a proxy, direct, or blocked outbound.
v2rayN provides preset rule sets and custom-rule controls in its routing settings, while v2rayNG lets you adjust domain policies and rule order in its routing settings.
Matching generally depends on rule order, so precise rules should come before broad ones. After changes, use the logs to confirm the matched rule and final outbound.
config > dns
dns controls which resolution servers the core uses and which path different domains follow. Common settings include server lists,
hosts mappings, query strategies, and domain-specific resolvers. DNS is closely tied to routing: after a domain resolves to an address, IP rules may still participate in matching.
Graphical clients usually place these options under DNS settings, advanced routing settings, or a custom configuration area. When troubleshooting a domain that resolves but fails to connect,
check system DNS, client DNS, and routing domain policies separately rather than treating them as one setting.
config > log
log controls access logs, error logs, and output verbosity. Keep verbosity low for everyday use, then raise it temporarily when investigating connection failures,
incorrect routing, port conflicts, or subscription-generation errors. Both v2rayN and v2rayNG provide log viewers.
Focus on whether the listener started, whether the outbound connected, whether DNS returned a result, and which tag routing ultimately selected.
Logs may contain server addresses and local paths. Before sharing troubleshooting data, keep only lines relevant to the issue and remove personal connection parameters.
project v / ecosystem
Graphical clients, proxy cores, and configuration data operate at different layers. Separating their responsibilities makes it easier to understand the relationship between client updates, core selection, subscription content, and routing rules.
Project V established the basic structure of the V2Ray configuration model and modular networking tools. Configuration files divide inbound, outbound, routing, DNS, transport, and logging into connected modules, allowing multiple modules to be combined into a clear data path with tags. This structure works well for maintaining config.json by hand and for graphical clients that generate configurations from subscriptions and interface settings. As a result, the servers, proxy modes, routing presets, and local ports shown in a client interface ultimately map to corresponding configuration fields.
V2Fly continues to maintain V2Ray core capabilities, with an emphasis on modular configuration and protocol implementations. Xray has developed as an independent core within a related configuration model, and is used by multiple clients for connection and routing tasks. Neither is a graphical client; both are underlying cores called by clients. The same graphical client can organize features around different cores, and the same subscription may show details that differ in transport parameters, routing capabilities, or configuration syntax depending on the client and the supported core.
v2rayN, v2rayNG, v2flyNG, and the related cores are maintained by open-source communities. Open-source licenses define the boundaries for using, modifying, and redistributing code, while allowing protocol implementations, configuration parsing, and fixes to be reviewed publicly. For most users, the practical checklist is: download a client that matches the current system, read the release notes, keep a known-working configuration, and check the system proxy, routing, and core status after upgrading.
Client updates and core updates do not always arrive at the same time. The interface program handles subscription management, configuration editing, tray controls, and system integration; the core handles protocol connections, DNS, routing, and traffic processing. An update limited to the interface usually does not change existing connection methods; an update involving the core or configuration format warrants a review of custom routing, transport parameters, and compatibility with older configurations. For maintenance, record the client type, core in use, and key settings rather than only the software name. This makes troubleshooting much easier.
desktop
A desktop graphical client for Windows, macOS, and Linux, handling subscription management, server selection, system proxy settings, routing presets, TUN mode, and log viewing. When you need full control over system network settings on desktop, start with v2rayN.
android / xray
An Android client powered by the Xray core, with QR scanning, clipboard imports, subscription updates, per-app proxying, and routing controls. Choose it as the primary mobile option when you already use Xray-related parameters or need support for its protocol capabilities.
android / v2fly
An alternative Android client based on the V2Fly core, with an interface and common subscription workflow that will feel familiar. Choose it when you need to keep the V2Fly configuration model or compare behavior across different cores.
workflow / checklist
quick answers
Run a subscription update first. Then check that the subscription group is enabled, the link is complete, and the client logs show no parsing errors. See the complete subscription import steps.
System proxy mainly handles applications that follow the system proxy settings; TUN mode uses a virtual network interface to process a wider range of traffic. Read the TUN mode section before choosing.
First identify the process using the local listening port. Then change the client’s SOCKS or HTTP port and update the proxy settings in your browser and other applications. See port conflict troubleshooting.
For newer systems, start with the cross-platform desktop edition. If you rely on the classic interface and established workflow, compare it with the WPF edition. See the details on the client comparison page.
notes / latest
Each article focuses on a reproducible problem: it explains the trigger, then provides the setting path, checks, and recovery steps. When configuration structure is involved, it also explains each field’s role so graphical interface actions can be mapped to the core configuration.
A port conflict at client startup usually means that a commonly used listening port is occupied by another program. This article explains how to identify the process, change the local port in v2rayN parameter settings, and update the browser proxy accordingly.
Read the full article →Complete the Windows setup in order, from downloading and extracting the package to first launch and subscription import. The guide covers missing runtime components, an inactive system proxy, and how to choose between client versions.
Read the full article →Break down a minimal configuration to show how inbound receives local traffic, outbound establishes connections, and routing uses tags to direct different rules to selected outbounds.
Read the full article →