127.0.0.1:49342: लोकलहोस्ट आईपी पता, पोर्ट और डीबग गाइड

हो सकता है आपने कुछ क्लिक किया हो। हो सकता है कोई टर्मिनल विंडो खुल गई हो। हो सकता है किसी लॉग फ़ाइल पर आपकी नज़र पड़ी हो। जो भी हो, यह स्ट्रिंग सामने आई: `127.0.0.1:49342`। आपका ब्राउज़र एक ऐसे पेज पर चला गया जो इंटरनेट पर कहीं भी मौजूद नहीं है। डेवलपर टूल्स ने इसे चिह्नित कर लिया। एक लॉगिन पॉपअप पल भर के लिए खुला और गायब हो गया। कुछ भी टूटा हुआ नहीं दिखा। फिर भी कुछ गड़बड़ ज़रूर महसूस हुई।

चिंता न करें, कुछ भी खराब नहीं है। यह छोटी सी स्ट्रिंग वास्तव में उन सबसे आम चीजों में से एक है जिन्हें आप कंप्यूटर का उपयोग करते समय देखेंगे, और जैसे ही आप इसके दोनों हिस्सों को समझ जाएंगे, हर बार `127.0.0.1:` आपको एक सामान्य वाक्य की तरह लगेगा। बाईं ओर का आईपी एड्रेस यूनिवर्सल लूपबैक है, जो आपके द्वारा उपयोग किए जाने वाले हर कंप्यूटर पर समान होता है। दाईं ओर का पोर्ट एक विशिष्ट पोर्ट है जिसे ऑपरेटिंग सिस्टम ने आपके हार्डवेयर पर चल रहे प्रोग्रामों के बीच संक्षिप्त संचार के लिए किसी स्थानीय सेवा, वेब एप्लिकेशन या किसी नेटवर्क सेवा को दिया है। इसका बाहरी नेटवर्क से कोई संबंध नहीं है। यह सब आपके सामने मौजूद कंप्यूटर पर ही रहता है।

तो ये है योजना। एक व्याख्यात्मक लेख और एक समस्या निवारण मार्गदर्शिका, दोनों एक साथ। पता कहाँ से आया है, ऐतिहासिक रूप से। पोर्ट नंबर वास्तव में क्या दर्शाता है। 49342, विशेष रूप से, कोई खास बात क्यों नहीं है। विंडोज उपयोगकर्ता इसे देखकर लिनक्स या मैकओएस उपयोगकर्ता से कैसे अलग महसूस करेंगे। 2026 में सुरक्षा की स्थिति कैसी होगी। क्रिप्टो डेवलपर हार्डहैट, एनविल, गनाश और बिटकॉइन कोर के साथ वेब3 विकास वातावरण में समान पैटर्न का उपयोग कैसे करते हैं। इसे शुरू से अंत तक पढ़ें, या सीधे उस अनुभाग पर जाएँ जो आपकी खोज से मेल खाता हो।

127.0.0.1 क्या है: लूपबैक एड्रेस की व्याख्या

पहले आईपी एड्रेस की बात करते हैं। 127.0.0.1 आजकल ऑनलाइन इस्तेमाल होने वाले अधिकांश आईपी एड्रेस से पुराना है। अक्टूबर 1989 में, जब व्यावसायिक वेब का कोई अस्तित्व ही नहीं था, तब IETF ने RFC 1122 जारी किया था। इसके सेक्शन 3.2.1.3 में नेटवर्किंग से जुड़ा एक बेहद स्पष्ट नियम लिखा था: "इस प्रकार के एड्रेस किसी होस्ट के बाहर नहीं होने चाहिए।" आज भी आपके फोन का ऑपरेटिंग सिस्टम इसे लागू करता है। आपका होम राउटर भी। तब से जारी किए गए हर ऑपरेटिंग सिस्टम ने चुपचाप इस नियम का पालन किया है।

बड़े पैमाने पर काम करना लोगों को उलझन में डाल देता है। यह नियम 16,777,216 पतों पर लागू होता है। सभी पर। सोलह मिलियन पते आरक्षित रखे गए हैं ताकि उनमें से एक, 127.0.0.1, पृथ्वी पर कहीं भी "यह मशीन, यहीं" का विश्वसनीय अर्थ दे सके। क्या यह कुछ ज्यादा ही फिजूलखर्ची है? हाँ, दशकों से इसकी शिकायतें होती आ रही हैं। IANA का वैश्विक IPv4 पूल 3 फरवरी, 2011 को शून्य हो गया। ARIN 24 सितंबर, 2015 को शून्य हो गया। RIPE NCC ने 25 नवंबर, 2019 को अपना अंतिम /22 ब्लॉक जारी किया। IETF का एक मसौदा, जिसका नाम `draft-schoen-intarea-unicast-127` है, चर्चा में है जिसमें सुझाव दिया गया है कि 127 पोर्ट का अधिकांश हिस्सा वास्तव में यूनिकास्ट उपयोग में वापस जा सकता है। लेकिन कोई भी इसे छूना नहीं चाहता। मौजूदा सॉफ्टवेयर का एक बड़ा हिस्सा यह मानकर चलता है कि 127 कभी नहीं बदलेगा।

