127.0.0.1:57573 लोकलहोस्ट पोर्ट गाइड और समस्या निवारण

एक छोटा सा फ्लास्क स्क्रिप्ट चलाएँ। ब्राउज़र में `http://127.0.0.1:57573` पेस्ट करें। दो परिणाम हो सकते हैं: या तो पेज लोड हो जाएगा, या टर्मिनल लाल रंग से `ECONNREFUSED` संदेश के साथ जल उठेगा और ब्राउज़र में डिस्कनेक्टेड प्लग का आइकन दिखाई देगा।

दोनों ही परिणाम रहस्यमय नहीं हैं। एड्रेस के दो हिस्से हैं: 127.0.0.1 IPv4 लूपबैक है, और 57573 एक पोर्ट है जिसे ऑपरेटिंग सिस्टम ने अपने हाई-पोर्ट पूल से लगभग बेतरतीब ढंग से चुन लिया है। यह गाइड इन दोनों हिस्सों को विस्तार से समझाएगी। हम देखेंगे कि इतने सारे लोकल सर्वर इस तरह के पोर्ट पर क्यों पहुँच जाते हैं, और कनेक्शन खुलने से पहले होने वाली लगभग आधा दर्जन समस्याओं के बारे में जानेंगे। अंत तक, आपको पता चल जाएगा कि किसी सेवा को सही इंटरफ़ेस से कैसे जोड़ा जाए, यह कैसे देखा जाए कि वास्तव में कौन सा सर्वर किसी पोर्ट पर चल रहा है, पोर्ट संबंधी समस्याओं और फ़ायरवॉल ब्लॉकों को कैसे ठीक किया जाए, और लोकल सर्वर को सार्वजनिक इंटरनेट से जोड़ने से पहले उसे कैसे सुरक्षित किया जाए।

सरल शब्दों में 127.0.0.1:57573 का अर्थ क्या है?

तीन भाग। आईपी पता 127.0.0.1 आईपीवी4 लूपबैक है। कॉलन का अर्थ है "और इस पोर्ट पर"। 57573 स्वयं पोर्ट है, जो उच्च संख्या वाली श्रेणी में आता है जिस पर किसी भी व्यापक रूप से उपयोग की जाने वाली सेवा का स्थायी स्वामित्व नहीं होता है।

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

यह रिज़र्वेशन इसका इस्तेमाल करने वाले ज़्यादातर डेवलपर्स से भी पुराना है। RFC 1122, सेक्शन 3.2.1.3 के अनुसार, 1989 में ही पूरे 127.0.0.0/8 ब्लॉक, यानी सभी 16,777,216 एड्रेस, को नेटवर्क से हमेशा के लिए हटा दिया गया था। IANA IPv4 स्पेशल-पर्पस एड्रेस रजिस्ट्री, जो RFC 6890 द्वारा नियंत्रित है और RFC 8190 द्वारा अपडेट की गई है, इसी ब्लॉक को फॉरवर्ड न करने योग्य, ग्लोबली राउटेबल न होने योग्य और प्रोटोकॉल द्वारा आरक्षित के रूप में चिह्नित करती है। 127.0.0.1 पर सुनने वाली कोई भी प्रक्रिया केवल अपने होस्ट से आने वाले ट्रैफ़िक को ही देख पाती है। बाहर से आने वाला कोई भी ट्रैफ़िक जो 127 सोर्स एड्रेस का दावा करता है, उसे चुपचाप ड्रॉप कर दिया जाता है। नेटवर्क विशेषज्ञ इन पैकेटों को "मार्टियंस" कहते हैं।

लोकलहोस्ट, यह नाम, उसी विचार के लिए बस एक सरल होस्टनाम है। macOS या Linux पर `/etc/hosts` या Windows पर `C:\Windows\System32\drivers\etc\hosts` खोलें, और आपको शीर्ष के पास यह पंक्ति दिखाई देगी: `127.0.0.1 localhost`।

लूपबैक एड्रेस: लोकलहोस्ट आपके मशीन तक कैसे रूट करता है

127.0.0.1 सबसे प्रसिद्ध है। लेकिन यह इकलौता नहीं है। पूरा 127.0.0.0/8 ब्लॉक, जिसमें सोलह मिलियन से अधिक पते हैं, लूप बैक करता है। आप Linux पर 127.42.42.42 को पिंग कर सकते हैं। यह काम करता है। हममें से ज्यादातर लोग सहज रूप से 127.0.0.1 का ही उपयोग करते हैं, लेकिन जब आप iptables नियमों को पढ़ते हैं या किसी हार्ड इमेज का ऑडिट करते हैं तो व्यापक ब्लॉक महत्वपूर्ण हो जाता है। (IETF में कई वर्षों से एक मसौदा विचाराधीन है जो 127/8 के अधिकांश हिस्से को यूनिकास्ट उपयोग के लिए पुनः प्राप्त करने का प्रस्ताव करता है। इसे अभी तक अपनाया नहीं गया है।)

