Can WireGuard Be Detected? What DPI Can See Through an Encrypted VPN

Yes. Standard WireGuard can be recognized by an ISP, network administrator or censor even though its tunnel contents are encrypted. Its message structure and traffic patterns distinguish it from ordinary web traffic. A network does not have to decrypt a VPN tunnel to identify the protocol or block the connection.

A 2026 study by Yasameen Sajid Razooqi and Adrian Pekar examines a different question: whether application categories can be classified through WireGuard using encrypted-side traffic features. The reported results show that useful patterns survive encapsulation. They do not establish a 98% success rate for detecting WireGuard across the internet.

There are three separate questions here: recognizing WireGuard, inferring activity inside it, and making the connection harder to identify through obfuscation. Our VPN protocol comparison covers ordinary protocol selection. For a detailed look at one anti-blocking variant, read how AmneziaWG 3.0 and 3.1 fight VPN fingerprinting.

Yes, encrypted WireGuard traffic can still be recognizable

WireGuard encrypts the IP packets carried inside the tunnel. That protects application data and inner destination addresses from an observer between your device and the VPN server. DNS requests receive that protection when they travel through the VPN too; requests that escape the tunnel do not.

The outer connection must still deliver those encrypted packets. Your ISP can see the VPN server's IP address, the transport and ports, how large the packets are, which way they travel and when they arrive. It can measure traffic volume and duration. Those properties form a fingerprint even when the content is unreadable.

The VPN provider occupies a different position: its gateway decrypts and forwards the inner packets. HTTPS still protects web content between your browser and a website. The visibility discussed below belongs to a passive observer outside the VPN, not its operator or someone who controls your device.

Why ordinary WireGuard is relatively easy to fingerprint

WireGuard deliberately uses a small set of message formats over UDP. Its standard handshake initiation is 148 bytes, its response is 92 bytes, and a cookie reply used in denial-of-service protection is 64 bytes. Transport data messages vary in length. These are WireGuard message lengths within the UDP payload, excluding outer UDP and IP headers; they are not total captured frame sizes.

Deep packet inspection, or DPI, examines traffic beyond a port number. It can inspect unencrypted protocol fields and track relationships between packets. A size alone can match unrelated traffic; a consistent combination of message type, reserved bytes, length and handshake behavior provides stronger evidence.

The open-source nDPI WireGuard dissector implements those checks. It compares expected handshake lengths and verifies that a response's receiver index matches the initiation's sender index. It also has a path for recognizing transport packets through consistent indices across packets, so its inspection is not limited to witnessing the opening handshake.

That is a working implementation of stock protocol identification without decryption. It does not tell us which engine a particular government uses, or how often its rules misclassify traffic. WireGuard's own limitations documentation explicitly leaves obfuscation to another layer.

New research: traffic inside WireGuard retains a fingerprint

Razooqi and Pekar's Matched-View Cross-Domain Evaluation of WireGuard VPN Traffic Classification Using Early-Flow Fingerprints was submitted to arXiv on August 30, 2026; its record states acceptance at CNSM 2026. It asks whether models trained on traffic before VPN encapsulation can classify application categories from the corresponding encrypted traffic.

Capturing VPN and non-VPN traffic in separate sessions can muddle that comparison: users may run different applications or behave differently. Here, both sides were captured simultaneously, with more than 99.9% packet correspondence. The underlying Data in Brief dataset paper documents roughly 80 hours across two December 2025 sessions, 10 household devices and 226,454 flows. The residential connection was in Budapest, using one Surfshark WireGuard endpoint in Prague.

What the researchers could infer

A flow is a related exchange of packets. The models received either whole-flow statistics, such as byte totals and duration, or an ordered record of packet sizes, directions and gaps between arrivals. The latter is called Sequence of Packet Length and Time, or SPLT. Its input preserves the rhythm of an exchange without reading payloads.

The comparison included Random Forest and XGBoost tree models and a multi-scale one-dimensional convolutional neural network, or CNN. The CNN processes local patterns in packet sequences; it achieved the strongest result with early-flow SPLT features. Table I reports balanced accuracy of 0.9753, approximately 0.98, and macro F1 of 0.8932, approximately 0.89, without VPN-side training data.

Balanced accuracy averages recall across categories: how many actual examples of each category were recognized. Macro F1 averages each category's balance of precision and recall, accounting for mistaken labels as well as missed examples. Web and Network traffic dominated the dataset, so ordinary accuracy alone could conceal poor results on smaller categories.

What the study does not prove

The experiment trained and evaluated on two views of the same underlying flows. As the authors explain in section IV-C, it measures transfer across encapsulation, not generalization to unseen flows. Testing on wholly held-out flow pairs would answer a separate deployment question.

The dataset also assigns encrypted packets to application flows using the matched inner capture. A passive censor lacks that view. Recovering separate application exchanges from a tunnel carrying several applications is an additional problem; the reported per-flow score does not establish that capability.

• It classified application categories. It did not test a binary WireGuard-versus-other-traffic detector.
• It covered one environment. One household, one protocol and one VPN endpoint cannot establish performance across devices, routes and implementations.
• It was not a national filtering trial. A deployment must handle unrelated traffic, changing applications, network address translation, packet loss, false positives and the damage caused by blocking legitimate connections.
• It recovered no encrypted payload. Neither WireGuard keys nor application messages were extracted.

Why changing the WireGuard port is not enough

Moving a supported endpoint from UDP port 51820 to UDP port 443 can bypass a rule aimed only at the former port. That is a useful improvement against simple filtering. It leaves the stock WireGuard message format intact.

Port 443 does not turn those messages into HTTPS or QUIC. QUIC commonly uses UDP 443, but it has its own protocol structure. A filter that checks packet fields can still distinguish stock WireGuard, whatever number appears in the destination-port field. Changing ports also leaves an IP-address block untouched.

