Mullvad’s new multihop modes change when a second server is used
What Mullvad’s three multihop modes do, how existing settings migrate, and where the rollout stands as of October 27, 2026.
Record updated October 27, 2026.
Mullvad’s new multihop controls distinguish a second server added for feature compatibility from a two-server route used on every connection. The practical distinction: When needed is not always-on multihop, and Never requires your selected location to support every active setting.
Mullvad’s announcement, dated August 24, 2026, introduces three modes and replaces DAITA’s separate “Direct only” setting. Availability differs by platform; the announcement’s Android rollout language has since been overtaken by release notes.
What each mode does
The following behavior is described in Mullvad’s announcement:
| Mode | Connection behavior | When to choose it |
|---|---|---|
| When needed | Uses one server unless an active feature or setting is unavailable at the selected location. The app then adds a nearby compatible server and exits through the location you selected. | You want feature compatibility without requiring two servers on every connection. |
| Always | Routes the connection through two different servers. You can control the entry server or use Automatic location. | You explicitly want a two-server route every time. |
| Never | Uses one server. The selected location must support all active settings for a connection to be established. | You want to exclude multihop and are willing to restrict locations or adjust settings. |
For example, if DAITA is enabled but unavailable at your chosen exit location, When needed can automatically add a compatible entry server. It does not mean the app continuously evaluates whether your activity is sensitive enough to need another hop: Mullvad describes the trigger as compatibility with enabled settings.
Automatic location is an entry-location option, not a fourth mode. Under Always, it lets the app select a nearby entry location that supports your enabled features. Mullvad does not promise that this automatic choice places the two servers in different countries or jurisdictions. Source: announcement.
Rollout status: distinguish the announcement from releases
- iOS: The August announcement identifies 2026.4 as already supporting the modes.
- Android: The announcement named 2026.9 as forthcoming. Mullvad’s 2026.9 release notes subsequently list the new multihop design and automatic “when needed” option.
- Desktop: The announcement targets 2026.6 later in 2026. As of this record, Mullvad’s release index lists desktop 2026.5 as the newest stable desktop release shown. Treat 2026.6 as an announced target here, not confirmed stable availability.
Android users should not install 2026.9 merely to obtain the feature. Mullvad warns against that version because QUIC could leave the tunnel stuck connecting or disconnecting, and recommends 2026.10 instead. The 2026.10 notes record a fix for the QUIC hang, while also noting a separate issue where the first connection attempt can fail with features such as DAITA or quantum-resistant tunnels. Later Android releases are listed in the release index; 2026.10 is the named corrective release, not a claim that it is the latest version.
Check your mode after upgrading
Mullvad says upgrades migrate existing settings to a new multihop mode and show a notification when the updated app first opens. For users already using multihop, it says settings map to the closest equivalent mode where possible. Its documented examples include:
- Multihop off, DAITA off, Direct only off, filters off → When needed.
- Multihop on, DAITA off, Direct only off, filters off → Always.
- Multihop on, DAITA on, Direct only off, filters off → Always, with an Automatic entry server.
These are examples, not an exhaustive migration table. In particular, a previously single-server configuration can migrate to When needed, rather than Never. Check the resulting mode, entry selection and active features instead of assuming the old toggle has an identical replacement.
Privacy and performance: what the change does not establish
Mullvad’s WireGuard multihop guide describes interconnected servers and end-to-end encryption in its multihop arrangement. It presents additional hops—preferably across different jurisdictions and infrastructure—as making incoming/outgoing traffic correlation more difficult and providing protection if one server is compromised. Those are the provider’s technical explanations, not an independent finding that these new modes guarantee anonymity.
Performance is also route-dependent. The same guide says distance generally slows multihop connections, but inefficient ISP peering can sometimes make a particular two-server route faster. “Always” is therefore not a fixed speed penalty, and “Never” is not a guaranteed speed improvement.
The material change is routing policy and feature compatibility, not new evidence about logging or ownership.