NaiveProxy on VPS with Caddy: Bypass DPI & Censorship

To deploy NaiveProxy on your server and bypass DPI that analyzes TLS fingerprints, you will need a VPS running Ubuntu 22.04 LTS or similar OS, along with the Caddy web server installed with the forwardproxy module to handle the protocol requests.

In a world where Deep Packet Inspection (DPI) systems are becoming increasingly sophisticated, standard blocking circumvention methods often prove ineffective. Protocols that only mask traffic content but leave noticeable "fingerprints" at the TLS handshake level are easily detected and blocked. This is where NaiveProxy steps in – an innovative solution designed to combat the most advanced DPI systems.

What is NaiveProxy and How Does it Bypass DPI?

NaiveProxy is a proxy protocol that employs a unique approach to bypass blocks: it mimics the network fingerprint of a regular Google Chrome browser. Unlike most other protocols that focus on data encryption and obfuscation, NaiveProxy goes further. It doesn't just mask traffic content; it replicates the entire Chromium network stack, including specific TLS handshake parameters, HTTP/2 headers, and even the temporal delays characteristic of a real browser.

Mimicking the Chromium Network Stack: The Key to Stealth

The core idea behind NaiveProxy is that to DPI, it appears as a regular browser requesting a legitimate web resource. DPI systems that analyze TLS fingerprints (e.g., using the JA3 library or similar methods) perceive NaiveProxy traffic as indistinguishable from ordinary web surfing via Chrome. This is achieved through several key features:

• TLS Fingerprint: NaiveProxy precisely reproduces the TLS Client Hello sent by the Chrome browser. This includes the cipher order, TLS extensions and their parameters, and other details that form a unique "fingerprint."
• HTTP/2 Headers: The protocol uses HTTP/2 and formats headers to perfectly match those generated by Chrome.
• Realistic Behavior: NaiveProxy mimics browser behavior during connection establishment, including delays and error handling, making it even more convincing to traffic analysis systems.

This is a fundamental difference from protocols that, while encrypting data, might have unique TLS fingerprints that betray them as proxy connections. For advanced DPI systems, such "unusual" fingerprints are a red flag leading to blocking. NaiveProxy, however, blends in with the mass of ordinary web traffic, becoming virtually invisible.

Why NaiveProxy is the Best Choice for Strict DPI?

The choice of protocol for bypassing DPI depends on the specific blocking conditions. While many modern solutions offer high performance and protection, NaiveProxy stands out for its specialization in circumventing systems that analyze connection metadata, not just its content.

NaiveProxy vs Trojan, Shadowsocks, and Other Protocols

Let's examine how NaiveProxy differs from popular protocols like Trojan, Shadowsocks, or even Hysteria2, in the context of strict DPI:

• Shadowsocks: Originally designed for simple encryption and obfuscation. While plugins exist (e.g., v2ray-plugin) that attempt to mimic TLS, basic Shadowsocks has its recognizable fingerprint and can be easily detected by systems actively analyzing TLS handshakes.
• Trojan: A protocol that masquerades as regular HTTPS traffic using standard TLS. This makes it resistant to basic DPI. However, if a DPI system performs deep analysis of TLS fingerprints (e.g., JA3, JA4), it can still identify Trojan as a non-browser TLS client, as its TLS fingerprint is not identical to that of a real browser.
• Hysteria2: A high-performance protocol based on QUIC, designed to bypass UDP shaping and ensure stable operation under high packet loss. It also uses TLS, but its main advantage is speed and resilience to unstable networks, not browser fingerprint imitation. For DPI analyzing TLS fingerprints, Hysteria2, like Trojan, can be recognized as a non-browser client.
• NaiveProxy: Deliberately mimics not only TLS but the entire Chromium network stack. This means that for DPI looking for anomalies in TLS fingerprints, NaiveProxy appears exactly like a regular Google Chrome. This is its primary and unique advantage in combating the most advanced DPI systems that actively use such analysis methods. If you want to learn more about how to tell if DPI is blocking your VPS, check out our article.

Thus, if you are encountering blocks that appear to be based on the analysis of TLS fingerprints and connection metadata, rather than just content or IP address, NaiveProxy may prove to be the most effective solution. It doesn't just hide your activity; it makes it indistinguishable from the most common and legitimate activity – web surfing via Chrome.

Preparing Your VPS for NaiveProxy Setup

For a successful NaiveProxy setup, you'll need a reliable VPS. Choosing the right server configuration and its initial preparation is a crucial step.

Choosing the Optimal Naive Proxy VPS

When choosing a VPS for NaiveProxy, it's important to consider several factors:

