What does a VPN protect you from, and does it slow down your internet?

VPNs are often presented as broad online security tools. They can provide useful security and privacy benefits, but a VPN has a more specific role than some marketing can suggest.

A consumer VPN creates an encrypted connection between a device and a VPN provider. Traffic covered by that connection travels through the VPN provider before continuing towards websites and other internet services. This can reduce what the local network or internet provider can directly observe and normally changes the public IP address presented to destinations.

A VPN does not, however, make every website trustworthy, prevent phishing, stop every malicious download, protect a device that is already compromised or replace software updates, browser security, account protection or recovery planning.

There can also be a performance trade-off. Routing traffic through an additional VPN server can change the network path and may increase latency or reduce throughput. The effect depends on factors including the original connection, VPN protocol, server location, server load and wider internet routing.

The useful question is therefore not simply “Should I use a VPN?” It is “What am I trying to protect, and is a VPN the right control for that particular part of the connection?”

Use the links below to jump to the section most relevant to your question.

• What a VPN actually changes
• Consumer VPNs and corporate VPNs are not the same
• What HTTPS already protects
• Do you still need a VPN on public Wi-Fi when websites use HTTPS?
• Where DNS, encrypted DNS and protective DNS fit
• Can DNS manipulation redirect a secure website?
• Why compromised home and office routers also matter
• Does a VPN slow down your internet?
• What split tunnelling changes
• What a VPN does not protect against
• When using a VPN makes practical sense
• How a VPN fits into layered security
• Related guides
• Supporting references
• Further Guidance and Support

Without a consumer VPN, a simplified internet connection may look like this:

Device
↓
Local network or Wi-Fi
↓
Internet provider
↓
Website or online service

Individual applications can still provide their own encryption. A browser using HTTPS, for example, normally establishes a TLS-protected connection with the website.

When traffic is sent through a consumer VPN, another protected path is introduced:

Device
↓
Encrypted VPN tunnel
↓
VPN provider
↓
Website or online service

The local network and internet provider can normally identify that the device is communicating with the VPN service, but the traffic carried inside the VPN tunnel is protected from direct inspection on that part of the network path.

The destination normally sees the VPN provider’s public IP address rather than the public IP address of the original home, office, hotel or mobile connection.

This does not eliminate trust. It moves part of the network trust from the local network and internet provider towards the VPN provider.

That is an important part of deciding whether a particular VPN service is appropriate.

The term VPN is used for technologies that can have quite different purposes.

A consumer VPN normally creates a protected connection from a device to the VPN provider’s infrastructure. Common reasons include reducing exposure on networks the person does not control, reducing visibility to the local internet provider, and changing the public IP address presented to internet services.

A corporate VPN is usually about protected access to organisational resources:

Remote device
↓
Corporate VPN
↓
Organisation’s protected network or private systems

The UK National Cyber Security Centre describes organisational VPNs as a way of providing secure connectivity between devices in physically separate locations. Its organisational VPN guidance also makes clear that individual consumer uses can be different.

A corporate VPN may therefore provide access to systems that have deliberately not been made directly available from the public internet.

A consumer privacy VPN and a corporate remote-access VPN should not be treated as the same security decision simply because both use the term VPN.

Modern web browsing already has an important security layer of its own.

HTTPS uses TLS to protect communication between the browser and the website. Correctly implemented HTTPS helps prevent someone positioned in the network path from reading the protected content or modifying it in a predictable way. Modern browsers also expect the server to present a valid digital certificate so that its identity can be checked.

A simplified connection looks like this:

Browser requests website
↓
Browser reaches a server
↓
Server presents its TLS certificate
↓
Browser checks the certificate and requested identity
↓
TLS connection is established
↓
Web traffic travels inside the encrypted connection

When an HTTPS website is opened through a consumer VPN, the VPN and HTTPS are normally protecting different parts of the same journey:

Device → VPN provider
protected by the VPN tunnel

while:

Browser → website
protected by HTTPS/TLS

The ordinary VPN provider does not gain the ability to read the contents of an HTTPS banking, email or cloud session merely because the encrypted website connection travels through its VPN server.

Something additional would normally have to interfere with TLS trust or the endpoint itself before that protected website content could be decrypted.