IPv6 पक्ष अधिक सरल है। RFC 4291 में एक ही पता, `::1`, परिभाषित है। इसमें /8 पोर्ट नहीं है। कोई अतिरिक्त पोर्ट नहीं है। यदि आपकी सेवा केवल `::1` से ही जुड़ती है, तो 127.0.0.1 पर प्रयास करने पर कुछ भी प्राप्त नहीं होगा, और इसके विपरीत भी। आधुनिक Linux और macOS दोनों पर, `localhost` दोनों पतों पर काम करता है, इसलिए ब्राउज़र आमतौर पर पहले `::1` पर प्रयास करता है, विफल होता है, और फिर वापस आ जाता है। आपको यह एक छोटे लेकिन स्पष्ट विलंब के रूप में दिखाई देगा। स्क्रिप्ट के अंदर एक ही पते पर पिन करने से यह अस्पष्टता दूर हो जाती है।

कर्नेल वर्चुअल इंटरफ़ेस पर लूपबैक पैकेट को हैंडल करता है। Linux इसे `lo` कहता है। macOS इसे `lo0` कहता है। `ip link show` और `ifconfig lo0` कमांड से इसे देखा जा सकता है। वही फ़ायरवॉल स्टैक जो बाकी सब कुछ नियंत्रित करता है, लूपबैक को भी नियंत्रित करता है, यही कारण है कि आक्रामक फ़ायरवॉल कॉन्फ़िगरेशन स्थानीय ट्रैफ़िक को बाधित कर सकता है। इसके बारे में कुछ अनुभागों में विस्तार से बताया जाएगा।

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

पोर्ट 57573 क्यों? IANA पोर्ट नंबर रेंज की व्याख्या

पोर्ट 57573 कोई खास पोर्ट नहीं है। ऑपरेटिंग सिस्टम या फ्रेमवर्क ने इसे इसलिए चुना क्योंकि यह खाली था। यह समझने के लिए कि इतनी बड़ी संख्या इतनी बार क्यों दिखाई देती है, आपको यह देखना होगा कि IANA 16-बिट पोर्ट स्पेस को कैसे विभाजित करता है। पूरी प्रक्रिया RFC 6335 और IANA सर्विस नेम एंड ट्रांसपोर्ट प्रोटोकॉल पोर्ट नंबर रजिस्ट्री में दी गई है।

49152–65535 वह रेंज है जिसे IANA अस्थायी पोर्ट के लिए अनुशंसित करता है । वास्तविक कर्नेल अक्सर इससे असहमत होते हैं। Linux डिफ़ॉल्ट रूप से 32768–60999 रेंज के साथ आता है (`sysctl net.ipv4.ip_local_port_range`)। Vista के बाद से Windows 49152–65535 रेंज का उपयोग करता आ रहा है। XP युग में 1025–5000 रेंज का उपयोग किया जाता था, जो एक सीमित रेंज थी और लोड के तहत पोर्ट को जल्दी-जल्दी इस्तेमाल करती थी, जिसके कारण कई बार सिस्टम बाधित हुआ। macOS IANA विनिर्देश का पालन करता है। पोर्ट 57573 हर आधुनिक डिफ़ॉल्ट पोर्ट के अंतर्गत आता है। यही एक तथ्य डेवलपर लॉग में इसके बार-बार दिखाई देने का मुख्य कारण है।

जब आपका कोड Flask में `app.run(port=0)` या Node में `server.listen(0)` करता है, तो ऑपरेटिंग सिस्टम अपनी स्थानीय डायनेमिक रेंज में से कोई भी खाली पोर्ट चुन लेता है। Linux लैपटॉप पर इसका मतलब 32768 से 60999 तक कोई भी पोर्ट हो सकता है। 57573 पोर्ट इसके अंतर्गत आसानी से आ जाता है। ऑटो-असाइनिंग टूल्स के लिए भी यही बात लागू होती है: Vite (जिसे 2022 में जानबूझकर 127.0.0.1 पोर्ट पर डिफ़ॉल्ट किया गया था ताकि डेवलपर्स कॉफी शॉप के वाईफाई पर सर्वर लीक न कर सकें), webpack-dev-server, VS Code Live Server, Jupyter, Selenium ड्राइवर ब्रिज, Playwright, Node का `--inspect=0` डीबगर। ये सभी कर्नेल से एक खाली हाई पोर्ट मांगते हैं और जो भी पोर्ट मिलता है, उसका उपयोग करते हैं।