एक चौंकाने वाली बात जो नए उपयोगकर्ताओं को हमेशा हैरान करती है: पैकेट असल में कभी भी फिजिकल नेटवर्क कार्ड तक नहीं पहुंचता। बिल्कुल भी नहीं। किसी भी 127.xxx डेस्टिनेशन पर भेजा गया पैकेट ऑपरेटिंग सिस्टम के TCP/IP स्टैक द्वारा लेयर 3 पर पकड़ा जाता है और एक वर्चुअल इंटरफेस (Linux और macOS इसे 'lo' कहते हैं) के माध्यम से आगे भेज दिया जाता है। कर्नेल अभी भी असली काम करता है - TCP सेगमेंट बनाता है, चेकसम चलाता है, रिसीव पाथ की जांच करता है। इसमें वास्तविक ओवरहेड होता है, जो शून्य नहीं होता। लेकिन आपके LAN पर कोई भी स्विच उस ट्रैफिक को नहीं देखता। कोई राउटर उसे नहीं देखता। कोई इंटरनेट बैकबोन उसे नहीं देखता।

"localhost" शब्द एक सरल नाम है जिसे एक साधारण टेक्स्ट फ़ाइल में मैप किया गया है जिसे आप अभी खोल सकते हैं। Linux और macOS पर: `/etc/hosts`। Windows पर: `C:\Windows\System32\drivers\etc\hosts`। DNS सर्वर से अनुरोध करने से पहले रिजॉल्वर इस फ़ाइल को एक्सेस करता है, यही कारण है कि हवाई जहाज में वाईफाई बंद होने पर भी `localhost` सही ढंग से रिजॉल्व हो जाता है। IPv6 अपना एक अलग संस्करण, `::1/128` लेकर आता है, जिसे फरवरी 2006 में RFC 4291 द्वारा परिभाषित किया गया था। एक आम समस्या जो अक्सर सामने आती है: एक आधुनिक ब्राउज़र `localhost` को पहले `::1` के रूप में रिजॉल्व करता है, लेकिन Python ऐप केवल 127.0.0.1 से जुड़ा होता है। अलग-अलग सॉकेट, कोई इंटरसेक्शन नहीं, और चुपचाप विफलता। यह समस्या हर हफ्ते कहीं न कहीं किसी न किसी के काम में बाधा डालती है।

आपको पोर्ट 49342 क्यों दिखाई देता है: अस्थायी बंदरगाह और IANA रेंज

अब दूसरे भाग की बात करते हैं। पोर्ट नंबर, आईपी नंबरों से भी ज़्यादा लोगों को भ्रमित करते हैं, और इसका एक ठोस कारण है। IANA सेवा-नाम और परिवहन-प्रोटोकॉल पोर्ट रजिस्ट्री, पूरे 16-बिट स्पेस (0 से 65535 तक) को तीन श्रेणियों में विभाजित करती है, और पोर्ट नंबर 49342 किस श्रेणी में आता है, यही पूरी कहानी है।

पोर्ट 49342 डायनामिक रेंज के अंतर्गत आता है। इस पर कुछ भी "पंजीकृत" नहीं है, और न ही कभी होगा, क्योंकि IANA इस रेंज में सेवाओं को आवंटित करने से इनकार करता है ताकि ऑपरेटिंग सिस्टम अस्थायी उपयोग के लिए यहां पोर्ट नंबर स्वतंत्र रूप से दे सकें। एक अस्थायी पोर्ट एक ऐसा पोर्ट होता है जिसे एप्लिकेशन ने किसी विशिष्ट पोर्ट नंबर द्वारा अनुरोध किए बिना गतिशील रूप से आवंटित किया है। इसने OS से कहा, "मुझे कोई भी खाली पोर्ट दे दो, मुझे बस इस सत्र के लिए इसकी आवश्यकता है।" OS ने 49342 लौटाया, एप्लिकेशन ने एक लिसनिंग सॉकेट स्थापित किया, और जिस भी फ्लो को अल्पकालिक पते और पोर्ट संयोजन की आवश्यकता थी, उसे वह मिल गया। पोर्ट 49342 का उपयोग अक्सर इस प्रकार के एड-हॉक बाइंडिंग का उपयोग करके अस्थायी स्थानीय सर्वर के लिए किया जाता है।

डिफ़ॉल्ट अल्पकालिक सीमा वास्तव में ऑपरेटिंग सिस्टम के अनुसार भिन्न होती है।

