[GH-ISSUE #1423] feature: enhance site split tunneling

bsakaguchi commented

2026-10-13 20:24:41 +00:00

Owner

Originally created by @Nethius on GitHub (Feb 18, 2025).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/1423

this issue is a stub to close duplicate issues, the plan to implement this feature will be described later

Originally created by @Nethius on GitHub (Feb 18, 2025). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/1423 this issue is a stub to close duplicate issues, the plan to implement this feature will be described later

bsakaguchi commented

2026-10-13 20:24:42 +00:00

Author

Owner

@DADA30000 commented on GitHub (May 29, 2025):

damn that's a lot of similar issues

@DADA30000 commented on GitHub (May 29, 2025): damn that's a lot of similar issues

bsakaguchi commented

2026-10-13 20:24:43 +00:00

Author

Owner

@firstvf commented on GitHub (May 29, 2025):

damn that's a lot of similar issues

I agree, there are so many problems that I couldn’t take it anymore and switched to another client. Amnesia works well on phones, but the Windows client is just awful. I ran into a huge number of issues, made reports, and wrote to support, but it feels like support doesn’t care about these problems - they only offer workarounds

@firstvf commented on GitHub (May 29, 2025): > damn that's a lot of similar issues I agree, there are so many problems that I couldn’t take it anymore and switched to another client. Amnesia works well on phones, but the Windows client is just awful. I ran into a huge number of issues, made reports, and wrote to support, but it feels like support doesn’t care about these problems - they only offer workarounds

bsakaguchi commented

2026-10-13 20:24:43 +00:00

Author

Owner

@DADA30000 commented on GitHub (May 29, 2025):

damn that's a lot of similar issues

I agree, there are so many problems that I couldn’t take it anymore and switched to another client. Amnesia works well on phones, but the Windows client is just awful. I ran into a huge number of issues, made reports, and wrote to support, but it feels like support doesn’t care about these problems - they only offer workarounds

yeah, I also just use singbox on my NixOS machine rn

@DADA30000 commented on GitHub (May 29, 2025): > > damn that's a lot of similar issues > > I agree, there are so many problems that I couldn’t take it anymore and switched to another client. Amnesia works well on phones, but the Windows client is just awful. I ran into a huge number of issues, made reports, and wrote to support, but it feels like support doesn’t care about these problems - they only offer workarounds yeah, I also just use singbox on my NixOS machine rn

bsakaguchi commented

2026-10-13 20:24:43 +00:00

Author

Owner

@xcviko commented on GitHub (Jun 22, 2025):

damn that's a lot of similar issues

I agree, there are so many problems that I couldn’t take it anymore and switched to another client. Amnesia works well on phones, but the Windows client is just awful. I ran into a huge number of issues, made reports, and wrote to support, but it feels like support doesn’t care about these problems - they only offer workarounds

what client do you use?

@xcviko commented on GitHub (Jun 22, 2025): > > damn that's a lot of similar issues > > I agree, there are so many problems that I couldn’t take it anymore and switched to another client. Amnesia works well on phones, but the Windows client is just awful. I ran into a huge number of issues, made reports, and wrote to support, but it feels like support doesn’t care about these problems - they only offer workarounds what client do you use?

bsakaguchi commented

2026-10-13 20:24:43 +00:00

Author

Owner

@AndreyNikiforov commented on GitHub (Nov 12, 2025):

this issue is a stub to close duplicate issues, the plan to implement this feature will be described later

Is there a plan and a timeline to share? Any progress since Feb? I am interested in domain rules on iOS and on OpenWRT to emulate app-based rules on Android.

@AndreyNikiforov commented on GitHub (Nov 12, 2025): > this issue is a stub to close duplicate issues, the plan to implement this feature will be described later Is there a plan and a timeline to share? Any progress since Feb? I am interested in domain rules on iOS and on OpenWRT to emulate app-based rules on Android.

bsakaguchi commented

2026-10-13 20:24:44 +00:00

Author

Owner

@magnastrazh commented on GitHub (Apr 23, 2026):

Hi waiting for wildcard for split rules

@magnastrazh commented on GitHub (Apr 23, 2026): Hi waiting for wildcard for split rules

bsakaguchi commented

2026-10-13 20:24:44 +00:00

Author

Owner

@MadPeachTM commented on GitHub (May 25, 2026):

still no news?

@MadPeachTM commented on GitHub (May 25, 2026): still no news?

bsakaguchi commented

2026-10-13 20:24:44 +00:00

Author

Owner

@c1on commented on GitHub (Jun 1, 2026):

Really looking forward to this feature, it's simply necessary now!

@c1on commented on GitHub (Jun 1, 2026): Really looking forward to this feature, it's simply necessary now!

bsakaguchi commented

2026-10-13 20:24:44 +00:00

Author

Owner

@Froke commented on GitHub (Jul 30, 2026):

Site split tunneling stores only one IPv4 address and never refreshes it

I can reproduce this on:

OS: CachyOS Linux x86_64
AmneziaVPN: 5.0.0.5
Route mode: VpnAllExceptSites (“Addresses from the list should not be accessed via VPN”)

Current behavior

When a hostname is added to site-based split tunneling:

The client resolves it only once.
Only the first IPv4 address returned by DNS is stored.
Other A records are discarded.
The stored address is not refreshed when the client starts or reconnects.
If DNS resolution initially fails, the hostname remains stored with an empty IP and is not retried automatically.
Imported hostnames with an empty ip field are also not resolved automatically.

The configuration effectively contains a map like hostname -> one IPv4 address, for example ozon.ru -> 185.73.194.82.

This makes hostname-based split tunneling unreliable for:

domains with multiple A records;
CDNs and load balancers;
DNS round-robin;
short-TTL records;
CNAME chains whose final addresses change;
domains that were temporarily unavailable during the initial lookup.

After a DNS record changes, traffic to the new address no longer follows the configured split-tunneling policy. The UI still shows the hostname, so the configuration appears valid even though it is only partially working.

The current implementation confirms this behavior:

addSite() calls QHostInfo::lookupHost() only when the site is initially added;
onHostResolved() stops after the first IPv4 address (break);
fillSites() only restores the previously saved hostname/IP pair and does not resolve it again.

Source: ipSplitTunnelingController.cpp

Expected behavior

Hostnames should remain the source of truth. The client should:

Follow CNAME chains.
Keep all relevant A records, not only the first one.
Ideally support AAAA records as well.
Resolve hostnames before every VPN connection.
Refresh addresses according to DNS TTL or when the network changes.
Retry hostnames that previously failed to resolve.
Atomically replace obsolete routes with newly resolved addresses.
Preserve the last known working addresses during temporary DNS failures.
Provide a manual “Refresh DNS addresses” action in the UI.
Clearly display resolution failures instead of silently keeping an empty IP.

Literal IP addresses and CIDR entries should continue to work without DNS resolution.

Suggested acceptance criteria

Every IPv4 address returned for a hostname follows the selected routing policy.
A DNS address change is applied without deleting and re-adding the hostname.
CNAME-based domains work correctly.
Temporary DNS failure does not permanently break the entry.
Imported entries containing only hostname are resolved automatically.
DNS resolution uses the appropriate direct or tunneled resolver and does not introduce unintended DNS leaks.

@Froke commented on GitHub (Jul 30, 2026): ### Site split tunneling stores only one IPv4 address and never refreshes it I can reproduce this on: - OS: CachyOS Linux x86_64 - AmneziaVPN: 5.0.0.5 - Route mode: `VpnAllExceptSites` (“Addresses from the list should not be accessed via VPN”) #### Current behavior When a hostname is added to site-based split tunneling: 1. The client resolves it only once. 2. Only the first IPv4 address returned by DNS is stored. 3. Other A records are discarded. 4. The stored address is not refreshed when the client starts or reconnects. 5. If DNS resolution initially fails, the hostname remains stored with an empty IP and is not retried automatically. 6. Imported hostnames with an empty `ip` field are also not resolved automatically. The configuration effectively contains a map like `hostname -> one IPv4 address`, for example `ozon.ru -> 185.73.194.82`. This makes hostname-based split tunneling unreliable for: - domains with multiple A records; - CDNs and load balancers; - DNS round-robin; - short-TTL records; - CNAME chains whose final addresses change; - domains that were temporarily unavailable during the initial lookup. After a DNS record changes, traffic to the new address no longer follows the configured split-tunneling policy. The UI still shows the hostname, so the configuration appears valid even though it is only partially working. The current implementation confirms this behavior: - `addSite()` calls `QHostInfo::lookupHost()` only when the site is initially added; - `onHostResolved()` stops after the first IPv4 address (`break`); - `fillSites()` only restores the previously saved hostname/IP pair and does not resolve it again. Source: [ipSplitTunnelingController.cpp](https://github.com/amnezia-vpn/amnezia-client/blob/dev/client/core/controllers/ipSplitTunnelingController.cpp) #### Expected behavior Hostnames should remain the source of truth. The client should: 1. Follow CNAME chains. 2. Keep all relevant A records, not only the first one. 3. Ideally support AAAA records as well. 4. Resolve hostnames before every VPN connection. 5. Refresh addresses according to DNS TTL or when the network changes. 6. Retry hostnames that previously failed to resolve. 7. Atomically replace obsolete routes with newly resolved addresses. 8. Preserve the last known working addresses during temporary DNS failures. 9. Provide a manual “Refresh DNS addresses” action in the UI. 10. Clearly display resolution failures instead of silently keeping an empty IP. Literal IP addresses and CIDR entries should continue to work without DNS resolution. #### Suggested acceptance criteria - Every IPv4 address returned for a hostname follows the selected routing policy. - A DNS address change is applied without deleting and re-adding the hostname. - CNAME-based domains work correctly. - Temporary DNS failure does not permanently break the entry. - Imported entries containing only `hostname` are resolved automatically. - DNS resolution uses the appropriate direct or tunneled resolver and does not introduce unintended DNS leaks.

bsakaguchi referenced this issue

2026-10-13 21:16:59 +00:00

[PR #590] 2nd improve install_docker.sh #1943

bsakaguchi referenced this issue

2026-10-13 21:17:00 +00:00

[PR #591] [MERGED] Introduction of direct checking of package installation results. #1944

Rows
Columns

[GH-ISSUE #1423] feature: enhance site split tunneling #591

Site split tunneling stores only one IPv4 address and never refreshes it

Current behavior

Expected behavior

Suggested acceptance criteria