Xray Log Levels: What to Log, What to Disable

To ensure maximum privacy on your self-hosted VPN server (e.g., using Xray, WireGuard, or Nginx), you can completely disable or significantly minimize the 50 to 500 MB of logs generated daily—which typically include IP addresses, connection times, and traffic volumes—by adjusting the `log level` or specific service configurations.

What are VPN Server Logs and Why You Should Control Them for Privacy

Every time you connect to your VPN server, establish a connection, or transfer data, the server software can potentially record information about these actions. These records are called logs. For a system administrator, logs are an invaluable tool for diagnosing problems, monitoring performance, and detecting anomalies. However, for a VPN user, especially one who values anonymity and privacy, logs pose a serious risk. They can contain sensitive data that, if improperly stored or if the server is compromised, could be used for de-anonymization.

Types of VPN Logs and Their Privacy Risks

On a typical VPN server, several main categories of logs can be identified: * **Access Logs:** These logs record information about every incoming or outgoing connection. For a VPN server, they might include: * **IP Addresses:** The client's IP address connecting to the VPN, and/or the IP addresses of resources the client accesses through the VPN. * **Timestamps:** The exact start and end times of a connection. * **Traffic Volume:** The amount of data transferred during a session. * **Ports:** Source and destination ports. * **Connection Status:** Whether the connection was successfully established, or if errors occurred. Potential Risk: These logs directly link your real IP address to your internet activity through the VPN. They are the primary threat to your `vpn logging policy`. * **Error Logs:** Contain records of any errors, warnings, or critical events that occurred on the server. * **Error Type:** Authentication error, network issues, misconfiguration. * **Timestamp:** The time the error occurred. * **Error Message:** Detailed description of the problem. Potential Risk: Usually do not contain direct user identifiers but can indirectly point to connection attempts or problems related to specific users. * **Debug Logs:** The most detailed logs, intended for developers and deep diagnostics. They include many internal details of program operation, often with excessive information. * **Detailed Traces:** Step-by-step code execution. * **Variable Values:** System state at specific moments. Potential Risk: Can accidentally capture sensitive data that should not have appeared in regular logs. Rarely used in production due to their large volume and potential for leaks. * **System Logs:** Operating system logs (e.g., `journalctl` in Linux) that can record events related to the VPN server, such as service startup/shutdown, network interfaces, and kernel messages. Potential Risk: May contain general information about network activity but rarely detail VPN traffic.

Commercial 'No Logs' vs. Self-Hosted 'No Logs' on Your Own VPS

When a commercial VPN provider claims a "no logs" policy, it means they promise not to store logs that could de-anonymize a user. This includes IP addresses, browsing history, traffic volumes, and timestamps. However, how can a user verify this promise? In most cases, they can't. You are forced to trust the provider, their audits (if any), and their jurisdiction. Commercial services are often under pressure from law enforcement, and their `vpn logging policy` can be changed without your knowledge or under duress. In contrast, when you set up a "no logs" configuration on your own VPS, you are in complete control. You manage every line of configuration, every logging parameter. If you correctly configure the server not to record sensitive data, then that data simply does not exist on disk. This provides a much higher level of confidence in privacy, as there is no third party to trust. You decide `what logs the server stores`, and you can be sure that no one else has access to them if you have taken all security measures. A detailed guide on deploying a VPN on your own VPS can be found in our main article on VPN on your own VPS: complete guide 2026.

What Logs Does Xray Store by Default and How to Disable Them?

Xray (or V2Ray) is a powerful toolkit for building proxy servers, supporting many protocols such as VMess, VLESS, Trojan, Shadowsocks, and others. By default, Xray generates two main types of logs: access logs and error logs. * **Access Logs (access.log):** Record information about each connection passing through Xray. This includes: * Client IP address (source). * Destination IP address (where the traffic goes). * Protocol and port used. * Volume of data transferred. * Timestamps. * User ID (if used). These logs are the most critical for privacy, as they directly link your activity to your real IP address. * **Error Logs (error.log):** Contain information about Xray errors, warnings, and other system events. They are important for diagnostics but usually do not contain de-anonymizing information unless a very high `xray log level` is enabled (e.g., `debug`).