• Location: Choose a VPS in countries with minimal internet traffic restrictions and good connectivity to your location. This will ensure low latency and high speed.
• Operating System: Linux distributions such as Ubuntu Server (20.04 LTS or 22.04 LTS), Debian (11 or 12), or CentOS Stream 9 are recommended. These systems are well-documented, stable, and have extensive package support.
• Resources: NaiveProxy itself is not a resource-intensive protocol, but the Caddy web server, which will be used, requires certain resources.

For 5-10 concurrent users, 2 vCPU, 2 GB RAM, and a 40 GB NVMe disk are sufficient.

Initial Server and Domain Setup

Before installing NaiveProxy and Caddy, you need to perform basic VPS setup:

1. System Update: Always start by updating the package list and installed packages.

   sudo apt update && sudo apt upgrade -y

2. Domain Setup: For NaiveProxy to work with Caddy, you will need a domain name. Register a domain (e.g., yourdomain.com) and configure an A-record pointing to your VPS's IP address. This is critical because Caddy automatically issues TLS certificates using Let's Encrypt, which requires an active domain.
3. Firewall Configuration (UFW): It is recommended to configure a firewall for enhanced security. Allow SSH (port 22), HTTP (port 80), and HTTPS (port 443).

   sudo ufw allow ssh
   sudo ufw allow http
   sudo ufw allow https
   sudo ufw enable

Quick pick

Need a dedicated server?

Bare metal with NVMe in 70+ locations — configure and order in minutes.

Browse servers

Installing Caddy with forwardproxy for NaiveProxy

Caddy is a powerful web server with automatic HTTPS configuration, which is ideal for NaiveProxy setup due to its simplicity and modular architecture. We will need to install Caddy along with the forwardproxy module.

Installing Caddy on Ubuntu/Debian

Caddy can be installed from its official repository. Execute the following commands:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

After installation, Caddy will be started as a system service.

Compiling Caddy with the forwardproxy Module (If Not Included in Standard Package)

In some cases, the standard Caddy package might not include the forwardproxy module. If this happens, you'll need to compile it manually. This is a more complex process but provides full control over the modules. For most users, however, installing Caddy from the repository and checking for the module's presence will suffice.

To check if the forwardproxy module is present in your Caddy installation, run:

caddy list-modules | grep forwardproxy

If the command returns nothing, you will need to compile Caddy. The easiest way to do this is using xcaddy:

sudo apt install -y build-essential libnss3-dev
go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest
~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy@caddy_v2

Then, replace the standard Caddy binary with the compiled one:

sudo systemctl stop caddy
sudo cp caddy /usr/bin/caddy
sudo systemctl start caddy

Now Caddy is ready to work with NaiveProxy.

Configuring NaiveProxy on the Server: User Creation

The main NaiveProxy configuration is done via the Caddyfile. Here, we will define the domain, port, and user credentials.

Caddyfile Configuration for NaiveProxy

Open the Caddy configuration file: sudo nano /etc/caddy/Caddyfile and replace its content with the following:

yourdomain.com {
    tls [email protected]
    route {
        forward_proxy {
            basic_auth {
                user1 your_password1
                user2 your_password2
                # Add more users as needed
            }
            hide_ip
            hide_via
            probe_resistance
        }
        reverse_proxy https://www.google.com {
            header_up Host {upstream_host}
            header_up X-Forwarded-Host {host}
        }
    }
}

Caddyfile Explanations:

• yourdomain.com: Replace with your domain name.
• tls [email protected]: Caddy will automatically obtain an SSL/TLS certificate from Let's Encrypt for your domain. Provide a real email for notifications.
• basic_auth: Here you define username password pairs for your users. Each user should be on a separate line.
• hide_ip: Hides the client's IP address from the upstream server.
• hide_via: Removes the Via header, which can reveal a proxy.
• probe_resistance: Adds resistance to probing by DPI. If someone tries to connect to your domain without the correct NaiveProxy credentials, Caddy will appear as a regular web server serving www.google.com.
• reverse_proxy https://www.google.com: This is a "decoy." If a request does not match NaiveProxy, Caddy will redirect it to Google to appear as a regular web server. You can replace https://www.google.com with any other legitimate website.

Applying Changes and Checking Status

After saving the Caddyfile, you need to validate its syntax and reload Caddy:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
sudo systemctl status caddy

Ensure that the Caddy service is running and operating without errors. If issues arise, check the logs: sudo journalctl -u caddy --no-pager.

Your NaiveProxy server is now configured and ready to accept connections.

NaiveProxy Client: Setup and Connection on Desktop and Mobile Devices