विंडोज़ या मैकओएस पर, 49342 डिफ़ॉल्ट रेंज के बिल्कुल अंदर आता है। यह पोर्ट लगभग निश्चित रूप से ऑपरेटिंग सिस्टम के एलोकेटर द्वारा दिया गया होगा। लिनक्स पर मामला अलग है - 49342 डिफ़ॉल्ट 32768 से 60999 रेंज से ऊपर है, इसलिए इसे किसी ऐसे ऐप ने चुना होगा जिसने कर्नेल से `bind(('127.0.0.1', 0))` कमांड का अनुरोध किया और जो भी पोर्ट उपलब्ध था, उसे प्राप्त कर लिया। जनवरी 2011 में IETF द्वारा जारी RFC 6056 सुरक्षा कारणों से स्टैक को 1024 से 65535 तक की पूरी रेंज में अस्थायी पोर्ट चयन को रैंडम करने का निर्देश देता है। अनुमानित पोर्ट होने से फ्लो को हाईजैक करना आसान हो जाता है। यही कारण है कि एक ही डेवलपर सर्वर आज 49342 पोर्ट पर, कल 54871 पर और परसों 33200 पोर्ट पर पहुँच सकता है।

जहां 127.0.0.1:49342 आपके कंप्यूटर पर दिखाई देता है

तो सामान्य दिनों में यह समस्या कब सामने आती है? पोर्ट 49342 पर चलने वाला एक लोकल सर्वर डेवलपर्स के लिए कई तरह के टूल में से किसी भी श्रेणी का हो सकता है, जहां डेवलपर्स लोकल लूपबैक सॉकेट के माध्यम से एप्लिकेशन का परीक्षण करते हैं। नीचे दी गई तालिका में उन सामान्य मामलों को दर्शाया गया है जहां पोर्ट 49342 जैसे पोर्ट उपयोग में आते हैं, और सेवाएं चल रही होती हैं और हर बार निर्दिष्ट पोर्ट पर कनेक्शन स्वीकार करती हैं।

ऐसा कौन सा मामला है जिसमें ब्राउज़र के एड्रेस बार में सीधे `127.0.0.1:49342` दिखाई देता है? लगभग हमेशा OAuth ही इसका कारण होता है। IETF का RFC 8252, जिसका शीर्षक "OAuth 2.0 for Native Apps" है, अक्टूबर 2017 में जारी हुआ था और इसमें नेटिव ऐप्स को लूपबैक रीडायरेक्ट फ्लो का उपयोग करने के लिए कहा गया है, जिसमें एक नियम पक्का है: ऑथराइजेशन सर्वर को "किसी भी पोर्ट नंबर की अनुमति देनी होगी"। `gh auth login` या `gcloud auth login` कमांड चलाएँ। CLI एक छोटे HTTP सर्वर को एक रैंडम अस्थायी पोर्ट पर शुरू करता है, आइडेंटिटी प्रोवाइडर पर एक ब्राउज़र खोलता है, उस लूपबैक एड्रेस पर कॉलबैक को पकड़ता है और खुद को बंद कर देता है। आपको 127.0.0.1:49342 जैसे लोकलहोस्ट एड्रेस दो सेकंड के लिए दिखाई देते हैं और फिर गायब हो जाते हैं। यह कोई बग नहीं है। न ही कोई ट्रैकर है। न ही कोई घोटाला है। यह सिर्फ एक बहुत छोटा हैंडशेक है, पूरी तरह से लोकल, जो किसी भी समय बाहरी नेटवर्क तक नहीं पहुँचता।

127.0.0.1:49342 त्रुटियों और पोर्ट विवादों का निवारण

मेरे अनुभव में, लोकलहोस्ट से जुड़ी परेशानियां पांच तरह की होती हैं। रात 11 बजे आपको कुछ भी खोजने के लिए मजबूर करने वाली कोई भी चीज किसी न किसी तरह इनमें से किसी एक श्रेणी में आती है।

पोर्ट पहले से ही उपयोग में है। नोड `EADDRINUSE` त्रुटि दिखाता है। पायथन आपको `OSError: [Errno 98] Address already in use` त्रुटि देता है, जो देखने में भद्दी लगती है। विंडोज़ बस `WinSock 10048` दिखाता है और चला जाता है। हर मामले में मूल वास्तविकता एक ही है: आपके कंप्यूटर पर किसी अन्य प्रक्रिया ने पहले ही पोर्ट 49342 का उपयोग कर लिया है। आपका काम है उसे ढूंढना, उसे बंद करना और पोर्ट को पुनः प्राप्त करना।

• Linux पर: `ss -tulpn | grep :49342`, या फिर पुराने तरीके से `sudo lsof -i :49342` कमांड का इस्तेमाल करें।
• मैक पर: `lsof -nP -iTCP:49342 -sTCP:LISTEN`
• विंडोज में पॉवरशेल में: `netstat -ano | findstr :49342` कमांड चलाएं, फिर उस PID को प्रोग्राम नाम में बदलने के लिए `tasklist /fi "PID eq "` कमांड चलाएं।

