Feature request: CDN / domain fronting for VPN tunnel traffic (Iran — all protocols and anti-censorship options fail)

[ThisIsMrAli]

Summary

Please add CDN / domain fronting for the VPN data plane, not only for API/control traffic. I am in Iran, where none of the available connection protocols work reliably, and Anti-censorship options (including Iran-specific presets) do not restore connectivity for me.

Your desktop client already implements strong censorship bypass for reaching Windscribe servers (login, server list, WireGuard config, etc.) via wsnet — including domain fronting via CDN, ECH, DoH, and backup endpoints (e.g. changelog 2.7.10+). That is valuable when API hostnames are blocked.

However, the VPN tunnel itself still connects to Windscribe node hostnames and IPs using standard protocols. In Iran, that is often not enough: even when the app can authenticate or load locations, the tunnel fails to establish or cannot be maintained.

---

What I have tried (all unsuccessful in Iran)

I have enabled Preferences → Anti-censorship (Circumvent censorship) and tried every connection protocol the client offers. None provide a working, stable VPN connection in my network conditions.

Protocol	Result in Iran
WireGuard	Does not connect / unstable
WireGuard + Anti-censorship (AmneziaWG / Iran presets)	Does not connect / no improvement
Stealth	Does not connect
WStunnel	Does not connect
OpenVPN UDP	Does not connect
OpenVPN TCP	Does not connect
IKEv2 (if available on my OS)	Does not connect
Different locations / auto-connect / server routing options	No improvement
Anti-censorship: protocol tweaks + server routing	No improvement

Observed behavior (typical):

• The app may open, and sometimes login or load server list (API/wsnet failover may partially work).
• Connection attempts fail, time out, or fail with “all protocols failed” (or equivalent).
• Stealth/WSTunnel still target Windscribe-specific endpoints; traffic does not appear as benign CDN traffic to major providers.
• Iran-focused AmneziaWG / anti-censorship presets do not change the outcome on my connection.

If logs would help, I can provide redacted connection logs on request.

---

Why API-only CDN fronting is not enough

From public documentation and changelog entries, domain fronting via CDN applies to API requests (via wsnet), not to the VPN tunnel payload path. In censored regions this creates a gap:

1. Control plane (API): may work or partially work thanks to CDN fronting, ECH, DoH, backup endpoints.
2. Data plane (VPN tunnel): still dials Windscribe node IPs/hostnames — often blocked, throttled, or DPI’d in Iran.

So users can appear “logged in” or see locations, but cannot actually use the VPN — which matches my experience.

---

Reference: what works in similar conditions elsewhere

Community Psiphon-based clients (e.g. builds using FRONTED-MEEK-CDN-OSSH) route tunnel traffic through CDN-fronted meek:

• TLS connects to CDN edge IPs or benign-looking domains (e.g. Fastly-backed hosts such as pypi.org, or Akamai edge addresses).
• Configurable SNI and optional custom edge IP lists for regions where defaults are filtered.
• Tunnel traffic is carried over HTTP/meek behind the CDN; the client does not expose a direct, blockable Windscribe hostname/IP for the outer connection.

That approach works in Iran for many users because the outer connection looks like ordinary CDN/HTTPS traffic, not a known VPN endpoint. It requires server-side CDN integration plus client dial overrides — it cannot be replicated by forking the desktop client alone without Windscribe operating matching CDN ingress.

---

Feature request

Please implement VPN tunnel CDN / domain fronting as a first-party feature:

1. Server / infrastructure

• Tunnel ingress behind one or more major CDNs (e.g. Fastly, Akamai), with meek-style or equivalent HTTP/TLS routing to Windscribe backends.
• Operational support for regions where specific edge IPs are blocked (rotating or region-specific edges).

2. Client (desktop and ideally mobile)

• Dial overrides for fronted tunnel protocols, including:
  • Remote address (CDN hostname or edge IP)
  • TLS SNI hostname
  • Certificate verification names (SANs)
  • Optional user-supplied CDN edge IPs and custom SNI (for power users when defaults fail in Iran)
• Behavior similar in spirit to Psiphon’s FrontedMeekDialOverrides / FrontedMeekDialOverridesProbability.

3. Protocol scope

• First priority: extend Stealth and/or WSTunnel (already HTTPS/TLS on 443) — best fit for CDN-style fronting.
• Keep WireGuard + AmneziaWG as a separate anti-DPI path; UDP CDN fronting is a different problem.
• Optional dedicated mode: “CDN fronting” or “Circumvent censorship (tunnel)” under Anti-censorship, distinct from API-only failover.

4. Documentation

• Clarify difference between:
  • API CDN fronting (existing wsnet behavior), and
  • Tunnel CDN fronting (requested).
• Note Iran / high-censorship use cases and recommended settings.

5. Iran-specific consideration

Given reports (including mine) that current Iran presets and all protocols fail, please treat Iran as a priority validation region for this feature, including testing with local ISPs and optional user-supplied edge IPs when government filtering targets known CDN ranges.

---

Expected benefit

• Users in Iran could connect even when Windscribe node IPs and hostnames are blocked.
• Reduces reliance on unofficial clients or unsafe workarounds.
• Aligns the data plane with the censorship investment already made on the control plane (wsnet).

---

Closing

I understand this is a significant infrastructure and protocol change, not a small UI tweak. I am asking because every current Windscribe option fails for me in Iran, while CDN-fronted tunnel designs demonstrably work in the same environment on other stacks.

Thank you for considering this. I am happy to provide logs, protocol failure screenshots, or further detail if the team needs it.