इसलिए, यदि स्टैक ट्रेस में 57573 पोर्ट दिखाई देता है, तो इसका सीधा सा जवाब लगभग हमेशा सही होता है। या तो कोई प्रोसेस जानबूझकर उस पोर्ट से जुड़ा हुआ है, या किसी फ्रेमवर्क ने "कोई भी खाली पोर्ट" मांगा है और कर्नेल ने इसे चुन लिया है। पोर्ट नंबर 57573 में कोई समस्या नहीं है। अधिकांश स्थानीय परीक्षण और विकास फ्रेमवर्क इस पूरे उच्च पोर्ट रेंज को एक सुरक्षित, पृथक वातावरण मानते हैं, क्योंकि कोई भी सार्वजनिक सेवा इस पर निर्भर नहीं करती है।

सर्वर को 127.0.0.1 बनाम 0.0.0.0 बनाम ::1 से जोड़ना

गलत बाइंड टारगेट चुनने पर अजीबोगरीब बग आ सकते हैं। तीन परिभाषाओं को ध्यान में रखना जरूरी है।

127.0.0.1 केवल IPv4 लूपबैक को ही नियंत्रित करता है। यह उसी मशीन से किसी भी IPv4 क्लाइंट पर पहुंच योग्य है। बाहर से कभी नहीं।

::1 केवल IPv6 लूपबैक को बाइंड करता है। मूल विचार वही है, लेकिन केवल एक ही बॉक्स पर मौजूद IPv6 क्लाइंट के लिए।

0.0.0.0 राउटर पर मौजूद सभी IPv4 इंटरफेस को आपस में जोड़ता है। आपकी मशीन तक पहुंचने वाला कोई भी व्यक्ति, जिसमें समान वाई-फाई से जुड़े फोन, वीपीएन पीयर और (पोर्ट फॉरवर्डिंग के साथ) सार्वजनिक इंटरनेट शामिल हैं, उस तक पहुंच सकता है।

रोजमर्रा के डेवलपमेंट के लिए, 127.0.0.1 को बाइंड करें। यह एकमात्र इंटरफ़ेस है जहाँ फ़ायरवॉल, वीपीएन पॉलिसी और आकस्मिक एक्सपोज़र जैसी समस्याएं नहीं रहतीं। फ्लास्क, फास्टएपीआई और एक्सप्रेस सभी डिफ़ॉल्ट रूप से इसी का उपयोग करते हैं।

मेरे अनुभव के अनुसार, लोग तीन अलग-अलग कारणों से 0.0.0.0 की ओर आकर्षित होते हैं: LAN पर फ़ोन से परीक्षण करना, डॉकर के अंदर परीक्षण करना, और किसी ऐसे ट्यूटोरियल का अनुसरण करना जिसके लेखक ने गलत डिफ़ॉल्ट सेटिंग कॉपी-पेस्ट कर दी हो। इन तीनों के लिए एक सुरक्षित विकल्प मौजूद है। LAN परीक्षण के लिए, विशिष्ट LAN IP से कनेक्ट करें और एक अस्थायी फ़ायरवॉल नियम जोड़ें। डॉकर के लिए, कंटेनर के अंदर 0.0.0.0 से कनेक्ट करें, लेकिन होस्ट पर `docker run -p 127.0.0.1:8080:8080 …` कमांड का उपयोग करके IP प्रकाशित करें। ट्यूटोरियल के लिए, 0.0.0.0 वाली लाइन को अनदेखा करें और 127.0.0.1 पर पिन करें, जब तक कि आपके पास कोई ठोस कारण न हो।

एक साधारण फ्लास्क स्निपेट सुरक्षित डिफ़ॉल्ट सेटिंग दिखाता है:

```

from flask import Flask

ऐप = फ्लास्क(__नाम__)

@app.route("/")

def index():

"हैलो, लोकलहोस्ट!" लौटाएँ

यदि __नाम__ == "__मुख्य__":

ऐप.रन(होस्ट="127.0.0.1", पोर्ट=57573)

```

नेटस्टेट, एलएसडब्ल्यूएफ और एसएस का उपयोग करके पोर्ट 57573 का निरीक्षण करना

पोर्ट नंबर 57573 पर कोई जासूसी कर रहा है और आपको इसका कोई अंदाजा नहीं है। कमांड आपके ऑपरेटिंग सिस्टम पर निर्भर करता है। इस छोटी सी सूची को याद कर लें, यह आपके लिए सालों तक उपयोगी साबित होगी।

सामान्य लिनक्स आउटपुट:

```

$ ss -tlnp | grep 57573

LISTEN 0 4096 127.0.0.1:57573 0.0.0.0:* users:(("python3",pid=18432,fd=4))

```

बाएँ से दाएँ छह फ़ील्ड। स्थिति। प्रेषण कतार। प्राप्ति कतार। स्थानीय पता। सहकर्मी पता। प्रक्रिया। इस मामले में PID 18432। Unix पर `kill 18432`। PowerShell में `Stop-Process -Id 18432`। हो गया। यदि आपको केवल पोर्ट वापस चाहिए, तो यही संपूर्ण समाधान है।

