RU DPI/TSPU blocks protocol on v1.7.12 ("None of the endpoints are available"); v1.8.1-nightly.1 works; no auto-reconnect on silent endpoint loss

[supervisorx]

Please answer the following question for yourself before submitting an issue

• I checked to make sure that this issue has not already been filed

AdGuard VPN CLI version

1.7.12 (release) and 1.8.1-nightly.1

Environment

• OS: Debian 12 (bookworm), kernel 6.1.0-26-amd64
• Architecture: x86-64
• Usage: Linux gateway/NAT box — TUN mode, config set-tun-routing-mode NONE, set-change-system-dns off, set-bound-if-override enp6s18, connect --no-fork -y -l "..." under systemd, Restart=on-failure
• Locations: US (New York / Seattle)
• Network path: Russia, ISP with TSPU (DPI) equipment

Issue Details

Steps to reproduce:

1. Run v1.7.12 connected directly through a Russian ISP (TSPU present), New York location, TUN mode.
2. During the morning of 2026-08-20 (UTC+11) the tunnel data-plane starts dying periodically (every 15–60 min); by ~12:13 local the client cannot connect at all.
3. adguardvpn-cli connect fails with:

ERROR CLI_APP ~CliApp: Command finished with error:
    > None of the endpoints are available

4. At the same moment, plain TCP to every known endpoint on :443 from the same host succeeds (verified with timeout 5 bash -c "echo > /dev/tcp/<endpoint>/443" for each one) — connections are established at TCP level but killed at the protocol level.
5. Routing the client's own traffic through another VPN tunnel restores full connectivity to the same endpoints from the same host.
6. After upgrading to v1.8.1-nightly.1 the client connects directly again and stays connected (as of ~16:20 UTC+11).

Expected Behavior

• The transport should withstand TSPU/DPI signature-based interference (masking, endpoint rotation, or graceful fallback), so the tunnel keeps working from Russia during the day.
• When an upstream endpoint dies silently, the client should detect the dead data-plane and reconnect to a fresh endpoint automatically, without the process just sitting on dead connections.

Actual Behavior

Two distinct problems observed on v1.7.12:

1) Signature-based DPI blocking (time-of-day dependent):

• Night (12+ hours of uptime): perfectly stable.
• Morning: data-plane dies every 15–60 min; the daemon process keeps running while no data flows, and there is nothing in the logs.
• Midday: complete block — connect exits with "None of the endpoints are available", while plain TCP :443 to every endpoint still succeeds (protocol layer killed after establishment).
• Encapsulating the client's traffic in another VPN tunnel makes the same endpoints work again from the same host — confirming DPI/TSPU as the cause.

2) No auto-recovery on silent endpoint loss:
Several times the data-plane stopped while the daemon stayed alive: TCP connections dead, no data flow, no log entries at all, status still reported connected. A manual service restart (which picks fresh endpoints) fixed it instantly every single time. With --no-fork under systemd this has to be covered by external watchdogs.

Endpoints observed during the incidents: 23.27.246.168, 103.115.19.250, 103.115.19.170, 138.124.33.46, 89.125.13.207, 104.154.125.27, 149.102.254.129, 104.143.217.188

Screenshots

Screenshot 1

Additional Information

• v1.8.1-nightly.1 currently connects directly where 1.7.12 could not. Not sure yet whether it's better protocol masking or just fresh endpoint ranges — tomorrow's DPI window will tell. Happy to report back with results.
• journald logs from the v1.7.12 incidents are available on request.
• Context: we run the CLI as a policy-routing gateway for a small office; the NONE routing mode + set-bound-if-override make it an excellent fit for this use case. Thanks for the great tool!

[supervisorx]

Update (2026-08-20, ~19:19 UTC+11): v1.8.1-nightly.1 got blocked as well. It stayed connected directly for ~3 hours (16:20–19:17), then the same failure mode returned: the daemon exits with None of the endpoints are available and systemd keeps restarting it, while plain TCP :443 to the endpoints (104.143.217.188, 149.102.254.129, 104.154.125.27) still succeeds from the same host.

So the nightly is affected too — the earlier direct success looks like a quieter DPI window rather than better masking.

One more observation that may be useful: earlier in the day, during the intermittent phase, a simple client restart (which picks fresh endpoints) restored connectivity every time. During the hard-block phase restarts stopped helping at all — no endpoint could be reached until the interference relaxed. So the blocking appears to have two phases: per-flow/endpoint (recoverable by reconnect) and a wider one (not recoverable).

[NoName135790]

Confirming from a different setup — same underlying behaviour.

Environment: v1.7.12 in SOCKS mode (not TUN) on a MIPS router behind CGNAT, three
independent instances, Russian ISP with DPI. Filed separately as #183 with netstat evidence.

Matching observations:

• Silent data-plane death with the daemon alive and status reporting a connection —
  identical to your point 2. In my case netstat shows the sockets stuck ESTABLISHED with a
  non-zero Send-Q, and the client loops VPN_SS_RECOVERING forever without ever re-dialing
  a new endpoint. disconnect + connect fixes it every time.
• Time-of-day clustering matches your DPI window: over 2.5 days my watchdog logged 9 forced
  reconnects, with three different instances failing within ~20 minutes of each other at
  02:23 / 02:33 / 02:44, and another at 03:24, plus a morning one at 11:37 (UTC+5).
  All three were on the same entry IP at that moment.
• Two of the endpoints from your list — 103.115.19.170 and 104.143.217.188 — are exactly
  the ones my instances were using during those incidents.

So the "no auto-recovery on silent endpoint loss" part reproduces on a completely different
platform and in a different mode, which suggests it is in the shared core rather than in the
TUN path.

Very interested in your v1.8.1-nightly.1 results — please do report back.

[supervisorx]

One more data point on the intermittent phase (2026-08-21/22): besides full connection loss, we observed a partial degradation mode that only affects new connections:

• Applications routing traffic through the tunnel saw waves (2–7 min each, several per hour during the day) where ~30% of new TLS handshakes fail with EOF, while long-lived streams keep working fine.
• A single lightweight probe once per 90 s stayed green throughout those waves — the client's established upstream connections survive; it's the new flows that get dropped.
• A service restart restores normality in ~25 s; on our side that matched ~26 forced reconnects over 24 h during daytime hours.

This per-flow behaviour is consistent with DPI dropping newly-dialled upstream connections while leaving established ones alone. It may also explain the "silent death" signature described above (sockets stuck ESTABLISHED with non-empty Send-Q): the client holds on to upstreams that can no longer carry new streams and never re-dials.

A keepalive-based health monitor is not enough to detect this — a burst of several fresh handshakes per check is what catches it.

[NoName135790]

Useful distinction from my side (#183, SOCKS mode): in my full-outage incidents the held
upstreams were not merely unable to carry new streams — they were dead themselves. netstat
showed them ESTABLISHED with a stuck non-zero Send-Q (287–295 bytes unacked) while healthy
instances on the same entry IP had empty queues. So there seem to be two stages: your partial
phase (established fine, new flows dropped), and a full one where the established connections
also stop being acknowledged. In both the client never re-dials.

Your point about probe design matches my experience: a single probe per check is a coin flip
at ~30% flow-failure rates. I've switched my watchdog to three fresh handshakes per check,
reconnecting on 2+ failures — will report if the partial phase shows up in the stats.