Manual VPN Setup 2026: Best Options (best vpn manual settings)

If you've already googledbest vpn manual settings and found dozens of articles with advice like "choose a reliable protocol" — I understand the frustration. The standard client was launched, the checkbox was checked, but YouTube still doesn't open. Or the connection lasts 20 seconds and drops. This is not a problem with the VPN service itself — it's the DPI of your provider reading the handshake and cutting the traffic. Below are specific values: MTU, ports, AllowedIPs, PersistentKeepalive. No made-up speed tests.

When VPN auto-configurations don't work and manual configuration is needed

Signs of VPN blocking by the provider's DPI

The symptoms are well known if you've encountered them. The app says "Connected," there's a ping to the server, but the browser hangs on loading. Or pages take 2–3 minutes to open, then the connection drops. Another characteristic sign is that the VPN works reliably for the first 10–30 seconds, then disconnects. The latter almost always indicates heuristic DPI detection: the provider allows the session to start, then recognizes the protocol signature and cuts the channel.

UDP traffic of WireGuard is particularly easy to block — a number of mobile operators cut non-standard UDP ports entirely. In such conditions, WireGuard won't work with any MTU settings. You need either TCP protocol or a change of provider.

Why Roskomnadzor slows down and drops VPN connections

Since 2021, the RKN has been actively using TSPU — technical means of countering threats. This is not just IP blocking, but specifically traffic analysis by signatures. Pure WireGuard has a unique UDP handshake that TSPU recognizes without problems. OpenVPN on standard ports does too. Therefore, "I just installed the client" stopped working around 2022 for many providers.

Here it's important to understand one point: TSPU reacts to the signature, not just the IP. Therefore, changing the server without changing the protocol may not help at all.

What manual configuration really provides and what is a myth

Honestly: manual configuration helps in specific cases. Changing the MTU eliminates packet fragmentation — the connection stops dropping due to incorrect size. Changing the protocol and port avoids DPI detection. Enabling obfuscation masks the traffic as regular HTTPS.

But there are things that settings won't fix. If the IP address of your VPN server is blacklisted by the RKN or the provider has blocked it separately — no MTU will help. A server change is needed. And one more thing: changing the MTU does not "speed up the internet," this is a common misconception. MTU only eliminates fragmentation that drops the connection.

Best protocols and parameters for bypassing blocks

WireGuard: MTU, ports, and why it's easily detected by DPI

WireGuard is a fast and elegant protocol. But its UDP handshake has a clear signature: the first packet is always 148 bytes, the response is 92 bytes. DPI systems know this and exploit it.

If WireGuard does work with your provider, the correct MTU is 1420. With mobile internet or frequent drops, try 1280 or 1360. Set PersistentKeepalive to 25 — this is critical behind NAT. It's better to specify DNS explicitly: 1.1.1.1 or 8.8.8.8, otherwise requests may go outside the tunnel. AllowedIPs must include both 0.0.0.0/0 and ::/0 — without the second, IPv6 traffic flows outside the VPN.

OpenVPN: TCP/UDP, port 443, tls-crypt against DPI

OpenVPN on TCP 443 with the directivetls-crypt — is one of the most resilient options. Port 443 is HTTPS, the provider cannot block it without breaking the entire internet for its subscribers. And tls-crypt encrypts the handshake itself, preventing DPI from reading the OpenVPN signature.

UDP is faster, but it's easier to block. If the provider cuts UDP — switch to TCP 443. Yes, it will be a bit slower, but it will work. For the config:proto tcp,port 443,tls-crypt ta.key. I recommend the cipher AES-256-GCM — faster than AES-256-CBC, hardware acceleration is available even on phones.

VLESS/XRay and Shadowsocks: masking as regular HTTPS traffic

These are the best options against tough DPI. VLESS with Reality mimics a TLS connection to a real site — for example, microsoft.com. DPI sees legitimate HTTPS and lets it through. Shadowsocks-2022 encrypts traffic in such a way that it is statistically indistinguishable from random data — there’s nothing to detect.