Detailed Breakdown of `xray log level` and Its Impact on Privacy

Logging configuration in Xray is set in the `config.json` file within the `log` section. Here's what a standard section looks like:

{
  "log": {
    "access": "/var/log/xray/access.log",
    "error": "/var/log/xray/error.log",
    "loglevel": "warning"
  },
  // ... rest of Xray configuration
}

The `loglevel` parameter determines how detailed the error logs will be. Available values: * `debug`: The most detailed level. Includes all debugging information, which can be excessive and potentially expose sensitive data. Not recommended for production servers. * `info`: Informational messages, including service startup/shutdown, successful operations, and important events. * `warning`: Warnings about potential issues. * `error`: Only critical errors that may affect service operation. * `none`: Complete disabling of error logging. For maximum privacy, it is recommended to completely disable access logs and set the `loglevel` for errors to `warning` or `error` to retain the ability to diagnose critical problems without recording unnecessary data. To disable access logging and minimize error logs, modify the `log` section as follows:

{
  "log": {
    "access": null, // Disables access logging
    "error": "/var/log/xray/error.log", // Path to error logs
    "loglevel": "error" // Record only critical errors
  },
  // ... rest of Xray configuration
}

Setting `access` to `null` completely disables access log recording. Setting `loglevel` to `error` ensures that Xray will only record the most important error messages, minimizing volume and potential risk. After changing the configuration, remember to restart the Xray service: `sudo systemctl restart xray`. For those using the Marzban panel to manage Xray, logging settings are also available through the web interface, usually in global settings or specific node settings. Managing Xray via Marzban significantly simplifies the process, but it's important to understand that the panel itself may keep its own logs. You can learn more about Marzban installation in the article Marzban on VPS: Xray panel and multi-user installation. Also, if you use Xray as a system proxy, you should check out Linux desktop and your own VPS: sing-box and Xray as a system proxy.

WireGuard: Minimal Logging for a True 'No Logs' Setup

WireGuard is known for its simplicity, high performance, and minimalist design. One of the key aspects of its architecture is the emphasis on minimizing state and, consequently, minimizing logging. This makes WireGuard an excellent candidate for implementing a "no logs" setup.

WireGuard's Built-in Logging: What the Kernel Records

Unlike many other VPN protocols that operate in user space and can generate extensive logs, WireGuard is implemented as a Linux kernel module (or other OSes). This means it is inherently very "quiet." By default, WireGuard records only the most essential events to the kernel's system logs (accessible via `dmesg` or `journalctl`): * **Interface Startup/Shutdown:** Messages about the creation or deletion of a WireGuard interface. * **Key Handshakes:** Information about successful or failed key exchanges during connection establishment. This may include peer public keys and timestamps. * **Critical Errors:** Messages about failures in the kernel module's operation. It's important to note that WireGuard **does not log client IP addresses, traffic volumes, or specific user actions** by default. It does not maintain access logs in the way Xray or OpenVPN do. However, information about peer IP addresses is present in the WireGuard configuration file (`wg0.conf` or similar), and this information is part of the setup, not a log. If you want to ensure that WireGuard does not record excessive information even at the kernel level, you can manage the kernel's logging level. In Linux, this is done via `sysctl`. For example, you can reduce the kernel logging level to avoid recording even standard WireGuard messages:

sudo sysctl -w kernel.printk="3 4 1 3"

This sets the `printk` level to lower values, meaning only more important messages will appear in `dmesg` and `journalctl`. However, be cautious: too aggressive a reduction in kernel logging can make diagnosing other system problems difficult. Typically, WireGuard's default behavior is sufficient to ensure high privacy.

Managing WireGuard Logs at the System Level