सर्वर चल रहा है, लेकिन कोई कनेक्शन नहीं हो पा रहा है। आपको शायद इससे ज़्यादा परेशानी हो रही है। IPv4 और IPv6 के बीच कुछ गड़बड़ हो गई है। आपका सर्वर 127.0.0.1 पोर्ट से जुड़ गया है। आपका ब्राउज़र बिना किसी कारण के `localhost` को `::1` के रूप में रिजॉल्व कर रहा है। ये दो अलग-अलग सॉकेट हैं, इसलिए ज़ाहिर है कि कोई कनेक्शन नहीं हो पा रहा है। इसे ठीक करने के लिए, दोनों पोर्ट को एक साथ जोड़ें (ज़्यादातर स्टैक पर `::` पर सुनने से IPv4-मैप्ड एड्रेस भी मिल जाते हैं) या सीधे URL में 127.0.0.1 लिखें।

VPN लूपबैक ट्रैफ़िक को बाधित कर रहे हैं। Cloudflare WARP इस मामले में सबसे आगे है। Cloudflare ने खुद अपनी ज्ञात सीमाओं वाले दस्तावेज़ पृष्ठ पर यह स्वीकार किया है: विशेष रूप से macOS पर, WARP को डिस्कनेक्ट करने से 127.0.0.1 रूट पूरी तरह से डिलीट हो सकता है। यदि VPN चालू/बंद करने के तुरंत बाद आपका लोकलहोस्ट काम करना बंद कर देता है, तो लगभग निश्चित रूप से यही कारण है। WARP को फिर से कनेक्ट करें, या `sudo ifconfig lo0 127.0.0.1 alias` कमांड का उपयोग करके रूट को मैन्युअल रूप से वापस लाएं। Proton VPN, Mullvad और NordVPN आमतौर पर ऐसा नहीं करते हैं। एंटरप्राइज़ एंटीवायरस और EDR उत्पाद एक अलग मामला हैं; उनमें से कुछ लूपबैक ट्रैफ़िक को इस तरह से इंटरसेप्ट और प्रॉक्सी करते हैं जो बहुत जल्दी अजीब हो जाता है।

HSTS उन HTTPS टेस्ट को याद रख रहा है जिन्हें आप भूल गए थे। कुछ महीने पहले, आपने `localhost` पर एक सेल्फ-साइन किए गए सर्टिफ़िकेट का परीक्षण किया था। Chrome ने अपनी आदत के अनुसार HSTS हेडर को कैश कर लिया। अब हर सामान्य `http://localhost` अनुरोध चुपचाप HTTPS में बदल जाता है। इसे डीबग करना बहुत मुश्किल है। दो मिनट का समाधान: `chrome://net-internals/#hsts` खोलें और उस एंट्री को हटा दें।

फ़ायरवॉल नियम। लूपबैक डिफ़ॉल्ट रूप से अधिकांश फ़ायरवॉल से होकर गुजरता है। कुछ एंटरप्राइज़ लैपटॉप इमेज मैलवेयर से बचाव के लिए जानबूझकर लोकलहोस्ट को फ़िल्टर करती हैं, और आपको इसका पता गुरुवार के अंत में चलता है। विंडोज डिफेंडर फ़ायरवॉल के उन्नत इनबाउंड नियमों की जाँच करें। लिनक्स पर, `sudo ufw status verbose` कमांड चलाएँ। यदि वास्तव में कुछ खोलने की आवश्यकता है, तो केवल संबंधित पोर्ट को ही अनुमति दें; पूरे फ़ायरवॉल को नष्ट न करें।

एक आदत है जो मुझे हर बार बचा लेती है। किसी भी फ़ायरवॉल नियम या रूट को छूने से पहले, `lsof` या `netstat` चलाएँ। आधे मामलों में, यह एक ज़ॉम्बी प्रोसेस होता है जो किसी डेवलपर रन के क्रैश होने के बाद से पोर्ट को ज़िद से पकड़े रहता है। PID को `kill -9` कमांड से मारें। समस्या कुछ ही सेकंड में हल हो जाती है।

डेवलपर उपयोग के लिए लोकलहोस्ट और सर्वर कॉन्फ़िगरेशन सेट अप करना

डिबगिंग की बजाय बिल्डिंग पर ध्यान दे रहे हैं? सर्वर कॉन्फ़िगरेशन की कुछ बुनियादी बातें सीख लें और आप कई दोपहरें बचा लेंगे। इसमें कुछ भी जटिल नहीं है। हमारा लक्ष्य बस इतना है: एक ही लैपटॉप पर कई नेटवर्क सेवाओं और विभिन्न सेवाओं का विश्वसनीय परीक्षण और डिबगिंग करना, बस इतना ही।

