Subscription Import and Local Listening
Subscriptions fetch server configurations in bulk; they do not establish a connection by themselves. In v2rayN, save the full URL in a subscription group and update it. On Android, add a group first, then update the configurations. Once entries appear, select an active server and test the connection. The SOCKS inbound snippet below is separate from subscription data; listening on a loopback address accepts connections only from the local machine. If an update fails, check the subscription request logs rather than changing the inbound port to fix a remote URL.
{
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
]
}
Read the inbound configuration reference →
Routing Rules Are Evaluated in Order
Routing rules choose an outbound for each request; they don’t fix the server itself. Give proxy and direct outbounds clear tags, write specific rules first, and set the default route last. The example sends private addresses to an outbound tagged direct. That tag must exist in the full configuration, and the referenced rule data must be available. To diagnose unexpected routing, check earlier matching rules first, then see whether the domain has already resolved to an IP. Don’t infer the result from a rule’s name or change several rules at once.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}
Read the routing rules reference →
System DNS vs. the Core’s DNS
A website failing to load doesn’t necessarily mean the server is unavailable; DNS may not be following the expected path. First distinguish system DNS, an app’s own encrypted DNS, and the core’s built-in DNS, then check whether routing triggers resolution. The snippet below shows simplified fields for the core’s DNS servers; it does not mean every app’s queries will be intercepted. Compare logs and results before and after a change, adjusting one part of the resolution path at a time. With remote DNS, also confirm that the connection to the resolver works to avoid a dependency loop.
{
"dns": {
"servers": [
"1.1.1.1",
"8.8.8.8"
]
}
}
Read the DNS configuration reference →
TUN Traffic Capture and Loop Risks
TUN handles traffic through a virtual network interface, which can cover more apps, but requires compatible permissions, routing, and DNS settings. First confirm that a standard proxy connection works, then enable TUN in the client and observe changes to the virtual interface and system routes. The SOCKS inbound below is for local connection testing, not a TUN switch. TUN implementation and configuration depend on the client’s components; this JSON is not a virtual network interface configuration. If the network goes down, disable TUN, save the logs, and investigate.
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
}
]
}
Read about TUN and traffic capture →
Start with the First Error
A core that fails to start and a connection that times out after connecting are different failure stages and need separate checks. Find the earliest error in the same startup session. Check configuration syntax, port conflicts, and field compatibility before investigating the remote connection and TLS handshake. Temporarily increasing the log level can help reproduce the issue; restore the usual level afterward to avoid excessive output. The warning level captures warnings and errors. Before sharing logs, remove subscription URLs, authentication details, and real addresses; keep the error type and surrounding context.
{
"log": {
"loglevel": "warning"
}
}
Read the log and configuration troubleshooting guide →