Introduction: Beyond Inbounds and Outbounds
While Articles 1-5 established the core functions of Inbounds, Outbounds, and Routing—which are the basic engine of V2Ray—a professional setup also needs an understanding of four other important root-level objects: log, dns, policy, and transport. These parts are essential because they manage the stability, ability to bypass censorship, and overall speed of your V2Ray instance.
Understanding these less-talked-about sections transforms V2Ray from a basic connection tool into a robust network service that is always being checked and maintained. These components handle the critical, behind-the-scenes work. We will now explain the purpose and simple configuration of each of these control objects within the main config.json file.
Section 1: The Log Section (Checking Your Security and Finding Problems)
The log object is very important for two main jobs: watching the health of your server and figuring out why connections are failing. Without proper logging, if a firewall blocks you or a protocol doesn’t match, it is almost impossible to figure out what went wrong.
Key Log Settings
| Setting | Type | Description | Best Practice |
|---|---|---|---|
access | string | The file path for the access log. This records every connection attempt (if it worked or failed). | Use /var/log/v2ray/access.log |
error | string | The file path for the error log. This records important warnings, serious errors, and system failures. | Use /var/log/v2ray/error.log |
loglevel | string | How much detail is written to the error file. High detail uses more server power. | warning for normal use, debug for fixing problems. |
Loglevels for Operation
Choosing the right loglevel determines how much information V2Ray must use server resources to write. This affects both your server’s speed and the amount of disk space consumed.
warning(Recommended for Production): Logs only critical failures and non-fatal but serious issues. This level saves disk space and CPU power while still alerting you to security problems. It is the best balance for a live server.info: Logs general status updates, including when users successfully connect and routine operations. Use this only when you need a little more detail thanwarning.debug(Recommended for Troubleshooting): Logs the most verbose internal details, including every packet header and every protocol change. Do not use in production as it consumes excessive disk space, slows the server down, and is only needed for advanced problem-solving.
Practical Example: Setting Log Warning Level
This example directs V2Ray to save connection data and error messages to specific files, while keeping the level of detail low for speed.
"log": {
"loglevel": "warning",
"access": "/var/log/v2ray/access.log",
"error": "/var/log/v2ray/error.log"
}
Section 2: The DNS Section (Fighting Against Censorship)
The dns section tells V2Ray how to find the real internet address (the IP address) for a website name (like https://www.google.com/search?q=google.com). This is a vital layer of fighting against blocks, because many advanced firewalls use a trick called DNS poisoning—it’s like sending V2Ray a fake address book entry for a blocked site to prevent the connection.
The Problem of Local DNS
If V2Ray uses the standard DNS settings from your Operating System (which usually comes from your local Internet Provider, or ISP), it is easily tricked by DNS poisoning. The correct IP address will never be found, and your traffic will be routed incorrectly or simply blocked.
The Solution: V2Ray’s Internal DNS Client
By setting up V2Ray’s own DNS client, you can force all name-lookup requests to use a reliable, secure, and often encrypted external DNS resolver. This completely bypasses any local interception or fake addresses. This ensures V2Ray always gets the truth about where to send traffic.
Practical Example: Using Secure External DNS
This configuration tells V2Ray to use highly trusted, fast resolvers from Cloudflare and Google. It also shows how to use DNS over HTTPS (DoH) for maximum security and domain-specific routing.
"dns": {
"servers": [
"1.1.1.1", // Cloudflare DNS (Very fast and private)
"8.8.8.8", // Google DNS (Reliable secondary choice)
{
"address": "[https://208.67.222.222/dns-query](https://208.67.222.222/dns-query)", // Use DNS over HTTPS (DoH) for high security
"port": 443,
"domains": ["geosite:cn"] // This resolver only handles domain names related to China
},
"localhost" // Fallback to local system DNS (used only as a last resort)
],
"tag": "dns_external" // Gives this DNS setup a name for use in routing rules
}
Tip: For advanced routing, you can create a rule that sends all standard Port 53 (UDP) DNS requests directly to this secure internal DNS setup.
Section 3: The Policy Section (User and Server Power Management)
The policy section is where administrators set rules for how much server power (resources) users can consume and how long connections can stay open. This is essential for protecting the server’s stability and defending against attacks that try to crash the server (Denial-of-Service or DoS).
Key Policy Settings (Levels)
Policies are based on a user’s numerical Level (usually Level 0 is the default for all users). You can create different levels (e.g., Level 1 for VIP users) to give them better access or stricter limits.
| Setting | Applies To | Description | Typical Adjustment |
|---|---|---|---|
connectionIdle | Global/User | The maximum time an active connection can be completely silent before V2Ray closes it. | Lowered to about 180 seconds (3 minutes) to free up memory from unused connections. |
handshake | Global/User | The maximum time allowed for the initial protocol setup when a connection starts. | Lowered to 4 seconds to quickly stop half-open attacks where the connection is started but never finished. |
bufferSize | Global/User | Sets the internal data storage size (buffer) for each connection. | Increased for high-speed servers to improve transfer rates, or decreased for servers with limited memory. |
downlinkOnly | Global/User | Max time to keep a connection open if only data is being downloaded. | Prevents users who are only streaming video from holding server memory after the video buffer is full. |
uplinkOnly | Global/User | Max time to keep a connection open if only data is being uploaded. | Useful for managing resources when users are only uploading large files. |
Practical Example: Aggressive Idle Timeout
This policy applies strict, faster-than-default timeouts to the main user group (Level 0) to ensure the server remains fast and responsive.
"policy": {
"levels": {
"0": {
"handshake": 4, // Strict handshake timeout (fast block of DoS attempts)
"connectionIdle": 180, // Close silent tunnels after 3 minutes to save memory
"downlinkOnly": 300, // 5 minutes max if only downloading
"uplinkOnly": 300, // 5 minutes max if only uploading
"bufferSize": 524288 // 512 KB buffer for good performance
}
},
"system": {
"statsInboundUplink": true // This turns on the ability to track how much data is being used by users
}
}
Section 4: The Transport Section (Global Basic Rules)
The optional transport section sets the basic, default rules for how V2Ray sends data using all transport protocols (TCP, mKCP, WebSocket, QUIC). These basic settings can be changed later by more specific streamSettings within an individual Outbound connection (meaning local rules beat global rules).
Global Transport Control
While often left empty, expert users can use this section to set default values for low-level network options, such as sockopt, across the entire V2Ray instance. This is useful for ensuring every connection has a consistent network behavior without having to set the rule for every Outbound.
"transport": {
"tcpSettings": {
"header": { "type": "none" } // TCP connections globally have no extra header
},
"kcpSettings": {
"header": { "type": "dtls" } // All mKCP connections default to DTLS obfuscation for hiding traffic
}
}
Conclusion: By actively managing the log, dns, policy, and transport sections, you move your V2Ray instance beyond a simple tunnel. It becomes a robust, high-performance, and intelligently controlled network proxy. These configuration elements are the silent defenders of your server’s stability and security, making sure server power is used wisely and that potential threats or problems are quickly recorded and fixed.
Next Up: Article 7 will explore the built-in workhorse protocols: Freedom and Blackhole Outbounds.