पहला नियम, जो थोड़ा उबाऊ है: `127.0.0.1` से बाइंड करें, न कि `0.0.0.0` से। `0.0.0.0` पर लिसन करने से आपका छोटा सा वेब सर्वर अचानक आपके स्वामित्व वाले हर नेटवर्क इंटरफ़ेस पर खुद को विज्ञापित करने लगेगा। मतलब: कैफे के वाईफाई पर बगल वाली टेबल पर बैठा कोई भी व्यक्ति इसे ढूंढ लेगा। `127.0.0.1` से बाइंड करने पर केवल वही चीज़ें एक्सेस होंगी जो पहले से आपके कंप्यूटर पर मौजूद हैं। Python का `http.server`, Node का `express.listen()`, Go का `http.ListenAndServe` — ये सभी सीधे IP एड्रेस को स्वीकार करते हैं। बस इसे टाइप करें।

नियम दो: जब आपको वास्तव में पोर्ट की परवाह न हो, तो पोर्ट न चुनें। लिसनर को पोर्ट 0 पास करें (नोड पर `server.listen(0)`, पायथन पर `bind(('127.0.0.1', 0))`) और कर्नेल उस मिलीसेकंड में जो भी पोर्ट खाली होगा उसे वापस भेज देगा। इसके बाद `getsockname()` को कॉल करके पता करें कि आपको वास्तव में क्या मिला है और उसे उस कंपोनेंट को दें जिसे URL चाहिए। मूल रूप से, हर OAuth CLI और हर डीबग एडॉप्टर जो आपने कभी इस्तेमाल किया है, ठीक यही करता है।

नियम तीन: एनवायरनमेंट वैरिएबल का इस्तेमाल करें, हार्डकोडेड पोर्ट का नहीं। `PORT` को env से लें और अगर यह मौजूद नहीं है, तो इसे किसी उपयुक्त मान पर सेट करें। एक ही बाइनरी dev पोर्ट पर 127.0.0.1:5173 और प्रोडक्शन पोर्ट पर रिवर्स प्रॉक्सी के पीछे 443 पोर्ट पर चलती है। डेटाबेस स्ट्रिंग्स, API कीज़ और बाकी सभी के लिए भी यही तरीका अपनाएं। ट्वेल्व-फैक्टर ऐप का डॉक्यूमेंटेशन आपके कुछ सहकर्मियों से भी पुराना है, लेकिन फिर भी यह आउटेज से बचने का सबसे सस्ता तरीका है।

नियम चार: लोकलहोस्ट पर HTTPS अब कोई परेशानी नहीं है। Chrome और Firefox दोनों ही अब अधिकांश सुविधाओं के लिए `localhost` और `127.0.0.1` को सुरक्षित संदर्भ (Secure Context) का दर्जा देते हैं, भले ही आपके पास कोई वास्तविक प्रमाणपत्र न हो। क्या कोई लाइब्रेरी अभी भी स्व-हस्ताक्षरित प्रमाणपत्र स्वीकार नहीं कर रही है? `mkcert` का उपयोग करें, जो अभी भी सबसे कम परेशानी वाला स्थानीय CA है। Python के `http.server` और Node के `net` मॉड्यूल जैसे अंतर्निहित टूल की मदद से आप स्थानीय विकास के दौरान लगभग पाँच पंक्तियों में एक स्थानीय सर्वर स्थापित कर सकते हैं, जिससे डेवलपर्स वास्तविक लोड के तहत वेब एप्लिकेशन का परीक्षण कर सकते हैं। इसके लिए उन्हें एकीकरण परीक्षणों के लिए उन्हीं स्क्रिप्ट का उपयोग करना होता है जहाँ लूपबैक के माध्यम से संचार करने के लिए सेवाओं की आवश्यकता होती है।

आखिरी नियम, और वास्तव में सबसे महत्वपूर्ण नियम। प्रोडक्शन लोकल नहीं होता। बस। आपकी लोकल मशीन एक ट्रस्ट बाउंड्री है; प्रोडक्शन कंटेनर नहीं। प्रोडक्शन कंटेनर के अंदर 127.0.0.1 पोर्ट पर चलने वाले डिबग एंडपॉइंट्स को कभी भी खुला न छोड़ें, क्योंकि उसी कंटेनर में मौजूद अन्य प्रोसेस पहले दिन से ही उन तक पहुंच जाते हैं, और रनटाइम में किसी बग के कारण हमलावर भी आसानी से अंदर घुस सकता है। लोकलहोस्ट ट्रैफिक का इस्तेमाल केवल वहीं करें जहां इसकी जरूरत है, यानी डेवलपमेंट एनवायरनमेंट में, और कहीं नहीं। और जिस दिन पोर्ट का इस्तेमाल करने वाला कोई भी इंटरनल API शेयर्ड एनवायरनमेंट या प्रोडक्शन एनवायरनमेंट में अपग्रेड हो, तुरंत उसके सामने असली ऑथेंटिकेशन लागू करें। "हम इसे लॉन्च के बाद ठीक कर देंगे" जैसी बातें न करें। यह पिछली कंपनी की सोच थी।