The complexity is higher than that of WireGuard. You need an XRay client (v2rayNG on Android, Shadowrocket on iOS) and a properly generated config with UUID, publicKey, and shortId. But stability under active DPI conditions is incomparably better. Some services, including NvoVPN, support VLESS/Reality — it's worth checking if standard protocols are not working.

AmneziaWG and obfuscation against deep packet inspection

AmneziaWG is WireGuard with the addition of junk packets at the beginning of the session. The goal is simple: to break the handshake signature that DPI reads. The parameters Jc, Jmin, Jmax, S1, S2, H1–H4 are set in the config and randomize the first packets.

Works well against TSPU. The Amnezia client is available for Android, iOS, Windows, macOS — and can import standard WireGuard configs with the addition of obfuscation parameters. If pure WireGuard doesn't work, AmneziaWG is the first thing to try without a radical protocol change.

IKEv2: when it is suitable and when it is useless

IKEv2 is a stable protocol, well withstands network changes (from Wi-Fi to mobile and back). It is built into iOS and Android without additional applications. But against DPI, it is practically defenseless: the signature on UDP 500/4500 is well known, and providers block it effortlessly.

Use IKEv2 where VPNs are not blocked: corporate networks, business trips to countries without strict censorship. In Russia, with active DPI, it is of little use.

Step-by-step manual configuration on different devices

Android: WireGuard and Amnezia — import config and edit parameters

WireGuard app from Google Play or F-Droid. Add the tunnel manually or scan the config QR code. Key fields:Endpoint — IP:port of the server;Allowed IPs — write 0.0.0.0/0, ::/0 (all traffic through VPN);DNS — 1.1.1.1;MTU — 1420, if there are issues change to 1280;Persistent Keepalive — 25.

For AmneziaWG — a separate Amnezia VPN application. You import the config via a file or the link amnezia://. The obfuscation parameters (Jc, Jmin, Jmax) are already specified in the config by the provider — you do not need to change them manually if the service generates configs itself.

iPhone/iOS: profiles in applications and system VPN restrictions

iOS does not allow changing MTU system-wide — this is a strict limitation by Apple. The built-in VPN client supports IKEv2, L2TP, and Cisco IPSec. For WireGuard, you need an app from the App Store. For VLESS — Shadowrocket (paid, $2.99) or Streisand.

Another point: iOS aggressively kills VPNs in the background when saving battery. This is not a config bug — it is a system policy. A partial solution: in the VPN settings, disable "Connect on demand" and keep the app active. Or set up the VPN on the router — then the iPhone simply goes through it, and there are no background issues.

Windows: clients and setup via WireGuard/OpenVPN GUI

You can download the official WireGuard client for Windows from wireguard.com. Create a new tunnel, paste the config in text format. The fields are the same: Interface (PrivateKey, Address, DNS, MTU) and Peer (PublicKey, Endpoint, AllowedIPs, PersistentKeepalive).

OpenVPN GUI — a standard open-source client. You place the .ovpn file in C:\Program Files\OpenVPN\config\, and run it with administrator rights. If TCP 443 is needed — this must be specified in the .ovpn file by your provider.

macOS: configuration and bypassing system restrictions

WireGuard is available in the Mac App Store. It works similarly to Windows — import the config via a file or QR. On macOS Ventura and newer, the built-in VPN function supports IKEv2 through system settings, but this won't help bypass DPI.

For VLESS on macOS — the Hiddify or Nekoray client. Both can work with XRay configs and support Reality.

Routers (Keenetic, OpenWrt): VPN for the entire network

Setting up a VPN on the router is the best solution for Smart TVs, consoles, and any devices without their own client. All traffic on the network goes through the tunnel automatically.

Keenetic natively supports WireGuard starting from firmware 3.3. Go to "Other connections" → WireGuard → add the configuration. I recommend an MTU of 1280 for routers — with a margin for encapsulation. On OpenWrt, install the packageluci-proto-wireguard, configure it through the web interface or directly in /etc/config/network.

