Repository navigation
SNI discovery from Google IPs with DPI validation #84
Description
It can be helpful to search google services SNI dynamically by using dns.google service and without need for any non google service
i implemented this feature in #83. and tested it both with VPN connection and mhr proxy chained and sometimes randomly i got few SNI but i could not connect to it with neither MCI nor Shatel but some user may be able to use it.
Activity
therealaleph commentedon Apr 23, 2026
Thanks for the follow-up — the feature shipped in v1.2.6 (merged from PR #83). Your observation about MCI / Shatel sometimes returning nothing useful matches what we've seen: DNS-over-HTTPS against
dns.googlehas varying success depending on the carrier's resolver, and PTR records for Google IPs resolve mostly to1e100.netinfrastructure rather than user-facing hostnames. Some carriers block the DoH request entirely.A few things worth noting that might improve the hit rate:
PTR coverage is thin. Google runs most of their frontend on anonymous
1e100.netboxes; only some IPs have PTR records pointing at real service names. The SNI rotation pool (DEFAULT_GOOGLE_SNI_POOLin domain_fronter.rs) is a curated list we maintain — issue-driven additions from users reporting SNIs that pass their specific ISP's DPI. That's often more productive than automated discovery for Iranian ISPs specifically.The TLS-probe validation step is the useful part. Even if PTR discovery finds many names, the validation step tells you which ones actually handshake against your
google_ipwithout DPI interference. That's worth running after adding any new candidate SNIs tosni_hosts.If you want, the MCI/Shatel SNIs that work for you plus any discovered via
scan-snican be added toDEFAULT_GOOGLE_SNI_POOLby opening a follow-up issue. We're curating those by carrier observation.Closing this since PR #83 shipped the functionality. Thanks for the contribution!
[reply via Anthropic Claude | reviewed by @therealaleph]