HTTPS also has an important limit: a protected connection does not prove that the website has good intentions. A fraudulent website can have a valid certificate for a domain controlled by the person operating it.

Public Wi-Fi is one of the situations most commonly associated with VPN use, but the answer is more nuanced than saying that public Wi-Fi is always unsafe without a VPN.

HTTPS already provides important protection for correctly configured website connections. This significantly reduces the ability of somebody operating or observing the local Wi-Fi network to read protected webpage contents.

A VPN can still add a broader network privacy layer because traffic covered by the VPN is first carried through the protected tunnel to the VPN provider rather than being exposed individually to the local network.

This can be useful on networks such as:

• • hotels
  • airports
  • cafés
  • conferences
  • shared workspaces
  • temporary office networks
  • other networks where the configuration and management are outside your control.

A VPN should therefore be understood as an additional network protection and privacy layer, not as the feature that makes HTTPS itself secure.

What can the local network see?

Without a VPN, even where HTTPS protects webpage contents, the local network can still observe some connection information. Traditional unencrypted DNS can also expose which domain names are being looked up.

Encrypted DNS can reduce that particular exposure. Mozilla describes DNS over HTTPS as improving privacy by hiding domain lookups from people observing public Wi-Fi, the internet provider or others on the local network.

With a VPN, much of the covered network activity instead appears locally as communication with the VPN service.

However, a VPN does not make a fake hotspot legitimate, make a fraudulent login page safe, or make it sensible to ignore certificate or browser warnings.

For a wider explanation of shared internet connections, see our guide to understanding internet access in offices and public places.

DNS performs a different job from a VPN and from HTTPS.

Before a device can normally connect to a website by name, it needs to find the network address associated with that name:

You request a website
↓
DNS asks where it can be reached
↓
DNS returns an address
↓
Browser connects to the destination
↓
HTTPS/TLS can then validate and protect the website connection

A useful distinction is:

DNS
Where should I go?

↓

TLS
Is the server I reached entitled to identify itself as the website I requested?

Encrypted DNS technologies such as DNS over HTTPS protect the DNS request while it travels between the device and the resolver. RFC 8484 defines DoH as DNS carried over HTTPS and notes that it protects DNS traffic against passive observation and certain on-path manipulation.

The connection is therefore:

Device
↓
Encrypted DNS request
↓
DNS resolver
↓
DNS answer returned
↓
Device makes its separate connection to the destination

A VPN has broader scope:

Device
↓
Encrypted VPN tunnel carrying covered network traffic
↓
VPN provider
↓
Internet destinations

Protective DNS adds another function. A service such as NextDNS can apply filtering policy at the DNS stage and block some destinations associated with security, privacy or other configured rules before the intended connection is made. NextDNS describes its service as providing DNS-level security and filtering against threats including malware and phishing.

These controls are therefore not direct replacements for one another:

Encrypted DNS protects the DNS lookup path.

Protective DNS can also apply policy to that lookup.

A VPN protects a broader network path to the VPN endpoint.

HTTPS/TLS protects compatible website sessions between the browser and website.

A DNS filtering service normally has much less effect on overall internet performance than routing internet traffic through a consumer VPN, because it handles DNS resolution rather than carrying the full internet session. Performance still depends on the resolver, network path and configuration.

For more detail on encrypted and protective DNS, see our our NextDNS guide.

DNS manipulation can cause a device to receive an incorrect network address for a genuine domain.

For example:

You request the genuine website name
↓
Manipulated DNS provides an attacker-controlled address
↓
Browser reaches the wrong server

However, DNS redirection by itself does not normally defeat correctly validated HTTPS.

The browser still expects the reached server to satisfy the TLS identity check for the hostname that was requested:

Wrong address returned by DNS
↓
Attacker’s server presents a certificate
↓
Certificate is not valid for the genuine hostname
↓
TLS validation should fail or produce a warning

For an attacker to impersonate the genuine HTTPS service successfully, another condition would normally also be needed, such as compromised certificate trust, certificate mis-issuance, an ignored warning, endpoint compromise or use of a misleading lookalike domain.

DNS and TLS therefore answer different security questions and can complement one another.

For a wider explanation of DNS manipulation and DNS integrity, see Why DNSSEC matters and how DNS attacks can redirect internet traffic.

These risks are not limited to airport or hotel Wi-Fi. Home and office routers are also part of the internet connection path and can affect many devices using the same network.

