One Request, Five Observers: What Websites, Providers, DNS and VPNs Learn When Loading a Page
The phrase “I have HTTPS, so my provider sees nothing” sounds convincing until one asks what exactly counts as “nothing.” Site name, specific article, message text, external IP, account, browser language and connection time are different data points that appear at different points along the route and reach different parties. This turns most privacy debates into exchanges of half-truths.
Consider an ordinary request to https://news.example/articles/privacy?from=mail from a home connection, standard browser and correctly configured HTTPS site. Corporate networks, antivirus products that replace certificates and decrypting proxies are separate cases where the network administrator can see more.
Browser knows the full address before any packet is sent
Before the first network packet leaves, the browser already possesses the complete URL, including path and query parameters, plus any stored state such as cookies, site data and login tokens. It applies strict rules when deciding what to send to each origin. Scripts on the page can read language, timezone, screen size and graphics API results, yet localStorage remains isolated by origin, HttpOnly cookies stay invisible to JavaScript, and the site cannot enumerate all open tabs or full history.
DNS resolver learns only the domain name
To reach the server the browser must resolve the domain. An unencrypted DNS query can be observed by the local network and ISP. The resolver itself sees the domain and client IP but never the URL path or credentials. DNS over HTTPS and DNS over TLS encrypt the query between device and chosen resolver, shifting trust to that resolver while the ISP sees only the connection to the resolver service.
ISP observes metadata but not HTTPS content
Once the IP address is known, the browser performs a TLS handshake followed by the encrypted HTTP request. The provider normally sees client and destination IPs, port 443, traffic volume, duration, unencrypted DNS queries and the Server Name Indication (SNI) unless Encrypted Client Hello (ECH) is used. Even with ECH the destination IP, volume and timing remain visible. One IP address frequently hosts many domains behind a CDN, so IP alone does not reliably identify the site.
Destination site receives the richest set of signals
The site (or its CDN) decrypts the traffic and obtains the client IP, full URL path and parameters, HTTP headers including Referer (subject to Referrer-Policy), cookies, authorization data, User-Agent information and any values collected by page scripts. Account login creates a stable identifier that survives IP changes. Browser fingerprinting combines language, timezone, screen dimensions and rendering behaviour to probabilistically link visits.
Third-party resources introduce additional observers
A single page often loads images, fonts, analytics scripts and widgets from multiple domains. Each third party receives its own request headers, cookies and identifiers. Removing cookies for one site therefore does not eliminate tracking performed by other origins.
VPN changes the route but adds a new observer
With a full-tunnel VPN the home ISP sees only the encrypted connection to the VPN server. The destination site sees the VPN exit IP. The VPN provider itself becomes the new observer that knows the user’s real IP and all destination addresses. HTTPS still protects content from the VPN, provided the user has not installed a trusted interception certificate.
A comparison of visibility with and without VPN:
- Site: home or mobile IP → VPN exit IP
- ISP: direct connections and sometimes DNS/SNI → connection to VPN and tunnel metadata
- VPN service: not involved → user IP, final destinations and DNS depending on configuration
- DNS resolver: domain and client IP → domain and VPN exit IP if DNS travels inside the tunnel
- Cookies and account: remain in the browser in both cases
- Browser fingerprint: largely preserved in both cases
Incognito mode clears local state, not network visibility
Incognito opens a temporary session whose cookies and storage are discarded when the window closes. Network observers, the destination site and any active VPN still see the same traffic metadata. Chrome documentation explicitly states that sites, the ISP and network administrators may continue to observe activity.
Effective privacy therefore requires first defining the precise information one wishes to hide and from whom, then selecting the appropriate combination of HTTPS, secure DNS, VPN routing, separate browser profiles and reduced third-party scripts.
Related articles
Step-by-Step Guide to Removing Personal Data from Search Engines, Databases and Social Networks
The guide provides a practical seven-step checklist for individuals seeking to reduce their digital footprint by removing personal information from websites, search engines, and social platforms. It emphasizes starting with a 20-minute audit to compile exact URLs rather than vague requests, followed by direct contact with site owners under Russia's 152-FZ personal data law. Subsequent steps cover submissions to Yandex and Google for de-indexing, manual cleanup of old social media accounts, handling of phone numbers in caller ID services, and removal from directories and review sites. The process includes templates for formal requests, timelines for responses, and escalation paths to Roskomnadzor when operators fail to comply. Special attention is given to leaked databases, where technical removal is impossible, and to web archives such as Internet Archive that require specific legal justifications. The full cycle is estimated at two months, with quarterly maintenance recommended to sustain results.
telEgo Combines MTProxy and WEB Proxy on Single Port 443 with TLS Fronting
telEgo, a Go-based Telegram MTProxy implementation using the gnet network engine, now supports all four WEB proxy transport modes alongside traditional MTProxy connections on the same public port 443. The solution allows FakeTLS with ee secrets, Obfuscated2 with dd secrets, and WEB carriers including https, https-lanes, websocket, and websocket-lanes without requiring separate ports or secret changes. telEgo performs handshake detection, forwards ordinary TLS traffic to Nginx on a private port using PROXY protocol v2, and routes authenticated WEB streams back to the internal MTProxy backend. The setup uses Docker Compose with separate containers for telEgo, Nginx, and certificate management via Certbot, keeping ports 8080, 8443, and 8444 internal. Existing MTProxy links continue to function while new WEB proxy links become available for Telegram Desktop. The configuration supports Prometheus metrics, connection limits, and automatic certificate renewal through systemd timers.
From HAProxy to VLESS+Reality: Overcoming DPI Blocks for MTProto Telegram Proxies
A detailed case study describes the challenges of running an MTProto proxy for Telegram on Russian servers facing ISP-level DPI. Initial attempts using HAProxy TCP relays and SOCKS5 tunnels failed because modern DPI systems detect MTProto and fake-TLS signatures regardless of transparent forwarding. The author eventually succeeded by layering mtg with an Xray VLESS+Reality tunnel that performs genuine TLS 1.3 handshakes to legitimate domains. Key configuration pitfalls included the xtls-rprx-vision flow breaking non-TLS payloads, missing mux causing handshake timeouts on short-lived connections, and provider-specific network policies. Final architecture places mtg and an Xray client on the Russian entry server while the foreign exit server runs Xray in VLESS+Reality inbound mode. The guide supplies complete docker-compose examples, key generation commands, and a checklist of common misconfigurations to avoid.
TLS MITM and Throttling to 10 Mbps: Two Distinct Network Degradation Patterns Observed in Russia
Russian users have reported sudden slowdowns and instability on international connections over the past several days. Analysis of Tunnel Cat logs revealed two separate issues that produce similar user symptoms but require different diagnostic approaches. The first pattern involves successful TCP and TLS handshakes followed by sharp drops in throughput, often from 80 Mbps to 8-12 Mbps, consistent with DPI-based throttling of international traffic. The second pattern shows TLS certificate substitution on Windows systems, indicating active man-in-the-middle interception. Tunnel Cat now detects invalid certificates and terminates such sessions, yet the underlying network phenomena persist. The observations highlight the need to examine both bandwidth dynamics and certificate chains when troubleshooting connectivity problems from Russia.