SOCKS5 UDP ASSOCIATE ने हमारा DNS कैसे तोड़ दिया

करीब एक साल पहले, हमने एक RFC feature को बिल्कुल spec के मुताबिक implement किया — और production down हो गया। Rollback किया, खोदकर निकाला, और root cause मिला। Spoiler: DNS की गलती नहीं थी। हम भूल गए थे कि ports एक सीमित resource हैं।

निजी मोबाइल प्रॉक्सी की आवश्यकता है?
अभी मोबाइल प्रॉक्सी बनाएं!
निःशुल्क 48 घंटे का परीक्षण शुरू करें

TL;DR

हमने अपने proxy servers पर iProxy.online में full SOCKS5 UDP ASSOCIATE support (RFC 1928) जोड़ा। कुछ दिन बाद, DNS resolve होना बंद हो गया, tunnels टूटने लगे, और random services timeout देने लगीं। Rollback किया और जांच शुरू की। Root cause था ephemeral port exhaustion — Linux पर हजारों UDP associations ने एक-एक dedicated port पकड़ रखा था, और पूरा system-wide port pool खाली हो गया। Fix दो configuration knobs से हुआ। Problem ढूंढने में काफी ज्यादा वक्त लगा।

SOCKS5 UDP ASSOCIATE क्या होता है?

SOCKS5, जो RFC 1928 में define है, तीन commands support करता है: CONNECT (TCP tunneling), BIND (inbound TCP connections accept करना), और UDP ASSOCIATE (UDP datagrams relay करना)। ज्यादातर proxy providers सिर्फ CONNECT implement करते हैं। UDP ASSOCIATE सबसे मुश्किल है — और यही real-time applications के लिए ज़रूरी है जैसे VoIP, gaming, DNS-over-UDP, और QUIC।

ये कैसे काम करता है:

1. Client एक TCP control connection खोलता है SOCKS5 server से।
2. Client इस TCP connection पर UDP ASSOCIATE request भेजता है।
3. Server एक dedicated UDP socket allocate करता है एक ephemeral port पर और client को address और port number वापस भेजता है।
4. Client उस relay port पर UDP datagrams भेजता है। Server उन्हें destination तक forward करता है और responses वापस relay करता है।
5. Association तब तक जिंदा रहता है जब तक TCP control connection बंद नहीं होता या session timeout नहीं हो जाता।

हर एक UDP association server पर एक अलग ephemeral port bind करता है। यही वो critical detail है जो सब कुछ बिगाड़ देती है।

अब यहाँ trap समझिए। UDP connectionless है। कोई FIN नहीं, कोई RST नहीं। आपको कैसे पता चलेगा कि client का काम हो गया और port free किया जा सकता है?

1. TCP control connection बंद होने का इंतज़ार करो — RFC का signal यही है। लेकिन clients इसे हमेशा के लिए open रख सकते हैं।
2. Idle timeout। अगर X seconds तक कोई datagram नहीं आता, तो association kill कर दो। लेकिन अगर timeout बहुत ज्यादा रखा, तो sockets इकट्ठा होते जाते हैं।

हमने generous timeouts सेट किए और ये cap नहीं लगाया कि एक client कितने associations खोल सकता है। नतीजा — sockets की भीड़ लग गई।

हमारा Setup

iProxy.online में हम 100+ देशों और 600+ mobile carriers में mobile proxy infrastructure operate करते हैं — असली Android phones को proxy servers में बदलते हैं। अगर आप इस concept में नए हैं, तो 4G proxy network कैसे बनाएं वाली हमारी गाइड में architecture विस्तार से बताया गया है। India में Jio, Airtel, Vi जैसे carriers पर ये बखूबी काम करता है। हमारे backend SOCKS5 servers हजारों concurrent connections handle करते हैं।

करीब एक साल पहले, हमने full UDP ASSOCIATE support शिप करने का फैसला किया — पूरी तरह RFC-compliant बनो और वो use cases unlock करो जो ज्यादातर competitors serve नहीं कर पाते: VoIP proxying, game traffic, QUIC-based protocols। Implementation सही था। Tests pass हुए। Ship कर दिया।