In an advisory dated 7 April 2026, the UK National Cyber Security Centre documented APT28 activity in which vulnerable routers were compromised and DHCP and DNS settings were altered to direct traffic towards attacker-controlled DNS infrastructure. The resulting malicious DNS responses were used as part of adversary-in-the-middle activity targeting credentials and authentication tokens.

The enduring lesson is not that every router or DNS failure indicates an attack.

It is that:

Trusted network

does not mean

permanently trustworthy network

Routers, DNS configuration, firmware, administrative access and network ownership still need appropriate review.

The example also illustrates why several layers matter. Manipulated DNS can redirect a connection attempt, while HTTPS/TLS identity validation remains a separate control that can still prevent a false server from successfully impersonating the intended hostname.

A VPN can affect internet performance because it changes the connection path.

Without a VPN:

Device → internet provider → destination

With a VPN:

Device → internet provider → VPN server → destination

The second path adds another network stage and requires the VPN traffic to be processed through the encrypted tunnel.

The effect can depend on:

• • distance to the VPN server
  • VPN server load
  • VPN protocol
  • network congestion
  • routing between providers
  • the original connection speed
  • latency on the underlying connection
  • processing capability of the device or VPN endpoint.

Norton describes VPN slowdown as resulting from the additional steps involved when traffic is encrypted and routed through a VPN server before reaching its destination. Proton similarly notes that a VPN connection is likely to be slightly slower than the underlying connection, while server load can also affect performance.

This does not mean that a VPN will always cause an obvious problem. With a good connection, a suitable protocol and a nearby lightly loaded VPN server, the practical difference may be small.

Why server location and routing matter

Suppose a device in London is connecting to a service also hosted relatively close to London.

Without a VPN, the network path may remain comparatively direct.

If the VPN endpoint is also nearby, the extra route may be modest.

If the connection instead exits through a distant VPN location:

London device
↓
Distant VPN server
↓
Back towards the requested service

latency can increase even where download throughput still appears reasonable.

This may be particularly noticeable with:

• • voice calls
  • video meetings
  • remote desktop sessions
  • interactive cloud applications
  • other latency-sensitive services.

Internet performance is therefore not only about the maximum number shown by a speed test. Latency, route quality and consistency also matter.

Some VPN products allow selected traffic to bypass the VPN. This is commonly called split tunnelling.

For example:

Browser or selected business application
→ VPN tunnel

while:

Excluded application
→ normal internet connection

Norton describes its split-tunnelling feature as allowing selected applications to be excluded from the VPN channel while other applications continue using the VPN.

This can sometimes help with performance, local-device access or compatibility.

However, split tunnelling also changes the security and privacy boundary. Traffic intentionally excluded from the tunnel no longer receives the VPN’s protection for that part of its connection.

The useful question is therefore not simply whether split tunnelling is enabled. It is which applications are bypassing the VPN, why they are excluded, and whether that remains appropriate.

A consumer VPN can be a useful network security and privacy control, but it should not be treated as complete protection.

On its own, a VPN does not:

• • prove that a website is genuine
  • prevent phishing
  • make a malicious website safe
  • prevent somebody voluntarily entering credentials into a fraudulent service
  • replace browser security
  • replace endpoint protection
  • correct vulnerable or unsupported software
  • prevent every browser or application exploit
  • secure a device that is already compromised
  • prevent every form of account takeover
  • replace MFA, passkeys or account recovery
  • replace protective DNS
  • replace email security
  • provide independent backup or recovery
  • guarantee anonymity
  • guarantee that every network connection is protected if split tunnelling or exclusions are in use.

Some commercial VPN products include additional features such as malicious-site blocking, tracker blocking or other security tools. Those are additional services supplied alongside the VPN rather than security properties that every VPN tunnel inherently provides.

Does a VPN make you anonymous?

A VPN can cause destinations to see the VPN provider’s public IP address instead of the public IP address of the original network.

That reduces one source of identifying or location information, but it does not make the person completely anonymous.

Online services may still associate activity through:

• • account sign-ins
  • cookies
  • browser or application identifiers
  • device characteristics
  • information deliberately supplied to the service
  • activity connected with an existing account.

A VPN is therefore better understood as a privacy control than as a guarantee of anonymity.