पोर्ट 49342 का सुरक्षित उपयोग: लूपबैक पते पर सुरक्षा

लोकलहोस्ट में गोपनीयता का एहसास होता है। और ज्यादातर मामलों में यह होता भी है। जब तक कि अचानक ऐसा होना बंद न हो जाए।

यहाँ एक ऐसी समस्या है जिसका सामना हर किसी को अंततः करना पड़ता है। बाहरी हमलावर सीधे 127.0.0.1 पर डायल नहीं कर सकते, यह तो निश्चित है। लेकिन वे आपके ब्राउज़र या आपके कंप्यूटर पर मौजूद किसी भरोसेमंद ऐप को धोखा देकर अपनी ओर से कॉल करवा सकते हैं। इस तरह के हमले को DNS रीबाइंडिंग कहा जाता है। यह लोकलहोस्ट सेवाओं को तब से प्रभावित कर रहा है जब से इस लेख को पढ़ने वाले अधिकांश लोग कोड लिखना भी नहीं सीखे थे।

क्रिप्टो जगत के लोग आज भी जिस उदाहरण का हवाला देते हैं, वह है 24 अप्रैल, 2018 को MyEtherWallet पर हुई घटना। हमलावरों ने Amazon के Route 53 पर BGP हाइजैक किया, myetherwallet.com के DNS को रीडायरेक्ट किया और एक फ़िशिंग क्लोन चलाया जो कुछ ही समय के लिए लाइव रहा और उससे लगभग 215 ETH (लगभग $152,000 से $160,000, यह इस बात पर निर्भर करता है कि आप किस समय को चुनते हैं, जैसा कि The Register और Internet Society की रिपोर्ट में बताया गया है) निकाल लिए गए। मुझे पता है, यह पूरी तरह से लोकलहोस्ट हैक नहीं था। लेकिन यह वह मोड़ था जब क्रिप्टो समुदाय ने ब्राउज़र के ओरिजिन मॉडल को एक वास्तविक सुरक्षा कवच मानना बंद कर दिया। लूपबैक पोर्ट पर चुपचाप सुन रहे हर लोकल वॉलेट ब्रिज को अचानक असुरक्षित महसूस होने लगा।

Chrome का समाधान प्राइवेट नेटवर्क एक्सेस के रूप में आया, जिसे मूल रूप से ड्राफ्ट में CORS-RFC1918 कहा गया था। मार्च 2024 से, ब्राउज़र अब किसी भी सार्वजनिक वेबसाइट को निजी या लूपबैक पते तक पहुँचने की अनुमति देने से पहले `Access-Control-Request-Private-Network: true` युक्त CORS प्रीफ़्लाइट भेजता है। पास होने के लिए आपकी स्थानीय सेवा को `Access-Control-Allow-Private-Network: true` के साथ जवाब देना होगा। Chrome के रिलीज़ 123 से 130 तक पूर्ण प्रवर्तन लागू हो गया है। इसलिए, यदि आप एकीकरण परीक्षणों के दौरान किसी सार्वजनिक पृष्ठ के आने की उम्मीद में 127.0.0.1:49342 पर एक विकास सर्वर स्थापित करते हैं, तो उस हेडर को सेट करें। अन्यथा अनुरोध चुपचाप अस्वीकार कर दिया जाएगा।

2025 के कुछ Electron CVEs का ज़िक्र करना ज़रूरी है। CVE-2025-10585 एक V8 टाइप-कन्फ्यूजन बग है, जिसे 23 सितंबर, 2025 को CISA की ज्ञात कमजोरियों की सूची में जोड़ा गया था। CVE-2025-55305 एक कोड-इंटीग्रिटी बाईपास है जो V8 हीप स्नैपशॉट में छेड़छाड़ करता है, और लगभग उसी समय इसका खुलासा हुआ था। Electron, Chromium पर आधारित है, और आपके लैपटॉप में Electron के कई ऐप्स इंस्टॉल हैं (Slack, VS Code, Discord, Notion, Teams, और शायद और भी)। इनमें से कई ऐप्स लूपबैक पर लोकल सर्विसेज़ को एक्सपोज़ करते हैं। इन्हें जल्द से जल्द पैच करें। और कृपया, 127.0.0.1 पर बिना ऑथ टोकन के कभी भी RPC एंडपॉइंट स्थापित न करें, अगर वह एंडपॉइंट कीज़ पढ़ सकता है, ट्रांजैक्शन साइन कर सकता है, या किसी भी तरह के पैसे को छू सकता है।

हार्डहैट, एनविल और गनाश में क्रिप्टो डेवलपर्स लोकलहोस्ट का उपयोग कैसे करते हैं