---

इस scale पर proxy infrastructure बनाने का मतलब है कि हर protocol decision के real consequences होते हैं। iProxy.online में हर Android device एक independent mobile proxy server की तरह काम करता है — SOCKS5, HTTP, और अब full UDP — सब एक dashboard या Telegram bot से manage होता है। अगर आप पहले समझना चाहते हैं कि system कैसे काम करता है इससे पहले कि पढ़ें कि हमने इसे कैसे तोड़ा, तो 48 घंटे का फ्री ट्रायल शुरू करें — कोई credit card नहीं चाहिए, सिर्फ ₹500/महीने ($6/month) से plans शुरू।

---

क्या गड़बड़ हुई

कुछ दिन बाद, production servers में अजीब और seemingly unrelated symptoms दिखने लगे:

• DNS resolve होना बंद हो गया। Internal services एक-दूसरे को hostname से find नहीं कर पा रही थीं।
• Tunnels टूट गए। Servers की management connectivity खत्म हो गई।
• NTP synchronization fail हो गया। Server clocks में drift आने लगा।
• Random UDP-based services timeout देने लगीं बिना किसी clear pattern के।

Failure gradual नहीं था — एक cliff की तरह था। घंटों सब ठीक चलता, फिर अचानक एक ही host पर multiple services एक साथ fail हो जातीं। UDP ASSOCIATE rollback किया और जांच शुरू की।

Root Cause कैसे मिला

हमारा पहला अंदाज़ा गलत था। DDoS attacks चेक किए, memory leaks देखे, disk I/O saturation, CPU load — सब normal। Application-level health checks सब हरे दिख रहे थे ठीक उस पल तक जब सब कुछ मर गया।

Breakthrough low-level system metrics से मिला जो ज्यादातर teams कभी monitor नहीं करतीं:

node_sockstat_UDP_inuse दसियों हज़ार तक चढ़ रहा था। एक healthy server पर ये number कुछ सौ में होता है। हमारे पर ये 20K पार कर गया।

ICMP Type 3 Code 3 (port unreachable) counters में spike आया। ये kernel बोल रहा था — "मैं इस outbound UDP packet के लिए source port allocate नहीं कर सकता।"

एक quick manual check ने confirm कर दिया:

ss -u state all | wc -l
# 28,431

cat /proc/net/sockstat
# UDP: inuse 28419

Linux पर ephemeral port range default 32768–60999 होता है — यानी लगभग 28,000 ports। हमने लगभग सब खा लिए थे।

Cascade कैसे हुआ

मैथ सीधा है। Linux के पास ephemeral ports का एक limited pool है — default में करीब 28K। हर UDP ASSOCIATE एक port खाता है। सैकड़ों concurrent associations + धीमी cleanup = pool खत्म।

जब ephemeral ports खत्म हो जाते हैं, तो server पर कुछ भी जिसे नया UDP socket खोलना है — fail हो जाता है। इसमें DNS भी शामिल है — हर outbound DNS query को एक ephemeral source port चाहिए port 53 पर request भेजने के लिए। Name resolution मर जाता है, और अचानक server पर सब कुछ टूट जाता है — ऐसे reasons से जिनका DNS से कोई लेना-देना ही नहीं।

Cascade ऐसे हुआ:

Port allocation → हर UDP ASSOCIATE bind() call करता है port 0 के साथ, kernel से अगला available ephemeral port माँगता है।

Port accumulation → port तब तक open रहता है जब तक TCP close नहीं होता या idle timeout expire नहीं होता। Generous timeouts का मतलब — ports release होने से पहले ही pile up हो जाते हैं।

Pool exhaustion → हजारों associations में हर एक के पास एक port, पूरा pool drain हो जाता है। bind() हर नए socket पर EADDRINUSE return करने लगता है।

