Log In Get Started
Free tool

What your network lets through

When a VPN will not connect in an office, a hotel or on campus, the app is usually not the problem. The network passes only 80 and 443, blocks UDP, or forces DNS to its own server, and each of those is cured by a different protocol. This page checks all four and tells you what will get through here.

Nothing to install; it all runs in the browser.

Ready to check

Press "Check the network", about seven seconds.

What follows from this

What the check showedWhat will connect here
Everything gets throughAny protocol. Take WireGuard, it is faster on weak hardware.
UDP closed, 443 worksA protocol over TCP 443: VLESS with Reality or similar. WireGuard and IKEv2 will not connect.
A non-standard port does not get throughOnly nodes on 443. A config with an unusual port number after the address is useless in this network.
DNS does not go outsideThe network keeps its own resolver. A connection usually survives that, but names before the tunnel are not resolved by you, see the DNS leak test.

Limits

What is checked are our addresses and public STUN servers, not the particular server you connect to: a network can pass 443 to some hosts and block it to others. UDP is checked on the STUN ports, 3478 and 19302; a network that passes one UDP port and blocks the rest will look closed here. QUIC is not checked separately: HTTP/3 is not enabled on our side yet, and measuring someone else’s would mean passing their rules off as yours.

More on this: who resolves your names, more about UDP and which services do not open in this network.

Does your network block half the protocols?

404 VPN connects over VLESS with Reality on TCP 443, to a filter that is indistinguishable from an ordinary site. Where UDP is closed and non-standard ports do not pass, it is the only thing that works.

How to connect 404 VPN →

FAQ

guest@404vpn:~$ cat network-check-faq.md
[01] $ Why does the VPN connect on mobile data but not on the office Wi-Fi? ▸
> Because a mobile carrier passes almost everything, while a corporate network passes only what it sees fit. The typical rule set: TCP 80 and 443 open outbound, UDP closed entirely, DNS queries forced to an internal server. WireGuard will never connect in a network like that, while a protocol over TCP 443 looks like ordinary HTTPS and gets through.
[02] $ What does "non-standard ports do not get through" mean? ▸
> We knock on our own server at port 8443, ordinary HTTPS, just not on 443. If that probe failed while 443 works, the network filters by port number. The practical conclusion: a connection whose server address ends in an unusual port will not work here, you need a node on 443.
[03] $ The test says UDP is closed. Is that certain? ▸
> It means that in six seconds not one public STUN server answered, even though the browser found local addresses. Almost always that is exactly the case, UDP is blocked. One caveat: a network can pass one UDP port and block another, so a rare WireGuard on an unusual port sometimes gets through where the test showed UDP closed.
[04] $ Why is there a DNS check here? ▸
> It answers whether the network lets queries to outside zones out at all. If it does not, the network has its own forced resolver, and that is a separate source of oddities: names may resolve to the wrong addresses or not resolve at all. Who exactly resolves your names is shown by the neighbouring tool, the DNS leak test.
[05] $ Do you store anything from the check? ▸
> No. The probes are requests to our own addresses, no different from opening a page. The summary for support goes into your clipboard, not to us: until you paste it into a message yourself, we never see it.