TSPU Filtering Disrupts Timeweb Cloud Servers: Diagnosis, CDN Failures, and Reverse Proxy Bypass

Russian hosting provider Timeweb Cloud began experiencing selective TSPU filtering in early June that prevented clients from accessing WordPress sites without a VPN. Two commercial sites hosted on the same VPS stopped opening for users in the same city and later for the administrator connecting over a wired connection.

Initial troubleshooting ruled out fail2ban, Google Captcha, registry blocks by Roskomnadzor, and judicial decisions. Competitors on other providers remained accessible, pointing to a provider-specific issue. The observed behavior showed TCP connections on port 443 establishing successfully, followed by a missing Server Hello and a 20-second timeout, while SSH on port 22 and ICMP traffic continued without loss.

The filtering proved dynamic: it initially blocked by SNI at night, later switched to IP-based blocking by midday, and intermittently relaxed in the evening. Timeweb support acknowledged the problem on June 5 in ticket 12068181, attributing it to changes in TSPU settings and noting that the issue varied by operator, region, and browser. Similar reports appeared from Beget and Selectel around the same period.

Obtaining new IP addresses proved ineffective, with filtered behavior recurring on fresh addresses. DNS record updates after IP changes also caused extended outages. Attempts to place Yandex Cloud CDN in front of the origin succeeded for static content but failed for any POST requests, returning 405 errors for wp-login.php, cart operations, and AJAX calls.

A stable workaround used a minimal nginx reverse proxy on a separate Russian cloud VPS. The configuration correctly forwards the Host header and SSL server name, supports all HTTP methods, and includes tuned proxy buffers to prevent 502 errors on large cookie responses from logged-in WordPress administrators. ACME challenge paths are explicitly proxied to allow Let's Encrypt certificate issuance, and a synchronization script copies updated certificates from the origin server.

Testing with curl --resolve allowed validation of both GET and POST functionality before DNS cutover. Additional community suggestions include disabling TLS 1.3 or requesting subnet whitelisting through legal entities, though these were not tested in this case.

Later tickets submitted to Timeweb in July received requests for mtr traces, which cannot detect selective DPI interference because the mechanism allows TCP establishment before dropping TLS packets. Support closed the tickets claiming resolution despite ongoing symptoms reported by clients.