Summary
blockcheckw status currently classifies domains as Available / SNI Blocked / IP Blocked / DNS
Failed.
It misses a critical case: IP-based throttling — where TCP connects, TLS handshake passes,
but data transfer is throttled to near-zero after ~16-19KB.
Real-world example: Discord (March 2026). 4 out of 5 Cloudflare IPs throttled,
TLS handshake succeeds, first ~19KB arrive, then speed drops to 0.
Users see "infinite loading" and think the bypass tool is broken.
Problem
Current status flow:
DNS → TCP SYN → TLS + HTTP HEAD → verdict
HTTP HEAD returns 200 → status reports "Available". But the site doesn't actually work
because bulk data transfer is throttled.
Proposed Solution
Add download test phase after HTTP HEAD succeeds:
DNS → TCP SYN → TLS + HTTP HEAD → Download ~100KB → verdict
New verdict: IpThrottled
Detection logic:
- Request a known-large resource (or the page itself with full body)
- If < 50KB downloaded in 10 seconds →
IpThrottled
- If ≥ 50KB at reasonable speed →
Available
http_test_data() already exists in network/http_client.rs with streaming body support.
interpret_data_transfer_result() already detects DpiDataLimit in 10-25KB range.
The infrastructure is there — needs to be wired into cmd/status.rs.
Output Example
discord.com
DNS: ✓ resolves (162.159.136.232, ...)
TCP SYN: ✓ connects
TLS: ✓ handshake OK
Download: ✗ THROTTLED — 19KB/10s (expected >50KB)
Verdict: IP-THROTTLED
ℹ Traffic to this resource's IP addresses is throttled by the ISP.
DPI bypass (zapret2) won't help — throttling is IP-based.
Solution: VPN or proxy (Podkop, AmneziaWG, VLESS).
Per-IP breakdown (nice to have)
Discord has 5 IPs, only 1 works. Would be useful to test each resolved IP separately
and show which are throttled:
162.159.128.233: ✗ throttled (19KB/10s)
162.159.135.232: ✗ throttled (17KB/10s)
162.159.136.232: ✓ OK (15MB/0.6s)
162.159.137.232: ✗ throttled (19KB/10s)
162.159.138.232: ✗ throttled (17KB/10s)
JSON output
Add to StatusDomainResult:
{
"domain": "discord.com",
"block_type": "ip_throttled",
"speed_kbps": 1.2,
"ips_tested": [
{"ip": "162.159.128.233", "speed_kbps": 1.2, "throttled": true},
{"ip": "162.159.136.232", "speed_kbps": 24000.0, "throttled": false}
]
}
Summary
blockcheckw statuscurrently classifies domains as Available / SNI Blocked / IP Blocked / DNSFailed.
It misses a critical case: IP-based throttling — where TCP connects, TLS handshake passes,
but data transfer is throttled to near-zero after ~16-19KB.
Real-world example: Discord (March 2026). 4 out of 5 Cloudflare IPs throttled,
TLS handshake succeeds, first ~19KB arrive, then speed drops to 0.
Users see "infinite loading" and think the bypass tool is broken.
Problem
Current
statusflow:DNS → TCP SYN → TLS + HTTP HEAD → verdict
HTTP HEAD returns 200 → status reports "Available". But the site doesn't actually work
because bulk data transfer is throttled.
Proposed Solution
Add download test phase after HTTP HEAD succeeds:
DNS → TCP SYN → TLS + HTTP HEAD → Download ~100KB → verdict
New verdict:
IpThrottledDetection logic:
IpThrottledAvailablehttp_test_data()already exists innetwork/http_client.rswith streaming body support.interpret_data_transfer_result()already detectsDpiDataLimitin 10-25KB range.The infrastructure is there — needs to be wired into
cmd/status.rs.Output Example
discord.com
DNS: ✓ resolves (162.159.136.232, ...)
TCP SYN: ✓ connects
TLS: ✓ handshake OK
Download: ✗ THROTTLED — 19KB/10s (expected >50KB)
Per-IP breakdown (nice to have)
Discord has 5 IPs, only 1 works. Would be useful to test each resolved IP separately
and show which are throttled:
JSON output
Add to StatusDomainResult:
{ "domain": "discord.com", "block_type": "ip_throttled", "speed_kbps": 1.2, "ips_tested": [ {"ip": "162.159.128.233", "speed_kbps": 1.2, "throttled": true}, {"ip": "162.159.136.232", "speed_kbps": 24000.0, "throttled": false} ] }