While WireGuard itself is minimalist, the system tools that manage it can create their own logs. For example: * **`wg-quick`:** This script, used for quick WireGuard setup, can output messages to `stdout`/`stderr`, which can then be captured by `systemd` and recorded in `journalctl`. * **`systemd`:** If you run WireGuard as a `systemd` service (which is standard), all service output will be directed to `journalctl`. To minimize system logs related to WireGuard: 1. **Configure `systemd` for WireGuard:** In the WireGuard service unit file (`/etc/systemd/system/[email protected]`): * Ensure there are no excessive commands that might output a lot of information. * You can redirect `stdout`/`stderr` to `/dev/null` for commands if it doesn't hinder diagnostics. * Example (`ExecStartPre` to clear `dmesg` buffer before start, but this is an extreme measure):

        [Unit]
        Description=WireGuard via wg-quick(8) for %I
        After=network-online.target nss-lookup.target
        Wants=network-online.target nss-lookup.target

        [Service]
        Type=oneshot
        RemainAfterExit=yes
        ExecStartPre=/usr/bin/bash -c "dmesg -c > /dev/null 2>&1" # Clear dmesg buffer
        ExecStart=/usr/bin/wg-quick up %I
        ExecStop=/usr/bin/wg-quick down %I
        Environment=WG_ENDPOINT_RESOLUTION_RETRIES=infinity
        StandardOutput=null # Disable output to journalctl
        StandardError=null  # Disable error output to journalctl

        [Install]
        WantedBy=multi-user.target
        

**Warning:** Disabling `StandardOutput` and `StandardError` can significantly complicate problem diagnosis. Use with caution. 2. **Manage `journalctl`:** Regularly clear the system journal or configure it to store a minimal amount of data. This will be discussed in the "Log Management and Rotation" section. Overall, WireGuard is one of the best options for those seeking a "no logs" setup, as it is inherently designed with privacy and minimal logging in mind.

Nginx as a VPN Proxy: What Gets Logged in Access and Error Files?

Nginx is often used not only as a web server but also as a powerful reverse proxy server, including for obfuscating VPN traffic or providing access to Xray/VLESS via WebSockets with TLS. In such scenarios, Nginx also generates logs that can contain sensitive information. By default, Nginx records two main types of logs: * **Access Logs (access.log):** Record every request Nginx processes. For VPN traffic through Nginx, this might include: * The client's IP address connecting to Nginx. * The request timestamp. * The requested URL (e.g., WebSocket path). * HTTP method, response status. * Size of data transferred. * User-Agent and Referer (if transmitted). These logs, as with Xray, are critical for privacy, as they directly link the client's real IP address to their activity on the server. * **Error Logs (error.log):** Contain information about Nginx errors and warnings (e.g., SSL certificate issues, backend unavailability, configuration errors).

Configuring Nginx `access_log` and `error_log` for Maximum Privacy

For maximum privacy, it is recommended to completely disable Nginx access logs or configure them not to contain IP addresses. Error logs are best kept, but with a minimal level of detail, to allow for problem diagnosis. 1. **Disabling Access Logs:** You can disable `access_log` for the entire server or for a specific `server` or `location` block. For the entire server (in the `http` block):

    http {
        ...
        access_log off;
        ...
    }
    

For a specific `server` or `location` (e.g., for your Xray proxy server):

    server {
        listen 443 ssl;
        server_name your_domain.com;
        ...
        access_log off; # Disable access logs for this server
        error_log /var/log/nginx/your_domain_error.log warn; # Error logs, warn level
        ...
        location /your_websocket_path {
            proxy_pass http://127.0.0.1:10000; # Xray listening port
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
            # access_log off; # Can be disabled here if not disabled above
        }
    }
    

After changing the Nginx configuration, remember to check its syntax (`sudo nginx -t`) and reload the service (`sudo systemctl reload nginx`). 2. **Configuring Error Logs:** Error logs are best kept, but with a `warn` or `error` level to avoid filling the disk with unnecessary information.

    error_log /var/log/nginx/error.log warn;
    

Available levels for `error_log`: `debug`, `info`, `notice`, `warn`, `error`, `crit`, `alert`, `emerg`. `warn` or `error` are recommended. 3. **Custom Log Formats Without IP Addresses (if logging is necessary):** If for some reason you still need to keep access logs but without IP addresses, you can create a custom log format. This is less secure than complete disabling but can be useful for statistics without de-anonymization. In the `http` block:

    http {
        log_format main_no_ip '$time_local "$request" '
                              '$status $body_bytes_sent "$http_referer" '
                              '"$http_user_agent" "$http_x_forwarded_for"';
        access_log /var/log/nginx/access_no_ip.log main_no_ip;
        ...
    }
    