अगर कुछ भी दिखाई न दे तो क्या होगा? इसका मतलब है कि कोई भी सर्वर सुन नहीं रहा है, जो अपने आप में एक उपयोगी जानकारी है। ब्राउज़र में बार-बार दिखने वाली "कनेक्शन अस्वीकृत" त्रुटि का आमतौर पर यही मतलब होता है। आपका सर्वर बंद हो गया है। या तो यह स्टार्टअप के दौरान क्रैश हो गया, या यह आपके द्वारा टाइप किए गए पते से कनेक्ट ही नहीं हो पाया।

सामान्य कनेक्शन विफलता त्रुटियाँ और उनके अर्थ

छह बातें। यही वो सारी विफलताएँ हैं जो आपको 127.0.0.1:57573 पर दिखाई देती हैं। त्रुटि संदेश पढ़ें, और एक श्रेणी चुनें।

`EADDRINUSE`, "पता पहले से उपयोग में है" या "पोर्ट 57573 पहले से ही आवंटित है" - इन सभी का मतलब एक ही है। कोई दूसरा एप्लिकेशन इस पोर्ट का उपयोग कर रहा है। पिछले भाग में दिए गए इंस्पेक्ट कमांड से आपको पता चल जाएगा कि कौन सा एप्लिकेशन उपयोग कर रहा है। उसे बंद कर दें, या अपनी सेवा के लिए किसी दूसरे पोर्ट का उपयोग करें। नेटस्टैट या एलओएसएफ जैसे टूल एक ही लाइन में यह काम पूरा कर देते हैं।

`ECONNREFUSED`, जो कि "कनेक्शन अस्वीकृत" का सरल रूप है, का अर्थ है: TCP कर्नेल तक पहुँच गया, लेकिन किसी ने संपर्क नहीं किया। आपका सर्वर स्टार्टअप के दौरान बंद हो गया, या कभी कनेक्ट ही नहीं हुआ। उस टर्मिनल को देखें जहाँ से आपने इसे लॉन्च किया था। ट्रेसबैक वहीं मौजूद है।

`ETIMEDOUT` और "Connection timed out" का मतलब है कि पैकेट चुपचाप गायब हो रहे हैं। 127.0.0.1 पर, ऐसा आमतौर पर कभी नहीं होना चाहिए। जब ऐसा होता है, तो इसका कारण फ़ायरवॉल नियम, वीपीएन एजेंट या कोई एंडपॉइंट प्रोटेक्शन टूल होता है। इन्हें एक-एक करके निष्क्रिय करें, पुनः प्रयास करें और प्रक्रिया दोहराएं।

रूट एक्सेस के बिना पोर्ट 1024 से नीचे बाइंड करने का प्रयास करने पर `EACCES` ("अनुमति अस्वीकृत") त्रुटि दिखाई देती है। पोर्ट 57573 जैसा कोई उच्च पोर्ट उपयोग करें, या बाइनरी को रूट के रूप में चलाएँ। तीसरा विकल्प उपलब्ध नहीं है।

`EAI_NONAME` और अन्य DNS त्रुटियों का मतलब है कि होस्टनाम रिजॉल्व नहीं हुआ। होस्ट फ़ाइल को `localhost` को 127.0.0.1 पर मैप करना चाहिए। हो सकता है कि किसी VPN क्लाइंट ने इसे ओवरराइड कर दिया हो। सिस्टम एडमिन ने कोई खराब इमेज भेजी हो सकती है। होस्ट फ़ाइल खोलें और पुष्टि करें कि `127.0.0.1 localhost` पहली नॉन-कमेंट लाइन है।

आखिरी वाला, जो थोड़ा पेचीदा है। सर्वर को पूरी तरह बंद करने के बाद, कर्नेल लगभग दो मिनट के लिए सॉकेट को TIME_WAIT मोड में डाल देता है। सर्वर को जल्दी से रीस्टार्ट करने पर आपको "Address already in use" का मैसेज दिखाई देगा, जबकि कोई भी सर्वर सुन नहीं रहा होगा। इसके तीन उपाय हैं: इंतज़ार करें, अपने bind में `SO_REUSEADDR` सेट करें, या किसी दूसरे पोर्ट पर स्विच कर दें। हममें से ज़्यादातर लोग यही करते हैं।

त्रुटि संदेश पढ़ें। समस्या का पता लगाएं। समस्या का समाधान करें। पूरी प्रक्रिया आमतौर पर एक मिनट से भी कम समय में पूरी हो जाती है।

फ़ायरवॉल सेटिंग्स जो पोर्ट 57573 को ब्लॉक करती हैं

लूपबैक ट्रैफ़िक सैद्धांतिक रूप से हमेशा अनुमत होता है। व्यवहार में, फ़ायरवॉल नियम कभी-कभी इसे बाधित कर देते हैं। 2026 में इसके कुछ प्रमुख उदाहरण इस प्रकार हैं:

• macOS एप्लीकेशन फ़ायरवॉल में "इनकमिंग कनेक्शन ब्लॉक करें" विकल्प को सख्त पर सेट करें। सिस्टम सेटिंग्स → नेटवर्क → फ़ायरवॉल में पोर्ट 57573 के मालिक बाइनरी को अनुमति सूची में जोड़ें।
• विंडोज डिफेंडर फ़ायरवॉल प्रोफ़ाइल में गड़बड़ी। एक नया डेवलपर टूल आपको एक्सेस की अनुमति देने के लिए कहता है। आप बिना सोचे-समझे कैंसिल पर क्लिक कर देते हैं। यह चुपचाप ब्लॉक कर देता है। `wf.msc` खोलें, डिनाई रूल हटा दें, और अगली बार प्रॉम्प्ट स्वीकार करें।
• Linux ufw या iptables में डिफ़ॉल्ट नीतियों को और सख्त किया गया है। `ufw status verbose` कमांड नियमों की सूची दिखाता है। `ufw allow from 127.0.0.1` कमांड स्पष्ट रूप से लूपबैक को खोलता है। अधिकांश डिस्ट्रो डिफ़ॉल्ट रूप से पहले से ही `lo` की अनुमति देते हैं, लेकिन कुछ हार्ड इमेज इसकी अनुमति नहीं देती हैं।
• एक कॉर्पोरेट वीपीएन या ज़ीरो-ट्रस्ट एजेंट ट्रैफ़िक को इंटरसेप्ट कर रहा है। कुछ एजेंट यूज़रस्पेस लिसनर के ज़रिए लोकल कनेक्शन को प्रॉक्सी करते हैं और लूपबैक को चुपचाप बाधित कर देते हैं। पुष्टि करने के लिए एजेंट को एक मिनट के लिए निष्क्रिय करें।
• एंटीवायरस या एंडपॉइंट प्रोटेक्शन। EDR उत्पाद कभी-कभी उच्च पोर्ट से जुड़े डेवलपर बाइनरी को तब तक ब्लॉक कर देते हैं जब तक आप उन्हें श्वेतसूची में शामिल नहीं कर लेते।

किसी भी प्रबंधित कॉर्पोरेट वातावरण में, इनमें से कम से कम एक समस्या अवश्य उत्पन्न होगी। निदान प्रक्रिया समान है: अपनी फ़ायरवॉल सेटिंग्स की जाँच करें, फिर उसी शेल से `curl http://127.0.0.1:57573` कमांड चलाएँ जिससे सर्वर शुरू किया गया था। क्या कर्ल काम करता है लेकिन ब्राउज़र विफल हो जाता है? आप गलत इंटरफ़ेस (अक्सर `::1` के बजाय 127.0.0.1) का उपयोग कर रहे हैं या कोई निजी नेटवर्क एक्सेस नीति लागू है। क्या कर्ल भी विफल हो जाता है? कर्नेल या फ़ायरवॉल पैकेट को आपके कोड तक पहुँचने से पहले ही रोक रहा है। वेब डेवलपर और नेटवर्क प्रशासक आंतरिक विकी पर इन सुझावों का आदान-प्रदान करते हैं क्योंकि जब तक आप दो बार इन समस्याओं का सामना नहीं करते, तब तक लक्षण एक जैसे ही दिखते हैं।

डॉकर, WSL और GitHub कोडस्पेस में लोकलहोस्ट

तीन ऐसी जगहें जहां लोकलहोस्ट आपकी अपेक्षा के अनुरूप व्यवहार करना बंद कर देता है।

पहले डॉकर की बात करते हैं। कंटेनर के अंदर, 127.0.0.1 कंटेनर का लूपबैक पोर्ट होता है, आपका नहीं। इसलिए, अगर आपका लैपटॉप 127.0.0.1:57573 पोर्ट पर कोई सर्विस चला रहा है, तो कंटेनर उस पोर्ट तक कभी नहीं पहुंच सकता। होस्ट गेटवे कहीं और होता है: मैक और विंडोज पर `host.docker.internal`, लिनक्स पर कोई ब्रिज आईपी। विपरीत दिशा (कंटेनर सर्विस, होस्ट कॉलर) के लिए एक पब्लिश फ्लैग की आवश्यकता होती है। `docker run -p 127.0.0.1:57573:57573 my-image`। `-p` हटा देने पर, कंटेनर के बाहर यह पोर्ट मौजूद ही नहीं होता।