System-wide failure → DNS queries fail होती हैं (systemd-resolved को भी ephemeral ports चाहिए)। WireGuard handshakes fail होते हैं। NTP fail होता है। Syslog-over-UDP चुपचाप मर जाता है। फिर DNS failure एक secondary cascade trigger करती है — hostname resolve करने वाली हर चीज़ रुक जाती है, health checks, database connections, monitoring agents सब। Server "down" दिखता है भले ही CPU, memory, और disk सब ठीक हों।

Standard Monitoring ने क्यों नहीं पकड़ा

HTTP health checks pass हो रहे थे — endpoint listen कर रहा था। CPU, memory, disk, throughput सब normal। Process-level metrics में कुछ unusual नहीं। SOCKS5 process healthy था। Kernel का port pool exhaust हो चुका था, और standard Grafana dashboard में ये track ही नहीं होता।

सिर्फ वो metrics काम आए जो हमने लगभग afterthought की तरह add किए थे: kernel-level socket counters और ICMP error rates।

Fix कैसे किया

दो knobs से fix हुआ। Debug करने में fix से ज्यादा वक्त लगा।

1. Idle timeouts को काफी कम किया। UDP associations का idle timeout minutes से seconds में ला दिया। अगर relay port से कुछ seconds तक कोई datagram pass नहीं होता, तो association tear down और port release। ज्यादातर legitimate UDP sessions (DNS queries, NTP) एक second से भी कम में complete हो जाते हैं। Long-lived sessions (VoIP, gaming) ongoing traffic से association alive रखते हैं, इसलिए उन पर कोई असर नहीं।

2. Per-client concurrent associations पर rate limit। एक client कितने simultaneous UDP associations hold कर सकता है — उस पर cap लगाया। इससे कोई एक user — या misbehaving client — port pool को monopolize नहीं कर सकता। Limit इतनी generous है कि legitimate use में कोई दिक्कत नहीं, लेकिन runaway accumulation रुक जाती है।

दोनों मिलाकर, UDP_inuse 28K से वापस कुछ सौ पर आ गया। नए limits के साथ UDP ASSOCIATE फिर से ship किया, और तब से stable चल रहा है।

---

Fix तो straightforward था — असली चुनौती थी ऐसा SOCKS5 UDP ASSOCIATE support बनाना जो हजारों concurrent sessions handle करे बिना system resources drain किए। अगर आपको ऐसा mobile proxy चाहिए जिसमें full UDP relay और proper lifecycle management built-in हो, तो iProxy.online असली Android devices पर 600+ carriers में चलता है — Jio, Airtel, Vi सब supported हैं। IP rotation, per-device control, और plans सिर्फ $6/month (करीब ₹500/महीना) से शुरू। Mobile proxy बनाएं →

---

आपको क्या Monitor करना चाहिए

अगर आप कुछ भी run करते हैं जो scale पर UDP sockets खोलता है — SOCKS5 proxies, game servers, VoIP infrastructure, QUIC relays — तो ये अपने monitoring stack में ज़रूर जोड़ें:

1. node_sockstat_UDP_inuse (node_exporter)। Real-time में open UDP sockets की संख्या। Normal server पर कुछ सौ होते हैं। अगर आप Prometheus use करते हैं, ये metric पहले से मौजूद है — बस panel और alert बनाना है। हम 5,000 से ऊपर जाने पर alert recommend करते हैं।
2. node_netstat_Icmp_OutDestUnreachs (ICMP Type 3 Code 3, port unreachable)। Spikes का मतलब — kernel उन UDP packets का reply दे रहा है जो ऐसे ports पर आ रहे हैं जहाँ कोई listen नहीं कर रहा। कुछ per minute normal है। हज़ारों per second — आग लगी है।
3. ss -u state all | wc -l — incident के दौरान quick sanity check।
4. cat /proc/net/sockstat — classic zero-dependency one-liner।

ये metrics ज्यादातर default dashboards में नहीं होते। होने चाहिए। Proxy infrastructure को healthy रखने के बारे में और जानने के लिए, proxy speed और stability optimize करने की हमारी गाइड देखें।

