How to Set Custom DNS in a VPN on Windows: 2026 Guide

Understand what custom DNS changes—and what it does not

When you type a website address into a browser, the device first needs to resolve that name. Windows normally sends a DNS query to the resolver supplied by the local network, router, internet provider, or VPN client. The resolver returns an IP address, after which the application opens a connection to that address. If the resolver is slow, unavailable, incorrectly configured, or returning an unsuitable answer, the browser may show a lookup error even when the VPN tunnel itself is connected.

A custom DNS setting replaces the default resolver with one you choose. This may make name resolution more consistent across home networks, public Wi-Fi, and mobile hotspots. It can also make troubleshooting easier because the resolver remains known instead of changing whenever the network changes. However, DNS is only one stage of the connection. It cannot increase the bandwidth of a selected node, fix packet loss on a route, or make a program support a proxy that it does not understand.

There is also an important distinction between DNS configured in Windows and DNS configured in a VPN client. Windows settings affect requests made through the normal network adapter, while a VPN client may intercept DNS and send it through a virtual adapter, a local DNS proxy, or the remote tunnel. Some clients ignore the Windows resolver after TUN mode is enabled. Others let you select a DNS mode such as system, local, remote, or fake-IP resolution. If you change Windows settings but the client continues to handle DNS internally, the visible result may not change.

Choose a resolver based on reliability and privacy

There is no single DNS resolver that is best for every Windows user. A suitable choice should be reachable from your current network, stable during VPN use, compatible with the client’s DNS mode, and governed by a privacy policy you understand. Public resolvers are convenient for testing, but convenience should not be confused with guaranteed performance in every region or on every route.

Public resolvers and encrypted DNS

Some public DNS services provide traditional DNS over UDP or TCP, while others also support DNS over HTTPS (DoH) or DNS over TLS (DoT). Traditional DNS is easy for almost every client to support, but queries may be visible to the local network. DoH sends DNS inside HTTPS, and DoT uses a dedicated TLS connection. These encrypted methods can reduce local observation of DNS queries, although they still depend on the selected provider and network path.

On Windows, browser-level Secure DNS may operate independently from the operating system. A browser can therefore resolve a website through DoH even while another application uses the Windows resolver. This is useful for privacy testing but can make troubleshooting confusing. If the browser works and a command-line tool does not, compare their DNS paths instead of assuming that the whole computer has the same configuration.

A practical selection checklist

• ✅ Choose a resolver that is reachable from the network where you normally use the VPN.
• ✅ Prefer a provider with clear documentation for ordinary DNS, DoH, or DoT.
• ✅ Keep a known working alternative so you can quickly roll back a failed change.
• ✅ Check whether the VPN client forces remote DNS or exposes its own DNS proxy.
• ❌ Do not assume that a familiar public resolver is automatically the fastest from every location.
• ❌ Do not enter addresses copied from an untrusted configuration file or unknown forum post.

For a VPN connection, preventing DNS leaks is often more important than selecting a resolver solely because it appears fast in a single test. If DNS requests leave through the local interface while web traffic uses the tunnel, the resolver may reveal which domains are being requested and may return answers based on the local network. A client with a remote DNS option, DNS hijacking protection, or a correctly configured TUN stack can keep the two paths aligned.

Set custom DNS in Windows step by step

Before changing anything, note the current adapter and DNS settings. If the computer uses both Wi-Fi and Ethernet, changing the inactive adapter will not affect the active connection. Disconnect from unnecessary VPN clients and virtual network tools during the initial setup. Running two clients at once can create competing routes, DNS interception, or conflicting virtual adapters.

Windows 11 Settings method

1. Open Settings, then select Network & internet.
2. Choose Wi-Fi or Ethernet, depending on the adapter currently in use.
3. Open the active network properties and find the DNS server assignment section.
4. Select Edit, change the method from automatic to manual, and enable IPv4.
5. Enter the primary and, if supplied by the resolver, secondary DNS addresses.
6. Save the change, disconnect and reconnect the network, then clear the local DNS cache.

The exact labels can vary slightly between Windows builds and language settings. Do not change the IP address, gateway, or subnet fields unless you know that the network requires a static configuration. For most users, only the DNS server assignment should be edited. If IPv6 is active, remember that IPv6 DNS can remain in use even after IPv4 DNS has been changed. Either configure IPv6 deliberately or temporarily disable it only for a controlled test; do not leave a partially understood configuration in place for normal use.

Control Panel and adapter properties

The traditional route remains useful when the newer Settings page does not expose the expected option. Open the network adapter properties, select Internet Protocol Version 4 (TCP/IPv4), open its properties, and choose the option to use specified DNS server addresses. Enter the resolver values, confirm the dialogs, and repeat the process for IPv6 only if you have suitable IPv6 DNS values.

After saving, open Windows Terminal or Command Prompt and run:

ipconfig /flushdns
ipconfig /all
nslookup example.com

The first command clears cached answers. The second displays adapter information and the DNS servers Windows believes are configured. The third asks a resolver to look up a domain and usually shows which server answered. Replace the example domain with a normal website that you are permitted to access. A successful response confirms that name resolution is functioning, but it does not prove that the query followed the VPN tunnel.

Configure DNS inside the VPN client when necessary

Many modern VPN and proxy clients create a virtual adapter or local DNS service. In that situation, Windows may show the virtual adapter as the active DNS path, while the physical Wi-Fi or Ethernet adapter still displays the router’s resolver. This is not automatically a leak or an error. The important question is which component receives the query and where it sends the request afterward.