What deep packet inspection can actually see

This table assumes a passive observer between the client and VPN server and traffic correctly routed through WireGuard. Statistical inferences can be wrong; the existence of a visible signal does not guarantee a reliable classification.

A category label such as Web or Download does not identify an exact website, file or page. An observer might combine patterns with other information, but that would be inference from additional evidence, not direct access to a URL inside WireGuard.

How WireGuard obfuscation changes the connection

Obfuscation changes the exterior of the encrypted tunnel. It may alter recognizable fields, add padding or place the tunnel inside a different transport. The aim is to deprive a filtering system of reliable signatures while retaining encrypted communication.

AmneziaWG

AmneziaWG is a WireGuard-based variant that keeps its underlying cryptographic approach while modifying observable traffic. Amnezia's current technical documentation describes configurable junk packets, handshake padding, replacement message headers and randomized header ranges. Its 3.x mechanisms extend to header protection, transport-content padding and randomized protocol timers. Version 3.1 includes random trailers and an option to disable cookie replies.

Earlier versions already modified more than a fixed port; 3.x broadens the changes to ongoing connection behavior. Padding can disturb length patterns, while randomized service timers reduce repeated timing cues. Those are design mechanisms, not measured success rates against every filtering system. The enabled parameters and compatibility between client and server determine what a particular connection uses.

Our AmneziaWG 3.0 and 3.1 analysis checks the public implementation and separates it from claims about Russia's closed filtering infrastructure. The Razooqi/Pekar experiment tested ordinary WireGuard; it supplies no detection benchmark for AmneziaWG.

Proton Stealth

Proton describes Stealth as WireGuard-based, carried through an obfuscated TLS tunnel over TCP. TLS is the encrypted transport used by HTTPS. Wrapping WireGuard changes what an outside observer receives, making the stock UDP signatures less useful.

Proton positions Stealth as harder for DPI to identify and block. That is the provider's claim; the WireGuard study neither tested Stealth nor proved it indistinguishable from ordinary web browsing. A known Proton endpoint can still be targeted by IP address.

Standard WireGuard, AmneziaWG and Stealth compared

Our VPN Protocol Transparency Report 2026 distinguishes base protocols, provider variants and obfuscation transports. AmneziaWG and Stealth have WireGuard roots; their anti-censorship behavior depends on changes around that base, rather than the WireGuard name alone.

Can governments block WireGuard?

Yes. Available methods range from simple rules to infrastructure investigation. They can be combined, and their cost and risk of collateral blocking differ. The list below describes capabilities, not a claim that every government deploys each one.

1. Port blocking: cheap rules targeting known ports can disrupt default configurations, but another permitted port may bypass them.
2. Protocol fingerprinting: inspecting stock message patterns catches connections that a port rule misses.
3. Server-IP blocking: targeting a known VPN endpoint can work even when its transport is obfuscated.
4. Flow analysis: combining sizes, directions and timing may support classification, subject to false positives and deployment limitations.
5. Active probing and infrastructure identification: investigating suspected endpoints can add evidence beyond a passive packet capture.

Active probing needs qualification for WireGuard. Its protocol is designed to remain silent to unauthorized peers, so sending a random packet does not ordinarily produce a convenient identifying reply. The official WireGuard paper describes that behavior. Probing success depends on the protocol, available endpoint information and surrounding services; it is not a universal WireGuard discovery trick.

Does detectability make WireGuard insecure or less private?

Detectability does not establish a cryptographic weakness. WireGuard uses a Noise-based handshake and ChaCha20-Poly1305 authenticated encryption. Recognizing its exterior neither recovers keys nor defeats authentication. The study describes information left in traffic patterns, not an attack on those cryptographic primitives.

Privacy still needs more than one test. Cryptographic security protects the tunnel contents. Provider privacy depends on what the VPN operator observes and retains. Traffic-analysis resistance limits inferences from patterns. Censorship resistance concerns whether the connection survives filtering. A service can perform well on one of those questions and poorly on another.

For ordinary VPN use, a recognizable connection can still protect your traffic from local inspection. On a network that acts on VPN identification, the same recognizable protocol may fail to connect. Choose according to the observer and the filtering you need to contend with, rather than treating encryption as a promise of invisibility.

What the 2026 research adds

Stock WireGuard identification already has a concrete explanation in its message format. The newer experiment supports a separate conclusion: encapsulation can leave enough application-generated structure for a classifier to use. Changing a handshake signature therefore does not, by itself, answer every traffic-analysis concern.

That is our interpretation of the research, not an independent test of obfuscation. AmneziaWG modifies several observable properties; Stealth wraps the transport. Whether either withstands a particular censor requires measurements on that network. The practical test is how reliably a filter can act on the remaining signals while avoiding legitimate traffic, not simply whether a tunnel has encryption.

Sources

Primary sources checked on October 9, 2026. Provider documentation establishes stated mechanisms and goals; it does not independently verify blocking resistance.

• Razooqi and Pekar, matched-view WireGuard classification study: methodology, Table I scores and same-flow evaluation limits; arXiv v1, accepted at CNSM 2026.
• Razooqi and Pekar, Data in Brief dataset paper: capture environment, labels, matching and dataset scope. Data are also available on Zenodo.
• Donenfeld, WireGuard: Next Generation Kernel Network Tunnel and official limitations: protocol design, cryptography, silence and obfuscation scope.
• nDPI WireGuard dissector: observable message lengths, types and index checks.
• AmneziaWG technical documentation: headers, padding, timers, trailers and cookie controls.
• Proton's WireGuard and Stealth documentation: its description of the obfuscated TLS/TCP transport.