WSL2 की अपनी कुछ खास विशेषताएं हैं। मिरर्ड नेटवर्किंग मोड (Windows 11 22H2 और उसके बाद के संस्करणों में `[wsl2] networkingMode=mirrored` के ज़रिए चुना जा सकता है) होस्ट के नेटवर्क स्टैक को WSL VM के साथ साझा करता है। इस मोड में, WSL के अंदर 127.0.0.1:57573 पर मौजूद कोई सेवा Windows पर उसी पते पर प्रतिक्रिया देती है। डिफ़ॉल्ट NAT मोड अभी भी पोर्ट फ़ॉरवर्ड करता है, लेकिन केवल `localhost` स्ट्रिंग के लिए, 127.0.0.1 के लिए हमेशा नहीं। इसमें एक गंभीर बग भी है, जिसे Microsoft WSL #40169 के रूप में ट्रैक किया गया है। मिरर्ड मोड चुपचाप कई पोर्ट को लॉक कर देता है। 127.0.0.1 पर बाइंड करने के प्रयास `WinError 10013` त्रुटि के साथ विफल हो जाते हैं, जिसे Python `PermissionError` के रूप में रिपोर्ट करता है। जब कोई पोर्ट बिना किसी स्पष्ट कारण के Windows पर बाइंड होने से इनकार करता है, तो सबसे पहले इसकी जाँच करें।

GitHub Codespaces और VS Code रिमोट SSH विपरीत दिशा में काम करते हैं। ये आपके पोर्ट को स्वचालित रूप से फॉरवर्ड कर देते हैं। 127.0.0.1:57573 पोर्ट पर Codespace के अंदर एक सर्वर शुरू करें और एडिटर आपके लिए एक टनल खोल देगा, जिससे वह पोर्ट एक अद्वितीय github.dev URL पर उपलब्ध हो जाएगा। आपके लैपटॉप पर खुलने वाला ब्राउज़र टैब 127.0.0.1 के बजाय उस URL से कनेक्ट होगा और अनुरोध टनल के माध्यम से वर्कस्पेस में वापस आ जाएगा।

तो एंडपॉइंट का नाम तो एक जैसा दिखता है। लेकिन पैकेट का वास्तविक मार्ग हर वातावरण में बिल्कुल अलग होता है। यह पता लगाने में पाँच मिनट बिताने से कि आप किस वातावरण में हैं, "कनेक्शन अस्वीकृत" संदेश को देखते हुए बीस मिनट की परेशानी बच जाती है।

लोकलहोस्ट पर HTTPS: सुरक्षित लोकल डेवलपमेंट के लिए सर्वोत्तम अभ्यास

आधुनिक ब्राउज़र और कई API स्थानीय विकास के लिए भी HTTPS का उपयोग अनिवार्य मानते हैं। सर्विस वर्कर, जियोलोकेशन, क्लिपबोर्ड API, और 'सुरक्षित' चिह्नित कोई भी कुकी, ये सभी सामान्य HTTP पर काम नहीं करते। एक अपवाद है: 127.0.0.1, जिसे ब्राउज़र पहले से ही सुरक्षित मानता है। यह अपवाद सामान्य विकास के अधिकांश उपयोगकर्ताओं के लिए लागू होता है। बाकी सभी के लिए, स्थानीय स्तर पर TLS का उपयोग करें।

सबसे कारगर टूल mkcert है, जिसे फिलिप्पो वाल्सोर्डा ने लिखा है। इसे एक बार `mkcert -install` कमांड से चलाएं, फिर `mkcert localhost 127.0.0.1 ::1` कमांड से चलाएं। इससे आपको `localhost+2.pem` सर्टिफिकेट और एक कुंजी मिलेगी। अपने डेवलपमेंट सर्वर को इस जोड़ी से कनेक्ट करें। ब्राउज़र बिना किसी चेतावनी के एक साफ ताला दिखाएगा, क्योंकि mkcert ने आपके सिस्टम और फ़ायरफ़ॉक्स ट्रस्ट स्टोर्स में एक लोकल रूट CA इंस्टॉल कर दिया है। Let's Encrypt `127.0.0.1` के लिए असली सर्टिफिकेट जारी नहीं कर सकता, क्योंकि वैलिडेट करने के लिए कोई डोमेन नहीं है, इसलिए लोकल CA ही इसका मानक समाधान है।

कुछ अन्य पैटर्न जिन्हें जानना उपयोगी होगा:

• स्वचालित परीक्षणों के लिए, किसी मैजिक-डीएनएस सेवा (`nip.io`, `sslip.io`, `traefik.me`, `localhost.direct`) का उपयोग करके आईपी पते को `127.0.0.1.nip.io` जैसे वास्तविक होस्टनाम में परिवर्तित करें। Let's Encrypt या ZeroSSL इन्हें प्रमाणित कर सकते हैं, और `localhost.direct` एक पूर्व-जारी वाइल्डकार्ड प्रमाणपत्र भी प्रकाशित करता है।
• अपनी सेवा को 0.0.0.0 के बजाय 127.0.0.1 से जोड़ें, ताकि प्रमाणपत्र (जो `127.0.0.1` को कवर करता है) वास्तव में मेल खाए।
• डेवलपर प्रमाणपत्रों को गिट से बाहर रखें। mkcert डिफ़ॉल्ट रूप से उन्हें आपकी वर्किंग डायरेक्टरी में डाल देता है। इन प्रमाणपत्रों को तुरंत `.gitignore` फ़ोल्डर में जोड़ें।
• स्थानीय CA को हर कुछ महीनों में बदलें। `mkcert -uninstall` इसे पूरी तरह से हटा देता है।
• यदि आप किसी कॉर्पोरेट MITM प्रॉक्सी के पीछे हैं, तो यह मान लें कि प्रॉक्सी आपके प्रमाणपत्रों को बदल देगा। यदि आपके टूल इसका समर्थन करते हैं, तो `127.0.0.1` पर प्रॉक्सी को अक्षम कर दें।

ब्राउज़रों का एक विशेष नियम भी है जिसे जानना ज़रूरी है। W3C सिक्योर कॉन्टेक्स्ट स्पेसिफिकेशन के अनुसार, `http://127.0.0.1`, `http://localhost` और `http://[::1]` को "संभावित रूप से भरोसेमंद" माना जाता है, जिससे HTTPS पेज बिना किसी मिश्रित-सामग्री अवरोध के उन्हें फ़ेच कर सकता है। यह विशेष छूट स्थानीय विकास के लिए है।

लोकलहोस्ट सुरक्षा की कोई सीमा नहीं है, जैसा कि अक्सर डेवलपर्स मानते हैं। DNS रीबाइंडिंग के ज़रिए ब्राउज़र को किसी भी वेबसाइट से लोकलहोस्ट तक पहुँचाया जा सकता है। इसमें एक दुर्भावनापूर्ण साइट अपने होस्टनेम को 127.0.0.1 पर री-रिज़ॉल्व कर देती है और हमलावर के पेज पर मौजूद जावास्क्रिप्ट को मूल साइट के ओरिजिन के तहत स्थानीय सेवाओं से बात करने देती है। 2019 का ज़ूम CVE (CVE-2019-13450) इसका एक प्रमुख उदाहरण है। ज़ूम ने macOS पर `localhost:19421` पर एक छिपा हुआ वेब सर्वर इंस्टॉल किया था ताकि मीटिंग लिंक डेस्कटॉप ऐप को लॉन्च कर सकें और कोई भी वेबसाइट इससे डेटा फ़ेच करके यूज़र को कैमरे के साथ मीटिंग में ज़बरदस्ती शामिल कर सके। लगभग 40 लाख मैक कंप्यूटर और इसी इंजन पर चलने वाले तेरह व्हाइट-लेबल क्लाइंट प्रभावित हुए थे। 2025 के अंत में जारी किए गए क्रोम 142 ने पुराने प्राइवेट नेटवर्क एक्सेस को लोकल नेटवर्क एक्सेस से बदल दिया। अब सार्वजनिक पेजों को लूपबैक या निजी पतों तक पहुँचने से पहले स्पष्ट अनुमति माँगनी पड़ती है, जिससे NCC ग्रुप के सिंगुलैरिटी द्वारा स्वचालित रूप से किए जाने वाले अधिकांश हमलों को नाकाम किया जा सकता है। 2025 के स्ट्राइकर एडवाइजरी में स्थानीय रूप से चल रहे मॉडल कॉन्टेक्स्ट प्रोटोकॉल सर्वरों के खिलाफ इसी तरह के हमले का दस्तावेजीकरण किया गया था, जो डेवलपर्स द्वारा लूपबैक पर अधिक LLM एजेंट चलाने के कारण तेजी से बढ़ता हुआ खतरा बन गया है। 127.0.0.1 से सख्ती से बाइंड करें, प्रमाणीकरण आवश्यक करें, `Origin` हेडर की जाँच करें और डेवलपर API पर वाइल्डकार्ड CORS से बचें। इन चार आदतों से इनमें से अधिकांश हमलों को रोका जा सकता है।

समस्या निवारण युक्तियाँ और त्वरित निदान जाँच सूची

जब 127.0.0.1:57573 जवाब देने से इनकार कर दे, तो किसी गहरी रहस्यमयी घटना की आशंका करने से पहले इस संक्षिप्त सूची को देखें।

1. सुनिश्चित करें कि सर्वर वास्तव में चल रहा है। उस टर्मिनल को देखें जहाँ से आपने इसे लॉन्च किया था। यदि यह क्रैश हो गया है, तो स्टैक ट्रेस वहीं मौजूद होगा।

2. पुष्टि करें कि यह 127.0.0.1 से जुड़ा है, न कि केवल 0.0.0.0 या ::1 से। अधिकांश फ्रेमवर्क स्टार्टअप पर बाइंड एड्रेस प्रिंट करते हैं। लाइन पढ़ें।