क्या सीखा

Ports एक finite resource हैं — इनका budget बनाओ। हम CPU, RAM, disk, bandwidth सबका budget बनाते हैं। Ephemeral ports का कोई budget नहीं बनाता। जब server हजारों connections handle कर रहा हो, तो ~28K ports इतने नहीं हैं। Range बढ़ा सकते हैं sysctl -w net.ipv4.ip_local_port_range="1024 65535" से, लेकिन 64K भी finite हैं जब हर association एक port indefinitely hold करे।

RFCs बताते हैं WHAT, नहीं बताते HOW। RFC 1928 साल 1996 में लिखा गया था जब "busy" server कुछ सौ connections handle करता था। Protocol mechanics बिल्कुल सही describe हैं। Port lifecycle management, resource caps, या graceful degradation के बारे में कुछ नहीं कहा। अगर आप कोई भी protocol scale पर implement कर रहे हैं, RFC पढ़ो correctness के लिए और resource management खुद design करो ऊपर से।

Kernel metrics वो पकड़ते हैं जो application metrics miss करते हैं। Health checks, Prometheus scrapers, और HTTP pings सब बोल रहे थे कि servers healthy हैं। Kernel को सच पता था। अगर आपकी monitoring में socket statistics और ICMP counters शामिल नहीं, तो resource exhaustion failures की पूरी category के लिए blind spot है। हमें एक similar observability gap Android device fleet में TLS 1.3 failures में भी मिला — अलग root cause, वही सबक।

UDP को explicit lifecycle management चाहिए। TCP में built-in lifecycle है — connections open होते हैं, data transfer होता है, defined handshake से close होते हैं। Ports TIME_WAIT के बाद reuse हो जाते हैं। UDP में ये कुछ भी नहीं है। Socket तब तक open रहता है जब तक कोई explicitly close न करे। Relay architectures में, आपको अपना lifecycle management बनाना होगा या unbounded resource consumption accept करना होगा।

किन लोगों को इससे सावधान रहना चाहिए

ये सिर्फ proxy की समस्या नहीं है। कोई भी infrastructure जो user requests के basis पर UDP sockets allocate करता है — उसे यही cliff मिल सकता है:

• TURN/STUN servers WebRTC के लिए — हर media relay एक port pair allocate करता है।
• Game servers — हर player session एक UDP port hold कर सकती है।
• QUIC load balancers — connection migration से port accumulation हो सकता है।
• DNS recursive resolvers — हर outbound query एक ephemeral port use करता है।
• VPN concentrators — WireGuard और IPsec IKE दोनों UDP पर depend करते हैं।

अगर आप इनमें से कुछ भी scale पर run कर रहे हैं — या mobile proxy farm operate कर रहे हैं — तो आज ही अपने sockstat numbers check करें। शायद आप cliff के उतने करीब हैं जितना सोचते भी नहीं।

अंतिम बात

हमने SOCKS5 UDP ASSOCIATE बिल्कुल सही implement किया — RFC-compliant, tested, deployed। और इसने एक ऐसा system-wide failure cause किया जो हमारी standard monitoring को दिखा ही नहीं।

जो सबक अब हम hard rule मानते हैं: कोई भी feature जो kernel-level resources allocate करता है — ports, file descriptors, conntrack entries — उसके लिए day one से explicit lifecycle management और resource budgeting ज़रूरी है। पहले outage के बाद fix के तौर पर नहीं।

Ports ऑक्सीजन की तरह हैं। जब तक हैं, पता नहीं चलता। जब खत्म होते हैं, सब रुक जाता है।

---

ये iProxy.online का एक real production incident है। हम mobile proxy infrastructure बनाते हैं जो Android phones को SOCKS5 और HTTP proxy servers में बदलता है — 100+ देशों और 600+ carriers में। Full UDP ASSOCIATE support — अब proper resource management के साथ। iProxy आज़माएं →