DNS, leak prevention, and kill-switch protection

DNS, UDP, and kill-switch settings protect different parts of a traffic path. Configure them for the actual workload and verify normal access and failure behavior separately.

What you should confirm

• The kill-switch policy matches the business risk.
• DNS mode and per-node DNS are intentional.
• UDP behavior is appropriate for games, commerce, and ordinary browsing.
• A failed node does not silently fall back to a local public IP when strict protection is required.

Before you start

• Keep one management device outside the test rule.
• Record the current public IPv4 and DNS result.
• Have one healthy node and one device that can be disconnected from the node path.
• Export a configuration backup before changing the policy.

Four paths to keep separate

1. Routing path: which rule and node/group handle the device.
2. DNS path: where hostname queries are resolved.
3. UDP path: how UDP traffic is handled by the selected mode.
4. Failure path: what happens when the selected node or link is unavailable.

A successful web page only tests part of these paths.

1. Choose a kill-switch policy

Use strict protection when local fallback could associate a device with the wrong public identity. Use a permissive policy only when the workload explicitly needs local direct fallback and the risk is understood. Test the behavior by disconnecting the selected node path with one non-critical device.

2. Choose DNS optimization mode

Use the built-in high-security mode for the usual protected path. Use the compatibility mode when a known application cannot resolve through the protected path. DNS passthrough or an outbound resolver may be suitable for a controlled environment; document the choice.

3. Assign dedicated DNS only when needed

A node or VPN line may have its own DNS profile. Use a custom profile only with a tested resolver list. Verify the resolver from the test device, not only from the router page.

4. Choose a UDP optimization mode

Use the mode recommended for the workload. Game and commerce traffic can have different compatibility requirements. Test login, a sustained session, and a reconnect instead of relying on a TCP-only website.

5. Enable domain and path protection when required

Turn on domain recognition or link-tracking protection only when the workload needs it. Record which option changed and verify an ordinary domain, a routed domain, and a direct exception.

6. Verify in a fixed order

Normal access

1. Check the matching rule and selected node.
2. Query the public IPv4 from the device.
3. Check DNS location or resolver ownership.
4. Test one TCP and one UDP application.

Kill-switch behavior

1. Disconnect or disable the selected node path.
2. Confirm the device does not silently use the local public IP when strict protection is enabled.
3. Re-enable the path and wait for service recovery.
4. Repeat the public IP and DNS checks.

Recover from an unexpected result

Disable the newest setting or restore the last known-good backup. Keep the management device outside strict protection, then reapply one option and test again. Do not combine a DNS change with a proxy-mode change during the same diagnosis.

Common problems

Public IPv4 is correct but DNS shows the local region

Check the DNS profile, the device resolver, and whether the application uses its own encrypted DNS. Test the exact hostname used by the application.

Strict protection blocks domestic direct access

Make the direct path an explicit, understood exception or use a less strict policy for that workload. Verify that the exception does not broaden to unrelated destinations.

IPv6 tests fail after enabling protection

Check whether IPv6 is intentionally supported by the selected mode. Do not assume an IPv4 rule covers IPv6 traffic; disable or explicitly route IPv6 according to the deployment plan.

Commerce or game voice traffic fails

Review UDP optimization, node compatibility, and the failure path. Test the application with one node before changing the whole group.

Disabling a rule restores the local public IP

That confirms the rule was controlling the path. Re-enable it, check the target node and kill-switch policy, and repeat with a fresh connection.