After configuring the NaiveProxy server, the next step is to set up client devices. NaiveProxy functions as a regular HTTP/2 proxy with TLS, so you can use both specialized clients and standard system proxy settings.

Client Setup on Desktop (Windows, macOS, Linux)

For desktop operating systems, there are several ways to connect to NaiveProxy.

Via Chromium Browser (Simplest Method)

The most natural way to use NaiveProxy is through Chromium-based browsers (Google Chrome, Microsoft Edge, Brave, etc.). You will need a proxy management extension, such as "SwitchyOmega" or "Proxy Helper."

1. Install the Extension: Find "SwitchyOmega" or a similar extension in your browser's extension store and install it.
2. Configure a New Proxy Profile:
   • In the extension settings, create a new profile (e.g., "NaiveProxy").
   • Protocol Type: HTTPS (or HTTP; some NaiveProxy clients use HTTP, but Caddy always processes it as HTTPS thanks to the tls directive).
   • Server: Enter your domain (e.g., yourdomain.com).
   • Port: Usually 443 (standard HTTPS port).
   • Enable the "Do not prompt for authentication" or "Always authenticate" option and enter the username and password you set in the Caddyfile (e.g., user1 and your_password1).
3. Activate the Profile: Select the created "NaiveProxy" profile in the extension to start using the proxy.

Dedicated Clients

There are also specialized NaiveProxy clients that can provide system-wide proxying or more granular configuration. For example, for Windows, you can use a client included with V2RayN or Clash for Windows, where NaiveProxy is supported as one of the protocols. In these cases, you specify the protocol type as naive, the server address, port, username, and password.

Client Setup on Mobile Devices (Android, iOS)

On mobile platforms, using NaiveProxy is also possible, though it may require installing third-party applications.

Android

For Android, it is recommended to use client applications that support NaiveProxy, such as V2RayNG, Clash for Android, or NekoBox. These applications allow flexible configuration of proxy connections.

1. Install the App: For example, V2RayNG from the Google Play Store.
2. Add NaiveProxy Configuration:
   • In the app, tap the "plus" icon to add a new profile.
   • Select "NaiveProxy" as the protocol type.
   • Enter your server domain, port (443), username, and password.
   • Save the configuration.
3. Activate the Connection: Select the created profile and activate the VPN connection in the app.

Applications like V2RayNG create a local VPN connection that routes all traffic through NaiveProxy. If you're looking for other solutions, Hysteria2 on a VPS is also an excellent option for bypassing DPI.

iOS

On iOS, clients supporting NaiveProxy are also available, such as Shadowrocket, Quantumult X, or Stash. The setup principle is similar to Android:

1. Install the App: For example, Shadowrocket from the App Store.
2. Add NaiveProxy Configuration:
   • In the app, go to the "Configuration" or "Servers" section.
   • Add a new server, select "NaiveProxy" as the type.
   • Specify the server domain, port (443), username, and password.
   • Save.
3. Activate the Connection: Select the created server and enable the proxy.

It's important to ensure that the NaiveProxy client used on the mobile device also mimics the Chromium network stack for maximum effectiveness against DPI.

Quick pick

Need a dedicated server?

Bare metal with NVMe in 70+ locations — configure and order in minutes.

Browse servers

When is NaiveProxy Your Best Choice?

NaiveProxy is not a universal solution for all blocking circumvention scenarios, but under specific conditions, it performs best, outperforming many other protocols.

Scenarios with Strict DPI and TLS Fingerprint Analysis

NaiveProxy's main advantage becomes apparent where DPI systems actively analyze not only traffic content but also its metadata, particularly TLS fingerprints. If you encounter the following signs, NaiveProxy might be your salvation:

• Blocking of Popular VPN/Proxy Protocols: If WireGuard, OpenVPN, Shadowsocks, Trojan, V2Ray, or Hysteria2 are blocked quickly, even with obfuscation. This may indicate that DPI identifies them by unique TLS fingerprints or other behavioral patterns that differ from regular browser traffic. Our article on Zapret on VPS and Router also covers similar issues.
• Blocking After a Time Delay: If your server works for a while and then gets blocked, this could be a result of behavioral analysis, where DPI accumulates data and determines that the traffic is not browser-like.
• Inability to Establish a TLS Connection: If clients cannot establish a TLS handshake with your server, even if ports are open, this may be a sign of active DPI interference in the TLS certification process.
• DPI Using Machine Learning: Modern DPI systems can use machine learning to detect anomalies in traffic. Mimicking the Chromium network stack makes NaiveProxy traffic "normal" for such systems.