Here, `$remote_addr` (client IP address) has been excluded from the `main_no_ip` format. However, if Nginx is used as a proxy, the `X-Forwarded-For` header might still contain the client's IP address if it's passed by an upstream proxy. In such a case, ensure you are not logging this header or that it is cleared.

Log Management and Rotation: How to Ensure Your VPN's Privacy

Even if you've configured your VPN server for minimal logging, completely avoiding system logs or accidental records is virtually impossible. Furthermore, logs can accumulate, consuming disk space and potentially storing information longer than necessary. Effective log management and rotation are key elements to ensure long-term `vpn logging policy`.

`logrotate` for Automatic Log Cleaning and Archiving

`logrotate` is a standard Linux utility designed for automatic rotation, compression, and deletion of log files. It helps prevent disk overflow from logs and ensures that old logs are not stored indefinitely. Example `logrotate` configuration for Xray and Nginx logs (`/etc/logrotate.d/xray` and `/etc/logrotate.d/nginx`):

# Configuration for Xray
/var/log/xray/*.log {
    daily               # Rotate logs daily
    rotate 0            # Keep 0 rotated logs (delete old ones immediately)
    missingok           # Don't error if log file is missing
    notifempty          # Don't rotate if log file is empty
    compress            # Compress rotated logs (not relevant with rotate 0)
    delaycompress       # Delay compression until the next cycle (not relevant with rotate 0)
    create 0640 root adm # Create new log file with specified permissions
    postrotate          # Commands to execute after rotation
        systemctl reload xray > /dev/null 2>&1 || true
    endscript
}

# Configuration for Nginx (if you still decide to keep error logs)
/var/log/nginx/*.log {
    weekly              # Rotate logs weekly
    rotate 4            # Keep 4 rotated logs (i.e., for the last month)
    size 10M            # Rotate if size exceeds 10 MB
    compress            # Compress rotated logs
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        if [ -f /run/nginx.pid ]; then
            kill -USR1 `cat /run/nginx.pid`
        fi
    endscript
}

**Explanation of `logrotate` parameters:** * `daily`, `weekly`, `monthly`: Rotation frequency. * `rotate N`: Number of rotated logs to keep. `rotate 0` means the old log will be deleted immediately after rotation. This is the most aggressive approach for privacy. * `size N`: Rotate if the file size exceeds N (e.g., `size 10M`). * `compress`: Compress rotated logs. * `notifempty`: Do not rotate empty files. * `create MODE OWNER GROUP`: Create a new log file with specified permissions. * `postrotate`/`endscript`: Commands executed after rotation. For Xray, this might be a service reload; for Nginx, sending a `USR1` signal to reopen log files without restarting the service. For maximum privacy, if you don't need historical logs for debugging, set `rotate 0` for all critically important logs.

Monitoring and Deleting System Logs (`journalctl`)

`journalctl` is a utility for working with the `systemd` journal. By default, `journalctl` stores logs in a binary format and can occupy significant disk space. It's important to regularly check and clear the journal. 1. **View `journalctl` disk usage:**

    sudo journalctl --disk-usage
    

This will show how much space journal logs are occupying. 2. **Clear journal by size:**

    sudo journalctl --vacuum-size=50M
    

Deletes old entries until the total journal size is reduced to 50 MB. 3. **Clear journal by time:**

    sudo journalctl --vacuum-time=7d
    

Deletes entries older than 7 days. 4. **Completely disable persistent journal storage (not recommended for most systems):** If you want `journalctl` to store logs only in RAM and not write them to disk (i.e., logs will be lost after reboot), edit the `/etc/systemd/journald.conf` file:

    [Journal]
    Storage=volatile
    

Then restart the `systemd-journald` service: `sudo systemctl restart systemd-journald`. **Warning:** This will significantly complicate problem diagnosis after a server reboot and is not recommended unless you have very specific security and privacy requirements. By combining application log disabling, `logrotate`, and `journalctl` management, you can achieve a very high level of "no logs" setup on your VPS.

For 20-50 concurrent VPN users, 2 vCPU, 4-8 GB RAM, and a 40-80 GB NVMe disk are sufficient.

Users	vCPU	RAM	Disk	Port	Approx. VPS Price ($/month)
1-5 (Personal)	1	1-2 GB	20-40 GB NVMe/SSD	1 Gbps	$3-7
5-20 (Family/Small Office)	2	2-4 GB	40-60 GB NVMe	1 Gbps	$7-15
20-50 (Medium Office/Community)	2-4	4-8 GB	60-80 GB NVMe	1-2.5 Gbps	$15-30
50-100 (Large Office/High Traffic)	4-6	8-16 GB	80-160 GB NVMe	2.5-10 Gbps	$30-60
100+ (Very High Traffic/Dedicated)	6-8+	16-32+ GB	160+ GB NVMe	10 Gbps	$60+ (up to $150+ for Dedicated)

'No Logs' Policy: The Myth of Commercial Services and the Reality of Your Own VPS

The "no logs" concept has become a cornerstone of marketing for many commercial VPN providers. They promise complete anonymity, claiming not to store any records of your activity. However, in practice, this `vpn logging policy` often proves more complex than it seems.

Why a VPN Provider's 'No Logs' Claim is Often Just a Promise

There are several reasons why a commercial VPN service's "no logs" policy might not be as reliable as it appears: 1. **Third-Party Trust:** You fully trust the company, its employees, its infrastructure, and its promises. Even if the company genuinely strives not to keep logs, human error, configuration mistakes, or internal policies can lead to their unintentional recording. 2. **Jurisdiction and Legislation:** VPN providers operate in specific jurisdictions that may have laws requiring them to store certain data or cooperate with law enforcement. In some countries, courts can issue warrants to begin logging without notifying users. 3. **Audits:** Some VPN providers undergo independent audits to confirm their "no logs" policy. This increases trust, but an audit is a snapshot of the state at a specific point in time, and it does not guarantee continuous compliance with the policy. 4. **Basic Operational Logs:** Even if a provider doesn't store activity logs, they often need to collect minimal operational data to maintain the service (e.g., number of concurrent connections, overall server load, bandwidth usage). While this data is usually anonymized, the line between "operational" and "identifying" logs can be thin. In the case of a commercial VPN, you are always in a position where you have to take their word for it. You can read more about how to choose a VPS with anonymous payment for VPN, which can help ensure your privacy, in the article VPS with anonymous payment for VPN: cryptocurrency and privacy.

Full Control Over Your `vpn logging policy` on Valebyte.com

The situation changes dramatically when you use your own VPS from Valebyte.com to deploy a VPN. In this case, a "no logs" setup becomes a reality, not just a marketing promise. * **You are the sole administrator:** You have full root access to the server. No one but you can change the VPN software configuration, install or remove applications, or view files on the disk. * **Direct control over configuration:** You decide what and how to log. As shown above, you can completely disable access logs for Xray, configure WireGuard for minimal kernel logging, and ensure Nginx does not record IP addresses. * **Physical control over data:** Your logs are stored on your disk, over which you have complete control. You can configure `logrotate` to immediately delete logs or even completely disable their recording. * **No legal pressure on you as a provider:** You are not a commercial VPN provider, and you are not subject to the same data retention laws or cooperation with law enforcement as large companies. Your `vpn logging policy` is your personal policy. Thus, using your own VPS from Valebyte.com for VPN gives you an unprecedented level of control over privacy and `what logs the server stores`. This is a fundamental difference from any commercial VPN service.

What Your Host and ISP See, Even with All Logs Disabled

Even if you have perfectly configured your VPN server to completely disable all logs, it's important to understand that your hosting provider (in our case, Valebyte.com) and your home Internet Service Provider (ISP) will still see certain information about your traffic. This is not `what logs the server stores` in terms of your activity within the VPN, but it is important metadata.

Traffic Metadata: Volumes, Times, Connection IP Addresses

1. **Your Internet Service Provider (ISP):** * **Destination IP Address:** Your ISP always knows that your home IP address connects to the IP address of your VPS server. * **Timestamps:** The ISP sees when you establish a connection to the VPS and how long it lasts. * **Traffic Volume:** The ISP knows how much data you transfer between your home and your VPS. * **Encrypted Traffic:** The ISP sees that the traffic is encrypted (e.g., by characteristic VPN ports or TLS handshake) but cannot read its content. * **Protocol:** In some cases, with deep packet inspection (DPI), the ISP can determine that you are using a VPN protocol (WireGuard, OpenVPN, Xray), even if it is obfuscated. The ISP does not see what you do *inside* the VPN tunnel (which websites you visit, which services you use), but it does see that you are using a VPN and communicating with a specific server. 2. **Hosting Provider (Valebyte.com):** * **IP Addresses Connecting to VPS:** The host sees the IP addresses that establish connections to your VPS server. This means it knows the IP addresses of your VPN clients. * **Traffic Volume:** The host monitors the total volume of incoming and outgoing traffic on your VPS for billing and network management. * **Resource Usage:** The host sees CPU, RAM, and disk usage on your VPS. * **Open Ports:** The host can see which ports are open on your VPS and which services are listening on them (e.g., 443 for Nginx/Xray, WireGuard port). Valebyte.com, like any other host, provides you with a clean environment but has access to metadata at the network infrastructure level. We do not monitor the content of your traffic or keep logs of your activity within the VPS, but network logs at the data center level may contain information about external connections to your server. This is standard practice for any hosting provider.

Technical Limitations on Hiding Network Activity

It is technically impossible to completely hide the fact that you are using a VPN from your ISP or host, as they are intermediaries in data transmission. Your goal when setting up a "no logs" configuration is to ensure that the *VPN server itself* does not store detailed logs of your activity that could be used for de-anonymization. It's important to understand that the host does not have access to your internal Xray, WireGuard, or Nginx configuration unless you explicitly grant it. It does not read your log files that you have configured to `rotate 0` or `off`. Your privacy within the VPN tunnel remains protected, but the fact of connecting to a VPN server is visible at the network infrastructure level. For scenarios with very high load or specific bandwidth requirements, where 100 Mbps is no longer enough, it's worth considering VPS or dedicated server for VPN, where control over the network and resources is even more complete.

Frequently Asked Questions

Which logs are most critical for privacy on a VPN server?

The most critical logs for privacy on a VPN server are access logs. They contain client IP addresses, connection timestamps, information about visited resources, and transferred traffic volumes. This data can be used to de-anonymize a user by linking their real IP to online activity. It is recommended to completely disable or minimize such logs.

Can logging be completely disabled in Xray?

Yes, in Xray, you can completely disable access logging by setting the `"access": null` parameter in the `config.json` configuration file. Error logs can be minimized by setting the `loglevel` to `error` or `warning` to retain only critically important messages for diagnostics without recording excessive information.

How much disk space do VPN server logs occupy?

The disk space occupied by VPN server logs can vary from several megabytes to several gigabytes per day, depending on traffic intensity and logging level. For example, with `loglevel: debug` and active traffic, Xray can generate hundreds of MB of logs daily, while WireGuard with minimal kernel logging only takes up a few KB in the system journal.

What does 'no logs' mean on a self-hosted VPS?

"No logs" on a self-hosted VPS means that you, as the sole administrator of the server, have complete control over what data is recorded. You can configure the VPN service (Xray, WireGuard) and system utilities so that they do not store sensitive information, such as client IP addresses or their activity history. This provides much greater confidence in privacy compared to commercial VPN services, where you are forced to trust a third party.

How often should VPN logs be rotated?

The frequency of VPN log rotation depends on your privacy requirements and the volume of logs generated. For maximum privacy, it is recommended to configure `logrotate` for daily deletion of old logs (`rotate 0`). If you still keep logs for diagnostics, you can set up weekly rotation, storing 1-4 rotated files, which will provide a history for 1-4 weeks.

Conclusion

To ensure maximum privacy on your self-hosted VPN server, it's crucial to actively manage its logs by completely disabling access logs in Xray and Nginx, and minimizing WireGuard's system entries. Utilizing `logrotate` with the `rotate 0` parameter and regularly clearing `journalctl` will guarantee that sensitive data is not stored on disk. This provides a true "no logs" setup, surpassing the promises of commercial VPN providers, even though your hoster and ISP will always see your connection's metadata.