वेब3 डेवलपमेंट मूल रूप से 127.0.0.1 नेटवर्क एड्रेस रेफरेंस की एक अंतहीन श्रृंखला है - चाहे आपका ध्यान कॉन्ट्रैक्ट डिप्लॉयमेंट, प्रोटोकॉल फ़ज़िंग, या स्थानीय नेटवर्क पर रोज़मर्रा के वेब डेवलपमेंट पर हो। आपके लैपटॉप पर अभी लोकलहोस्ट पर स्थानीय नोड्स का एक छोटा क्लस्टर चल रहा है (भले ही आप उनमें से आधे के बारे में भूल गए हों)। प्रत्येक नोड का अपना सर्वर ऑन पोर्ट नियम है। प्रत्येक नोड क्लाइंट्स को डायल करने के लिए एक विशिष्ट आईपी एड्रेस और पोर्ट संयोजन प्रदान करता है, आमतौर पर उस विशिष्ट पोर्ट का उपयोग करके जिसे टूल ने डिफ़ॉल्ट रूप से सेट किया है।

संक्षिप्त जानकारी। नॉमिक फाउंडेशन का हार्डहैट नेटवर्क डिफ़ॉल्ट रूप से `http://127.0.0.1:8545` और चेन आईडी 31337 का चयन करता है। फाउंड्री का एनविल भी इसी पते और पोर्ट का उपयोग करता है, जिसे `--port` कमांड के माध्यम से कॉन्फ़िगर किया जा सकता है, खासकर तब जब आपके पास दो टेस्ट सूट खुले हों और उनमें समस्या आ रही हो। गनाश जीयूआई `127.0.0.1:7545` और नेटवर्क आईडी 5777 का उपयोग करता है, हालांकि इसका सीएलआई संस्करण हार्डहैट के 8545 पोर्ट का उपयोग करता है। वहीं, बिटकॉइन कोर का रेगटेस्ट मोड `127.0.0.1:18443` पोर्ट पर अपना JSON-RPC चलाता है - यह बदलाव वास्तव में v0.16 में पुल रिक्वेस्ट #10825 के माध्यम से किया गया था, जब किसी ने टेस्टनेट के 18332 पोर्ट के साथ समस्या की ओर ध्यान दिलाया था।

MetaMask इनमें से किसी से भी कनेक्ट हो सकता है। लोकल RPC URL के साथ एक कस्टम नेटवर्क जोड़ें और आप कनेक्ट हो जाएंगे। IP 127.0.0.1 आपके ब्राउज़र-आधारित वॉलेट UI और उस समय आपके लैपटॉप पर चल रहे किसी भी सिम्युलेटेड ब्लॉकचेन के बीच एक पतले पुल का काम करता है। जब आप Web3 स्टैक ट्रेस में `127.0.0.1:` देखते हैं, तो यह लगभग हमेशा दो चीजों में से एक होता है: या तो आपके IDE का डिबग एडैप्टर नोड को एक्सेस कर रहा है, या नोड खुद अपने फिक्स्ड RPC के ठीक बगल में किसी रैंडम पोर्ट पर एक WebSocket एंडपॉइंट शुरू कर रहा है।

भुगतान एकीकरण भी इसी पैटर्न को दोहराते हैं। क्या आप प्लिसियो-आधारित क्रिप्टो चेकआउट बना रहे हैं? आप `127.0.0.1:3000/plisio/callback` पोर्ट पर एक छोटे से फ्लास्क या एक्सप्रेस लिसनर के साथ स्थानीय रूप से SDK चलाते हैं। गेटवे का वेबहुक सार्वजनिक इंटरनेट से सीधे आपके लैपटॉप तक नहीं पहुंच सकता, इसलिए स्थानीय परीक्षण के लिए पोर्ट को उजागर करने के लिए एक टनल (ngrok, Cloudflare Tunnel, Tailscale Funnel) का उपयोग किया जाता है। यह एक विशिष्ट पोर्ट नंबर पर एक विशिष्ट पोर्ट होता है जिसे आप, व्यापारी, चुनते और नियंत्रित करते हैं। प्लिसियो के PHP, Python, Laravel और Node.js SDK में `verifyCallbackData` हेल्पर होता है जो दुकान की गुप्त कुंजी के विरुद्ध पेलोड का HMAC-SHA1 पुनः गणना करता है। यह जांच प्रत्येक कॉलबैक के लिए तब चलती है जब वह स्थानीय लिसनर पर पहुंचता है। लूपबैक पता समान होता है, कार्य समान होता है, और वास्तविक हस्ताक्षर संलग्न होते हैं।