In an official VPN client, look for settings named DNS, Use VPN DNS, Custom DNS, DNS leak protection, or Split tunneling. If the client offers remote DNS, prefer that option when the goal is to keep name resolution within the VPN path. If it offers only system DNS, Windows adapter settings may control the result. Read the client’s status page after connecting; some clients display the active DNS mode or the virtual adapter address.

Compatible clients use different terminology. Clash Verge may expose DNS settings under its profile or advanced configuration. sing-box commonly separates DNS servers, rules, and final outbound behavior. Shadowrocket is mainly used on Apple platforms, so it is not a native Windows option, but a subscription compatible with multiple clients may use different DNS defaults in each application. A subscription link imports nodes and rules; it does not guarantee that every client will interpret DNS settings identically.

Protocols also matter indirectly. Shadowsocks, VMess, Trojan, and Hysteria2 are proxy protocols with different transport and implementation behavior, while WireGuard is a VPN protocol that normally routes IP traffic through a virtual interface. The protocol itself does not decide whether Windows uses a particular DNS resolver. The client’s DNS interception, routing mode, and leak-protection implementation make that decision. Do not switch protocols merely because a DNS lookup fails; first establish whether the resolver is reachable and whether the client is capturing the query.

For a clean test, choose one control point at a time. Start with Windows DNS while the VPN is disconnected. Then connect the VPN and inspect the client’s DNS mode. Finally test the browser and a command-line application separately. Changing Windows DNS, browser DoH, client DNS, and TUN rules simultaneously makes it difficult to identify which change solved or caused the problem.

Verify the result and troubleshoot failed connections

Verification should cover both resolution and routing. First confirm that a domain resolves with nslookup. Then open a permitted website through the browser, test an application that follows the Windows proxy, and test one application that uses a different network stack. If only the browser works, the problem may be application compatibility rather than DNS.

Use ipconfig /displaydns to inspect cached entries and ipconfig /flushdns after changing settings. If you need to identify the path more closely, compare results with the VPN disconnected and connected. A different answer is not automatically wrong because DNS providers can use regional routing. Focus on whether the response is consistent, whether the intended client is answering, and whether the application can establish its next connection.

• ✅ Confirm the active adapter before editing DNS.
• ✅ Test with one VPN client only and close other proxy tools.
• ✅ Check IPv6 if IPv6 remains enabled on the network.
• ✅ Review split-tunneling rules for DNS services and target applications.
• ❌ Do not treat a connected status icon as proof that every program uses the tunnel.
• ❌ Do not repeatedly change nodes, protocols, and DNS at the same time.

Common error patterns

“DNS server not responding”: The resolver may be unreachable, the address may be mistyped, or a firewall may block the selected transport. Return to automatic DNS to confirm that the network itself works, then test a documented alternative.

Websites open, but an application fails: Check whether the application reads the Windows proxy, uses its own DNS, or is excluded by split tunneling. TUN mode can capture more IP traffic, but it may also conflict with corporate security software, virtual machines, or other adapters.

DNS changes appear to have no effect: The browser may be using Secure DNS, or the VPN client may intercept all queries. Inspect browser DNS settings and the client’s DNS mode rather than changing the same Windows field again.

Connections fail only after enabling TUN mode: Disable TUN temporarily and test system-proxy mode. If that restores connectivity, review permissions, virtual adapters, firewall rules, and the client’s DNS configuration. Re-enable features one at a time after the basic route works.

Some domains resolve but others do not: Clear caches, compare IPv4 and IPv6 behavior, and inspect whether rules send different domain categories to different resolvers. A domain-rule error can look like a DNS outage even when the resolver is healthy.

Custom DNS on Windows VPN: FAQ

Will custom DNS always make a VPN faster?

No. It may reduce the time needed to resolve a domain when the original resolver is slow or unreliable, but it cannot improve the capacity of the VPN route or reduce congestion between the client and node. Measure the complete task—lookup, connection establishment, and data transfer—rather than judging performance from DNS response time alone.

Should DNS be changed in Windows or in the VPN client?

Use the layer that actually handles your queries. If the client provides remote DNS or leak protection, configure that first. If it explicitly follows system DNS, Windows adapter settings may be sufficient. Browser-level DoH should be treated as a separate layer because it can bypass both the Windows resolver and the client’s expected DNS path.

Do I need to configure IPv6 DNS too?

Only if IPv6 is active and you want a complete, deliberate configuration. Changing IPv4 DNS while leaving IPv6 to another resolver can produce mixed results. For troubleshooting, compare both paths; do not disable IPv6 permanently unless you understand the effect on your network and applications.

Will importing a subscription link set custom DNS automatically?

Not necessarily. A subscription link normally provides nodes, profiles, or rules. The receiving client decides how to interpret DNS options, and some profiles may use their own DNS mode. After importing, inspect the client’s DNS and routing settings, then verify the active behavior rather than assuming that the imported profile matches another application.

For most Windows users, the safest workflow is simple: record the original settings, choose a documented resolver, change one layer, flush the cache, connect the VPN, and test DNS and application traffic separately. If the change does not solve the original issue, restore the previous configuration and investigate routing mode, TUN permissions, split tunneling, IPv6, or application proxy support instead of continuing to rotate DNS addresses.