Under such conditions, where DPI is "smart" and capable of distinguishing different types of TLS traffic, NaiveProxy becomes one of the few protocols capable of effectively bypassing such blocks, as it literally "pretends" to be a regular browser. This is especially relevant for regions with the strictest internet restrictions, where state-level DPI systems, such as the "Great Firewall" or its equivalents, are used.

Drawbacks of NaiveProxy: An Honest Look

Despite its unique advantages in bypassing advanced DPI, NaiveProxy also has its limitations, which are important to consider when choosing a protocol.

Limitations and Potential Issues

1. Smaller Client Ecosystem: Compared to protocols like Shadowsocks, V2Ray, or WireGuard, NaiveProxy's ecosystem is significantly smaller. This means the choice of client applications might be limited, and support less widespread. Finding ready-to-use, convenient clients for all platforms can be more challenging.
2. More Complex Updates and Maintenance: Since NaiveProxy often requires compiling Caddy with a specific module, the server update process can be more complex than a simple apt upgrade. This demands more technical knowledge and time to keep the server up-to-date.
3. Potentially Lower Speed with Packet Loss: NaiveProxy is based on HTTP/2 over TCP. In unstable network conditions with high packet loss, TCP performance can significantly degrade. Protocols based on QUIC (e.g., Hysteria2), which operate over UDP and have their own loss recovery mechanisms, often show better performance in such conditions. For maximum performance in unstable networks, consider Hysteria2 with port hopping.
4. Dependency on Caddy: NaiveProxy is tightly integrated with Caddy. This means you depend on the updates and stability of Caddy and its forwardproxy module. Any changes in Caddy may require adjustments to your NaiveProxy configuration.
5. Higher Resource Requirements: While NaiveProxy itself is not very resource-intensive, Caddy, especially with TLS encryption and HTTP/2 handling, can consume slightly more RAM and CPU compared to minimalistic proxy servers. For small VPS with 512 MB RAM, this can be noticeable.
6. Potential Future Identification Risks: Although NaiveProxy is highly effective now, DPI systems are constantly evolving. If DPI begins to analyze other behavioral patterns beyond TLS fingerprints (e.g., specific request sequences or their frequency) that even NaiveProxy cannot fully imitate, its effectiveness might decrease.

Thus, NaiveProxy is a powerful tool for specific tasks, but its implementation requires a conscious approach to management and an understanding of its trade-offs.

Frequently Asked Questions

Can I use NaiveProxy without a domain?

No, NaiveProxy requires an active domain name. This is because the protocol uses HTTPS, and Caddy automatically obtains TLS certificates from Let's Encrypt, which necessitates a domain pointing to your VPS's IP address. Without a domain, Caddy cannot obtain a certificate, and NaiveProxy will not function correctly.

How secure is NaiveProxy?

NaiveProxy uses standard TLS encryption, making it secure in terms of data confidentiality. The primary "security" of NaiveProxy lies in its ability to masquerade as regular browser traffic, bypassing DPI. However, like any proxy, it does not provide complete anonymity, and your IP address remains known to the VPS provider.

Does NaiveProxy affect internet speed?

Like any proxy protocol, NaiveProxy can affect internet speed. Performance depends on your VPS's bandwidth, the distance to the server, and the quality of the network connection. Under stable network conditions, NaiveProxy provides good speed, but with high packet loss (over 5-10%), its TCP foundation can lead to a noticeable speed reduction compared to QUIC protocols like Hysteria2.

Can I use NaiveProxy on a home router?

Theoretically, yes, but it's more complex than on a VPS. To run it on a router (e.g., with OpenWrt), you would need to install Caddy with the forwardproxy module, which often requires compilation for the router's architecture and sufficient resources (RAM, CPU, storage). It's simpler to set up NaiveProxy on a VPS and then use it for your entire network via a client on the router that supports proxy connections. For bypassing DPI on a router, you might consider Zapret on Keenetic and OpenWrt Routers.

Quick pick

Need a dedicated server?

Bare metal with NVMe in 70+ locations — configure and order in minutes.

Browse servers

Conclusion

NaiveProxy represents a powerful and effective solution for bypassing the most advanced DPI systems, especially those that actively analyze TLS fingerprints and traffic metadata. Its unique ability to mimic the Chromium network stack makes it virtually indistinguishable from regular browser traffic, providing reliable access to blocked resources. While NaiveProxy has its drawbacks, such as a smaller client ecosystem and potentially lower speed under packet loss, its advantages in combating strict blocks make it an indispensable tool for technically savvy users willing to perform self-setup on their VPS.

SSD NVMe

Ready to launch your VPS?

NVMe VPS with 60-second activation: full root access, 20+ locations, pay with card or crypto.

Choose a plan