Smart TV and Apple TV: setup via router or separate client

Smart TVs (Samsung, LG) do not have a native VPN client. The only decent option is to set up a VPN on the router. Apple TV with tvOS 17+ supports configuration profiles, but this is more like IKEv2 — for serious DPI bypass, this is insufficient. Better also through the router.

Fine-tuning speed and stability

Choosing MTU through ping to eliminate fragmentation

Here’s a method that few explain properly. On Windows, open the command prompt and execute:

ping -f -l 1400 8.8.8.8

The flag-fprevents fragmentation,-lsets the packet size. If you receive "Packet needs to be fragmented" — reduce the size. You find the maximum size at which the ping passes without fragmentation — add 28 (this is for IP + UDP headers). The resulting number is your optimal MTU.

On Linux and macOS, the command looks different:ping -D -s 1400 8.8.8.8. The logic is the same.

I will emphasize again: this does not speed up the connection. MTU simply eliminates fragmentation, which causes packets to be lost and the connection to break.

Choosing a port: 443, 53, 80 and why it matters

Port 443 is gold. This is HTTPS, and the provider physically cannot block it without causing the entire internet for subscribers to stop working. Most blocks are bypassed through it.

Port 53 (DNS) is also often allowed without inspection — providers need DNS queries to work. Port 80 (HTTP) is worse: the traffic is unencrypted and easier to inspect. UDP ports are generally easier to block than TCP 443 — keep this in mind when choosing.

PersistentKeepalive against disconnections behind NAT

Behind NAT (especially behind CGNAT from mobile operators), the WireGuard session closes if no traffic goes for some time. PersistentKeepalive 25 sends an empty packet every 25 seconds — the NAT record does not expire, and the connection is maintained. Without this parameter, behind CGNAT, the VPN will constantly reconnect.

Split tunneling: allowing only necessary sites through VPN

If you need a VPN only for YouTube, Instagram, Twitter/X, and Telegram — there’s no need to route all traffic through it. Split tunneling allows you to direct only specific IPs or domains into the tunnel, while banks and local services can go directly.

In WireGuard, this is done through AllowedIPs — instead of 0.0.0.0/0, you specify specific subnets. But manually compiling a list of IPs for YouTube is quite a task. It’s easier to use apps that support domain-routing (Amnezia, Hiddify), where you can specify a list of domains for the tunnel.

Measure your real speed through Speedtest or Fast.com before and after the setup. No made-up "three times faster" — look at your numbers in your own network.

Diagnostics: what to do if the VPN still doesn't work

VPN connects, but websites do not open

“Connected, but not working” — the most common complaint. Almost always, it is one of three reasons: incorrect MTU (packets are fragmented and lost), DPI cuts traffic by protocol signature, or not all address ranges are specified in AllowedIPs.

Checklist in order: first — check AllowedIPs, it should include both 0.0.0.0/0 and ::/0. Second — try MTU 1280. Third — if nothing helps, change the protocol to VLESS or OpenVPN TCP 443. This sequence works in 90% of cases.

DNS and WebRTC leaks — how to check

A DNS leak means that domain name requests go through the provider, not through the tunnel. Your provider sees which websites you visit. You can check at dnsleaktest.com — if it shows your provider's addresses instead of the VPN server, there is a leak.

WebRTC leaks are relevant for browsers: the WebRTC Control extension or uBlock Origin (configuration in its settings) block this. Check at browserleaks.com. If your real IP is visible there — enable WebRTC blocking in the browser.

IPv6 leaks bypassing the tunnel

This is a problem that most articles remain silent about. If your provider issues an IPv6 address, and ::/0 is not specified in AllowedIPs, all IPv6 traffic goes past the VPN directly. Websites that support IPv6 will see your real address.

The solution is simple: add ::/0 to AllowedIPs. Or, if the VPN server does not support IPv6 tunneling, completely disable IPv6 on the network adapter. On Windows, this is done in the adapter properties → uncheck "Internet Protocol version 6".