एक पल के लिए ज़ूम आउट करें। यह पैटर्न वास्तव में हर जगह मौजूद है: भुगतान, OAuth, विकास में उपयोग की जाने वाली Web3 नेटवर्क सेवाएं, ये सभी अंदर से एक जैसी दिखती हैं - पोर्ट 49342 या किसी अन्य डायनामिक पोर्ट पर एक सर्वर, निर्दिष्ट पोर्ट पर वास्तविक कनेक्शन, और हर समय लोकलहोस्ट पर चल रहा होता है।

किसी भी ऑपरेटिंग सिस्टम के लिए त्वरित लोकलहोस्ट और पोर्ट जांच

एक संक्षिप्त गाइड। इसे टर्मिनल टैब में खुला रखें। आपको इसकी ज़रूरत उम्मीद से कहीं ज़्यादा पड़ेगी।

किसी भी Linux डिस्ट्रीब्यूशन की कल्पना कीजिए। `sudo ss -tulpn | grep :49342` कमांड से पता चल जाता है कि 49342 पोर्ट पर कौन है। अगर आप grep कमांड हटा देते हैं, तो आपको मशीन के सभी खुले हुए सॉकेट मिल जाएंगे। क्या आप कर्नेल की डायनामिक पोर्ट लिमिट के बारे में जानना चाहते हैं? `cat /proc/sys/net/ipv4/ip_local_port_range` कमांड चलाएं। अगर आप सिर्फ यह देखना चाहते हैं कि लूपबैक पोर्ट सही से काम कर रहा है या नहीं, तो `ip addr show lo` कमांड चलाएं। और हां—अगर आउटपुट से `lo` गायब हो जाता है, तो समझ लीजिए कि आपको पोर्ट से कहीं बड़ी समस्या मिल गई है।

Mac भी इसी तरह काम करता है, बस BSD सिस्टम होने के कारण इसमें अलग टूलिंग का इस्तेमाल होता है। `lsof -nP -iTCP:49342 -sTCP:LISTEN` पोर्ट पर मौजूद प्रोसेस को दिखाता है। कॉलन और नंबर हटाकर आप सभी लिसनर्स की सूची देख सकते हैं। दूसरे यूजर्स के सॉकेट्स को देखने के लिए `sudo` प्रीफिक्स का इस्तेमाल करें। अस्थायी रेंज `sysctl net.inet.ip.portrange.first net.inet.ip.portrange.hifirst` में मिलती है। लूपबैक को यहां `lo0` कहा जाता है (न कि `lo`), और नामकरण की यह छोटी सी गलती लोगों को सिर्फ एक बार ही परेशान करती है, उसके बाद वे इसे हमेशा के लिए समझ लेते हैं। `ifconfig lo0` से इसकी जांच करें।

विंडोज़ पूरी तरह से डायलेक्ट बदल देता है। एडमिन के रूप में पॉवरशेल खोलें। `netstat -ano | findstr :49342` कमांड से एक PID प्राप्त होता है। इस PID को `tasklist /fi "PID eq "` कमांड में डालें ताकि यह संख्या ऐप के नाम में परिवर्तित हो जाए। डायनामिक रेंज के लिए, `netsh int ipv4 show dynamicport tcp` कमांड का उपयोग करें। क्या किसी पुराने ऐप को कम PID की आवश्यकता है? इसके लिए `netsh int ipv4 set dynamic tcp start=49152 num=16384` कमांड का उपयोग करें।

इन चीजों को अच्छी तरह से समझ लें और लोकलहोस्ट से जुड़ी आपकी परेशानियां पांच मिनट में, शायद उससे भी कम समय में हल हो जाएंगी। कभी यह करके देखें: अपने लैपटॉप पर `lsof -nP -iTCP -sTCP:LISTEN | grep 127.0.0.1` कमांड चलाएं। स्क्रॉलिंग लिस्ट हमेशा आपकी उम्मीद से लंबी होती है। ब्राउज़र के बैकग्राउंड टैब। कुछ एडिटर लैंग्वेज सर्वर, अक्सर एक से ज़्यादा। डॉकर का इंटरनल DNS। स्लैक, डिस्कॉर्ड, लीनियर, या आपके द्वारा चलाए जा रहे किसी भी अन्य ब्राउज़र के इलेक्ट्रॉन IPC ब्रिज। कोई OS टेलीमेट्री डेमन जिसके बारे में आपको पता ही नहीं था। साथ ही आज सुबह के वे छह या सात डेवलपमेंट सर्वर जिन्हें आप बंद करना ज़रूर भूल गए थे। यह शोरगुल सामान्य है। एक कार्यशील डेवलपमेंट वातावरण की अंदरूनी आवाज़ें ऐसी ही होती हैं।

Simon Chartan

A journalist with a strong technical background and a passion for decentralized finance. With degrees in MBA and Master of Engineering in Data Science, the author combines analytical expertise with a clear, engaging writing style. At Plisio, they cover topics such as cryptocurrency, blockchain, DeFi, and digital finance—helping readers make sense of a rapidly evolving fintech landscape.