The most useful way to decide whether a VPN is appropriate is to start with the problem rather than the product.

A simple decision path is:

Do you need protected access to private organisational resources?
↓
Review the organisation’s corporate VPN or other approved remote-access method.

Do you want broader local-network privacy on a network you do not control?
↓
A suitable consumer VPN may provide an additional protected network path.

Is the main requirement DNS privacy?
↓
Review encrypted DNS.

Is the requirement to block known or policy-restricted domains?
↓
Review protective DNS.

Is the requirement to protect a website connection?
↓
HTTPS/TLS performs that role.

Is the concern malware or harmful activity on the device?
↓
Browser, application and endpoint security are also required.

Is the concern account compromise?
↓
Authentication, permissions, session protection, monitoring and recovery remain separate controls.

The technologies overlap in places, but they are not interchangeable.

A VPN makes the most sense when its role is deliberate and understood rather than when it is enabled simply because it is assumed to make everything on the internet secure.

A VPN is best understood as one part of a wider security model.

A realistic internet connection may depend on several different controls:

Device and operating system security
↓
Local network and router
↓
DNS or protective DNS
↓
VPN where appropriate
↓
HTTPS/TLS
↓
Browser and application security
↓
Account authentication and permissions
↓
Monitoring and recovery

Each layer addresses a different question.

A device can use a VPN and still visit a phishing website.

A browser can use HTTPS and still download harmful software.

Protective DNS can block a known malicious domain but cannot guarantee that every newly created or newly compromised destination is already known.

A fully updated device can still contain an unknown or not-yet-fixed vulnerability.

This is why the aim should not be to find one product that claims to solve every problem.

The wider model remains:

Prevent → Detect → Contain → Recover → Learn → Improve

A VPN can contribute mainly to the preventive and privacy parts of that model. Other controls are needed to detect problems, contain compromised accounts or devices, recover important information and improve the environment afterwards.

This guide is not a permanent checklist. VPN technologies, protocols, operating-system behaviour, provider features and internet architecture can change. The underlying questions should therefore be reviewed periodically:

What are we protecting?
↓
Which part of the connection does this control protect?
↓
What does it not protect?
↓
What performance or usability trade-off does it introduce?
↓
What happens if that layer does not work as expected?

For the wider security model, see our layered security guide.

The following Evening Computing guides provide more detail about the individual security and network layers covered on this page:

What is NextDNS and what does it do?
Explains DNS filtering, encrypted DNS, device and router deployment, and the limits of DNS-level protection.

How to improve browser security and privacy in Chrome and other browsers
Explains browser permissions, Secure DNS, website protections, session security and the limits of browser hardening.

Why DNSSEC matters and how DNS attacks can redirect internet traffic
Explains DNS manipulation, DNS integrity and how DNSSEC helps verify DNS responses.

Understanding internet access in offices and public places
Explains shared Wi-Fi, hotspots and how internet connections differ across offices, hotels and other public environments.

What is layered security and why does it matter?
Explains why security depends on several controls rather than one product or setting.

The following sources support the technical standards, security mechanisms and documented examples used in this guide:

UK National Cyber Security Centre: Virtual Private Networks (VPNs)
Guidance on organisational VPNs and protected connectivity between physically separate locations.

Mozilla MDN: Manipulator in the Middle
Technical explanation of HTTPS/TLS as a primary defence against interception and predictable modification of protected web traffic.

Mozilla MDN: Transport Layer Security
Explanation of TLS and certificate-based server identity validation.

Mozilla Support: Firefox DNS over HTTPS
Explanation of how encrypted DNS can reduce exposure of DNS lookups on public Wi-Fi and other local network paths.

RFC 8484: DNS Queries over HTTPS
Technical standard defining DNS over HTTPS and its transport-security properties.

UK National Cyber Security Centre: APT28 exploit routers to enable DNS hijacking operations
Documented April 2026 example of compromised routers and malicious DNS configuration being used in adversary-in-the-middle activity.

Norton: Does a VPN slow down your internet?
Explanation of how the additional encrypted VPN path can affect performance.

Norton Support: Configure VPN settings
Product documentation describing split tunnelling and the ability to exclude selected applications from the VPN path.

NextDNS
Product documentation and service description covering DNS-level filtering and security functions.