3. उसी शेल से `curl -v http://127.0.0.1:57573` कमांड चलाकर देखें। क्या कर्ल काम कर रहा है? समस्या ब्राउज़र में है, सर्वर में नहीं।

4. पता करें कि पोर्ट का मालिक कौन है। लिनक्स, `ss -tlnp | grep :57573`। मैकओएस, `lsof -i :57573`। विंडोज, `netstat -ano | findstr :57573`।

5. क्या कोई गलत प्रक्रिया इसका स्वामित्व ले रही है? उसे बंद करें, फिर अपने सर्वर को पुनः आरंभ करें।

6. क्या कोई भी सुन नहीं रहा है? स्टार्टअप लॉग देखें। `EACCES` का मतलब विशेषाधिकार प्राप्त पोर्ट है। `EADDRINUSE` आमतौर पर पुराने TIME_WAIT को दर्शाता है।

7. IPv6 फॉर्मेट को आज़माएँ। `curl http://[::1]:57573`। यदि `127.0.0.1` या `::1` में से कोई एक काम करता है और दूसरा नहीं, तो आपकी सेवा सिंगल-स्टैक है।

8. कोई दूसरा पोर्ट आज़माएँ: `--port 12345` (या जो भी हो) पास करें और रीलोड करें। नया पोर्ट काम कर रहा है? आपके सिस्टम में पोर्ट से संबंधित समस्या है।

9. वीपीएन, एंटीवायरस और एंडपॉइंट एजेंट को एक मिनट के लिए बंद कर दें। यदि 57573 जवाब देना शुरू कर देता है, तो इसका मतलब है कि उनमें से कोई एक ट्रैफ़िक को बाधित कर रहा था।

10. कंप्यूटर को रीबूट करें, या कम से कम नेटवर्क इंटरफ़ेस को रीस्टार्ट करें। हालांकि यह समस्या का एकमात्र समाधान नहीं है। लेकिन जब अन्य कोई उपाय काम न करे, तो यह पुराने सॉकेट और अटके हुए फ़ायरवॉल की समस्या को हल कर देता है।

अधिकांश डेवलपर समस्याओं के लिए, पहले चार समस्या निवारण चरण कनेक्शन विफलता के कारण का पता लगा लेते हैं। बाकी चरण उन असामान्य मामलों को कवर करते हैं, जहां IPv6 बेमेल, पुराने सॉकेट या किसी प्रतिकूल फ़ायरवॉल परत के कारण वास्तविक विफलता छिपी होती है। त्रुटि संदेश पढ़ें, फिर सूची में दिए गए चरणों का पालन करें।

प्लिसियो से संबंधित एक महत्वपूर्ण बात। जब आप किसी क्रिप्टो भुगतान प्रोसेसर के वेबहुक को एकीकृत करते हैं, तो गेटवे को एक सार्वजनिक यूआरएल की आवश्यकता होती है जिस पर वह POST कर सके। प्लिसियो इनवॉइस एपीआई पेलोड में `callback_url` स्वीकार करते हैं, और सिस्टम उस एंडपॉइंट पर स्टेटस अपडेट POST करता है। आपका स्थानीय सर्वर 127.0.0.1:57573 परिभाषा के अनुसार सार्वजनिक इंटरनेट से पहुंच योग्य नहीं है, इसलिए इसका मानक समाधान टनल है। 2026 में आमतौर पर चुने जाने वाले विकल्प हैं ngrok (व्यक्तिगत उपयोग के लिए $8/माह, प्रो उपयोग के लिए $20/माह), Cloudflare Tunnel (जीरो ट्रस्ट पर 50 उपयोगकर्ताओं तक निःशुल्क), और Tailscale Funnel (व्यक्तिगत उपयोग के लिए निःशुल्क, टीमों के लिए सशुल्क $6/उपयोगकर्ता/माह)। ये सभी एक सार्वजनिक होस्टनाम लेते हैं और ट्रैफ़िक को आपके लैपटॉप के 127.0.0.1:57573 पोर्ट पर अग्रेषित करते हैं। प्लिसियो के पायथन, पीएचपी और नोड एसडीके में एक `validate_callback` हेल्पर शामिल है जो क्रमबद्ध JSON बॉडी पर HMAC-SHA1 `verify_hash` को सत्यापित करता है, इसलिए एक बार टनल स्थापित हो जाने के बाद वही हैंडलर डेवलपमेंट और प्रोडक्शन दोनों में समान रूप से काम करता है।

Mathis Curcio

Mathis Curcio is a senior content strategist and NFT specialist at Plisio. With over 5 years of experience in the Web3 space, Mathis focuses on the evolution of NFT ecosystems, digital collectibles, and decentralized ownership models. He creates accessible, insight-driven content that bridges the gap between blockchain innovation and mainstream adoption. His expertise spans NFT market trends, use cases across art and gaming, and the infrastructure powering next-generation tokenized assets.