HabrAugust 11, 2026🇷🇺Translated from Russian

Configuration Drift Silently Breaks Multi-Hop Chains in sing-box Reality Fleet

A detailed post-mortem from the operators of an RCQ messenger network has exposed how configuration drift in a sing-box and Reality deployment left four out of seven nodes unreachable, while every monitoring check continued to report OK status.

Network Architecture

The fleet on 10 August comprised 14 endpoints running on seven machines hosted by four providers. Clients fetched a signed configuration (version 144) and used urltest to select routes. Since version 0.80, traffic follows a two-hop path: entry nodes know the client but not the destination, while exit nodes know the destination but not the client. This design requires every entry node to maintain an explicit allowlist of exit nodes because each machine ends its firewall rules with a reject policy.

What Went Wrong

Rules extracted from a live entry node showed only five permitted addresses: two islands and two relays. The remaining five nodes in the fleet were absent from the list. Four of those missing nodes belonged to a single provider, immediately limiting viable chains. Further inspection revealed inconsistent lists across machines; only three of the seven published nodes could reach each other. A free user whose entry landed in the first group therefore had just two possible exits, and the onion routing layer routed traffic through only three nodes instead of seven.

urltest never complained because it simply ignored dead chains and selected from the remaining live options. Canary checks verified that relays answered, external probes confirmed islands were alive, and the relay-lockdown.sh --check script only validated local services such as the masquerade host and mirrors. None of these tools compared the allowlist against the full set of relays published in the signed configuration.

Private Nodes and Additional Findings

Examination of two paid private nodes found no route section at all, meaning anyone holding the tenant key could route arbitrary traffic through the rented machine. The relay-lockdown.sh script also surfaced an outdated SNI value of www.apple.com on two machines, left over from an earlier period before operators realized the masquerade name must reside in the same ASN as the server address.

Remediation Steps

The check script was updated to compare the allowlist against relays listed in the signed configuration and to print missing addresses. A hardcoded fallback list grew from three to seven addresses. The script now runs every thirty minutes via cron on all nine machines and only expands the allowlist; narrowing remains a manual operation. Every new configuration is validated with sing-box check before deployment.

The root cause remains unknown because lists were never dated and drift leaves no log entries. The warning already present in the script header proved accurate: a snapshot locked down from one branch silently rejects every node added later.

Related articles

HabrPrivacy & Surveillance

Apple Updates Private Relay Domain for Sign in with Apple: Why Email Cannot Serve as Account Identity

Apple announced that new Private Relay addresses for Sign in with Apple will use the private.icloud.com domain starting later in 2026, while existing privaterelay.appleid.com addresses will continue functioning without interruption. The change highlights a deeper architectural issue: many applications incorrectly treat email addresses returned by Apple as stable identifiers rather than transient contact channels. Proper implementation requires separating the signed identity token, the verified subject claim, and the optional email relay address into distinct data models. Developers must validate the full identity token on the server, including signature, issuer, audience, nonce, and expiration, before linking any Apple identity to an internal account. Using provider and subject pairs as the unique key prevents duplicate accounts, accidental merges, and broken logins when relay domains or email claims change. The article provides concrete recommendations for data models, token verification boundaries, and test cases that remain resilient to future Apple updates.

SecuritylabPrivacy & Surveillance

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.

HabrPrivacy & Surveillance

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.

HabrPrivacy & Surveillance

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.