۱۲۷.۰.۰.۱:۵۷۵۷۳ راهنمای پورت لوکال هاست و عیب یابی آن
یک اسکریپت کوچک Flask اجرا کنید. `http://127.0.0.1:57573` را در مرورگر جایگذاری کنید. دو نتیجه دارد. صفحه بارگیری میشود، یا ترمینال با `ECONNREFUSED` قرمز میشود و مرورگر آن آیکون غمگین قطع اتصال را نشان میدهد.
هیچکدام از این دو نتیجه مرموز نیستند. این آدرس دو نیمه دارد: ۱۲۷.۰.۰.۱ حلقهی برگشتی IPv۴ است و ۵۷۵۷۳ پورتی است که سیستم عامل تقریباً به طور تصادفی از مجموعه پورتهای بالای خود برداشته است. این راهنما هر دو نیمه را باز میکند. ما بررسی خواهیم کرد که چرا بسیاری از سرورهای محلی روی چنین پورتی قرار میگیرند و شش مورد از مشکلاتی را که قبل از باز شدن اتصال رخ میدهند، بررسی خواهیم کرد. در پایان، شما باید بدانید که چگونه یک سرویس را به رابط صحیح متصل کنید، ببینید چه چیزی واقعاً روی یک پورت گوش میدهد، تداخل پورتها و بلوکهای فایروال را برطرف کنید و سرور محلی را قبل از اتصال به اینترنت عمومی، قفل کنید.
معنی عبارت 127.0.0.1:57573 در انگلیسی ساده چیست؟
سه بخش. آدرس IP 127.0.0.1 حلقه بازگشتی IPv4 است. علامت دونقطه میگوید «و روی این پورت». 57573 خود پورت است که در محدوده شماره بالا قرار دارد و هیچ سرویس گسترده مستقر به طور دائم آن را در اختیار ندارد.
به آن متصل شوید و هسته بسته را مستقیماً به دستگاه محلی شما هدایت میکند. بدون کارت شبکه. بدون سوئیچ. بدون رفت و برگشت از طریق هیچ سیمی. این آدرس به یک فرآیند اجازه میدهد تا با فرآیندهای دیگر در همان میزبان صحبت کند بدون اینکه چیزی را در معرض شبکه خارجی قرار دهد. این کل نکته loopback است.
این رزرو قدیمیتر از آن چیزی است که اکثر توسعهدهندگان از آن استفاده میکنند. RFC 1122، بخش 3.2.1.3، کل بلوک 127.0.0.0/8، یعنی تمام 16,777,216 آدرس را در سال 1989 برای همیشه از دسترس خارج کرد. رجیستری آدرسهای ویژه IANA IPv4، که توسط RFC 6890 اداره و توسط RFC 8190 بهروزرسانی میشود، همان بلوک را به عنوان غیرقابل ارسال، غیرقابل مسیریابی سراسری و رزرو شده توسط پروتکل علامتگذاری میکند. هر فرآیندی که به 127.0.0.1 گوش میدهد، فقط ترافیک میزبان خود را میبیند. هر چیزی که از خارج وارد شود و آدرس منبع 127 را ادعا کند، بیسروصدا حذف میشود. افراد شبکه به این بستهها "مریخی" میگویند.
نام Localhost، فقط نام میزبان قابل فهم برای انسان است که برای همین منظور استفاده میشود. در macOS یا لینوکس، فایل `/etc/hosts` و در ویندوز، فایل `C:\Windows\System32\drivers\etc\hosts` را باز کنید. این خط را تقریباً در بالای صفحه خواهید دید: `127.0.0.1 localhost`.
آدرس حلقه برگشتی: چگونه localhost به دستگاه شما مسیردهی میکند
۱۲۷.۰.۰.۱ معروفترین است. تنها مورد نیست. کل بلوک ۱۲۷.۰.۰.۰/۸، تمام شانزده میلیون آدرس، به عقب برمیگردند. میتوانید ۱۲۷.۴۲.۴۲.۴۲ را در لینوکس پینگ کنید. این روش کار میکند. اکثر ما به صورت خودکار به ۱۲۷.۰.۰.۱ پایبند هستیم، اما وقتی قوانین iptables را میخوانید یا یک تصویر سختشده را بررسی میکنید، بلوک وسیعتر اهمیت پیدا میکند. (سالهاست که پیشنویسی در IETF در جریان است که پیشنهاد میکند بیشتر ۱۲۷/۸ برای استفاده تکپخشی بازپس گرفته شود. این پیشنهاد پذیرفته نشده است.)
سمت IPv6 سادهتر است. یک آدرس، `::1`، در RFC 4291 تعریف شده است. خیر /8. بدون آدرس اضافی. اگر سرویس شما فقط به `::1` متصل شود، هر چیزی که 127.0.0.1 را امتحان کند، چیزی دریافت نمیکند و برعکس. در یک لینوکس مدرن و در macOS، `localhost` به هر دو پاسخ میدهد، بنابراین مرورگر معمولاً ابتدا `::1` را امتحان میکند، شکست میخورد و سپس به عقب برمیگردد. شما این را به عنوان یک تأخیر کوچک اما قابل مشاهده میبینید. در داخل اسکریپت، به یک آدرس پین کنید و ابهام از بین میرود.
هسته، بستههای loopback را در یک رابط مجازی مدیریت میکند. لینوکس آن را `lo` و macOS آن را `lo0` مینامد. `ip link show` و `ifconfig lo0` آن را نشان میدهند. همان پشته فایروال که همه چیز را کنترل میکند، loopback را نیز کنترل میکند، به همین دلیل است که یک پیکربندی فایروال تهاجمی میتواند ترافیک محلی را مختل کند. در چند بخش دیگر بیشتر در مورد آن صحبت خواهیم کرد.
نکتهی اصلی برای توسعه: 127.0.0.1 امنترین رابط برای اتصال است. هیچ چیز خارج از دستگاه شما نمیتواند به آن دسترسی پیدا کند. کانتینرها و ماشینهای مجازی، حلقهی بازگشتی مخصوص به خود را دارند که جدا از حلقهی بازگشتی میزبان است و همین موضوع باعث میشود که اکثر توسعهدهندگان برای اولین بار که انتظار دارند 127.0.0.1 درون یک کانتینر داکر به طور جادویی به یک سرویس در لپتاپ برسد، دچار سردرگمی شوند.
چرا پورت ۵۷۵۷۳؟ توضیح محدوده شماره پورتهای IANA
پورت ۵۷۵۷۳ پورت خاصی نیست. سیستم عامل یا فریم ورک آن را به دلیل رایگان بودنش انتخاب کرده است. برای اینکه بفهمید چرا چنین عدد بزرگی اینقدر زیاد نمایش داده میشود، باید ببینید که IANA چگونه فضای پورت ۱۶ بیتی را تقسیم میکند. کل این طرح در RFC 6335 و رجیستری شماره پورت پروتکل انتقال و نام سرویس IANA قرار دارد.
| محدوده | نام ایانا | مثالها |
|---|---|---|
| ۰–۱۰۲۳ | پورتهای سیستم/معروف | ۲۲ SSH، ۸۰ HTTP، ۴۴۳ HTTPS، ۵۳ DNS |
| ۱۰۲۴–۴۹۱۵۱ | پورتهای کاربر/ثبتشده | ۳۳۰۶ MySQL، ۵۴۳۲ Postgres، ۸۰۸۰ alt-HTTP |
| ۴۹۱۵۲–۶۵۵۳۵ | پویا / خصوصی / زودگذر | توسط سیستم عامل به صورت خودکار اختصاص داده میشود، هرگز در IANA ثبت نمیشود |
۴۹۱۵۲–۶۵۵۳۵ محدودهای است که IANA برای پورتهای موقت توصیه میکند . هستههای واقعی اغلب با این موضوع مخالفند. لینوکس به طور پیشفرض با ۳۲۷۶۸–۶۰۹۹۹ (`sysctl net.ipv4.ip_local_port_range`) ارائه میشود. ویندوز از زمان ویستا از ۴۹۱۵۲–۶۵۵۳۵ استفاده کرده است. دوران XP از ۱۰۲۵–۵۰۰۰ استفاده میکرد، محدودهای محدود که پورتها را تحت بار پردازشی میبلعید و باعث قطعیهای معروف میشد. macOS به مشخصات IANA پایبند است. پورت ۵۷۵۷۳ در هر پیشفرض مدرنی جای میگیرد. همین حقیقت به تنهایی توضیح میدهد که چرا این پورت در لاگهای توسعهدهندگان وجود دارد.
وقتی کد شما در Flask دستور `app.run(port=0)` یا در Node دستور `server.listen(0)` را اجرا میکند، سیستم عامل هر پورت خالی را از محدوده پویای محلی خود انتخاب میکند. در یک لپتاپ لینوکس، این به معنای هر پورتی از ۳۲۷۶۸ تا ۶۰۹۹۹ است. ۵۷۵۷۳ به راحتی در داخل آن قرار میگیرد. همین داستان برای ابزارهای تخصیص خودکار نیز صادق است: Vite (که در سال ۲۰۲۲ عمداً مقدار پیشفرض را روی ۱۲۷.۰.۰.۱ تنظیم کرد تا توسعهدهندگان از نشت سرورها از طریق وایفای کافیشاپ جلوگیری کنند)، webpack-dev-server، VS Code Live Server، Jupyter، پلهای درایور سلنیوم، Playwright، اشکالزدای `--inspect=0` در Node. همه آنها فقط از هسته درخواست یک پورت بالای رایگان میکنند و از هر آنچه دریافت میکنند استفاده میکنند.
بنابراین اگر عدد ۵۷۵۷۳ در ردیابی پشته ظاهر شود، تقریباً همیشه پاسخ کسلکننده، پاسخ درست است. یا فرآیندی عمداً به آنجا محدود شده است، یا یک چارچوب درخواست "هر پورت آزادی" کرده و هسته این پورت را انتخاب کرده است. هیچ مشکلی به طور خاص با شماره پورت ۵۷۵۷۳ وجود ندارد. اکثر چارچوبهای تست و توسعه محلی، کل محدوده بالا را به عنوان یک محیط امن و ایزوله در نظر میگیرند، زیرا هیچ سرویس عمومی به آن وابسته نیست.
اتصال یک سرور به 127.0.0.1 در مقابل 0.0.0.0 در مقابل ::1
اگر هدف اتصال اشتباه را انتخاب کنید، با باگهای عجیبی مواجه میشوید. سه تعریف برای روشن شدن موضوع.
۱۲۷.۰.۰.۱ فقط به حلقه بازگشتی IPv4 متصل میشود. از همان دستگاه روی هر کلاینت IPv4 قابل دسترسی است. هرگز از خارج قابل دسترسی نیست.
::1 فقط حلقه بازگشتی IPv6 را متصل میکند. ایده مشابه است، اما فقط کلاینتهای IPv6 روی همان دستگاه.
0.0.0.0 به هر رابط IPv4 روی دستگاه متصل میشود. هر کسی که به دستگاه شما مسیریابی میکند میتواند به آن دسترسی داشته باشد، از جمله تلفنهای روی همان Wi-Fi، VPN peers و (با port forwarding) اینترنت عمومی.
برای توسعههای روزمره، به 127.0.0.1 متصل شوید. این تنها رابطی است که در آن فایروالها، سیاستهای VPN و افشای تصادفی دیگر مشکلساز نخواهند بود. Flask، FastAPI و Express همگی به طور پیشفرض روی آن هستند.
طبق تجربه من، افراد از سه جای مختلف به سمت 0.0.0.0 سوق پیدا میکنند. تست روی تلفن از طریق LAN. تست داخل Docker. دنبال کردن آموزشی که نویسنده آن پیشفرض اشتباه را کپی پیست کرده است. هر کدام حرکت امنتری دارند. برای تست LAN، به IP خاص LAN متصل شوید و یک قانون فایروال موقت اضافه کنید. برای Docker، 0.0.0.0 را داخل کانتینر متصل کنید اما با `docker run -p 127.0.0.1:8080:8080 …` روی میزبان منتشر کنید. برای آموزشها، خط 0.0.0.0 را نادیده بگیرید و به 127.0.0.1 پین کنید، مگر اینکه دلیل واقعی داشته باشید.
یک قطعه کد خستهکننده از Flask، پیشفرض امن را نشان میدهد:
```
از فلاسک، فلاسک را ایمپورت کنید
برنامه = فلاسک(__name__)
@app.route("/")
شاخص تعریف():
"سلام، میزبان محلی!" را برمیگرداند.
اگر __name__ == "__main__":
app.run(host="127.0.0.1", port=57573)
```
بررسی پورت ۵۷۵۷۳ با netstat، lsof و ss
چیزی روی ۵۷۵۷۳ در حال گوش دادن است و شما هیچ سرنخی از آن ندارید. این دستور به سیستم عامل شما بستگی دارد. این لیست کوتاه را به خاطر بسپارید و سالها از آن استفاده خواهید کرد.
| سیستم عامل / پوسته | فرمان | یادداشتها | |
|---|---|---|---|
| لینوکس (مدرن) | دستور `ss -tlnp` | دستور grep:57573` | جایگزین netstat میشود. اگر با دسترسی root اجرا شود، فرآیند را نشان میدهد. |
| لینوکس (نسخه قدیمی) | دستور netstat -tlnp | دستور grep:57573` | ممکن است net-tools روی تصاویر کوچک نصب نشود. |
| مکاواس | `lsof -i :57573` | در لینوکس هم همینطور است. شامل فرآیند و کاربر میشود | |
| سی ام دی ویندوز | دستور netstat -ano | یافتن رشته: 57573` | ستون PID به Task Manager نگاشت میشود |
| ویندوز پاورشل | `دریافت-NetTCPConnection -LocalPort 57573` | تمیزتر، قابل اسکریپتنویسی |
خروجی معمول لینوکس:
```
دستور grep با کد 57573
گوش دهید 0 4096 127.0.0.1:57573 0.0.0.0:* کاربران:(("python3",pid=18432,fd=4))
```
شش فیلد، از چپ به راست. وضعیت. صف ارسال. صف دریافت. آدرس محلی. آدرس نظیر. فرآیند. در این مورد PID 18432. در یونیکس `kill 18432`. در پاورشل `Stop-Process -Id 18432`. انجام شد. اگر تنها چیزی که میخواستید برگرداندن پورت بود، کل مشکل همین است.
اگر چیزی نمایش داده نشود چه؟ پس هیچ چیزی در حال گوش دادن نیست، که خود اطلاعات مفیدی است. آن خطای مرورگری که مدام میبینید، "اتصال رد شد"، معمولاً فقط به این معنی است. سرور شما از کار افتاده است. در هنگام راهاندازی از کار افتاده است، یا هرگز به آدرسی که تایپ کردهاید متصل نشده است.
خطاهای رایج قطع اتصال و معنی آنها
شش مورد. این کل لیست خرابیهایی است که در 127.0.0.1:57573 میبینید. رشته خطا را بخوانید، یک سطل را انتخاب کنید.
عبارات `EADDRINUSE`، `Address already in use` یا `port 57573 is already dedicated` همگی به یک معنی هستند. برنامه دیگری در حال استفاده از پورت است. دستورات inspect از بخش قبل به شما میگویند که کدام یک. آن را متوقف کنید یا فقط از پورت دیگری برای سرویس خود استفاده کنید. ابزارهایی مانند netstat یا lsof کار را در یک خط تمام میکنند.
عبارت «ECONNREFUSED» که به صورت دوستانهتر «اتصال رد شد» نوشته میشود، میگوید: TCP وارد هسته شد، اما کسی گوشی را برنداشت. سرور شما در هنگام راهاندازی از کار افتاد یا هرگز متصل نشد. به ترمینالی که آن را اجرا کردید نگاه کنید. ردگیری همانجاست.
«ETIMEDOUT» و «اتصال زمانبندی شده» به این معنی است که بستهها بیصدا ناپدید میشوند. در آدرس ۱۲۷.۰.۰.۱، این اتفاق اساساً نباید هرگز رخ دهد. وقتی این اتفاق میافتد، یک قانون فایروال، یک عامل VPN یا یک ابزار محافظت از نقاط پایانی علت آن است. آنها را یکی یکی غیرفعال کنید، دوباره امتحان کنید، تکرار کنید.
وقتی سعی میکنید بدون دسترسی root به پورت پایینتر از ۱۰۲۴ متصل شوید، خطای `EACCES` ("Permission denied") نمایش داده میشود. از یک پورت بالا مانند ۵۷۵۷۳ استفاده کنید، یا فایل باینری را به عنوان root اجرا کنید. گزینه سوم وجود ندارد.
خطاهای `EAI_NONAME` و سایر خطاهای DNS به این معنی هستند که نام میزبان هرگز حل نشده است. قرار است فایل hosts، `localhost` را به 127.0.0.1 نگاشت کند. ممکن است یک کلاینت VPN آن را بازنویسی کرده باشد. ممکن است یک مدیر سیستم یک تصویر خراب ارسال کرده باشد. فایل hosts را باز کنید. تأیید کنید که `127.0.0.1 localhost` اولین خط غیر کامنت است.
آخرین مورد، روش مخفیانه. بعد از یک خاموش کردن کامل، هسته سیستم، سوکت را به مدت تقریباً دو دقیقه در TIME_WAIT پین میکند. سرور را سریعاً راهاندازی مجدد کنید و میبینید که "آدرس از قبل در حال استفاده است" حتی اگر کسی گوش ندهد. سه پاسخ وجود دارد: صبر کنید، `SO_REUSEADDR` را در اتصال خود تنظیم کنید، یا فقط به یک پورت دیگر بروید. اکثر ما این کار را میکنیم.
رشته خطا را بخوانید. سطل را بردارید. راه حل را اعمال کنید. کل حلقه معمولاً در کمتر از یک دقیقه بسته میشود.
تنظیمات فایروال که پورت ۵۷۵۷۳ را مسدود میکنند
ترافیک Loopback، در تئوری، همیشه مجاز است. در عمل، قوانین فایروال گاهی اوقات آن را نقض میکنند. مظنونین همیشگی در سال ۲۰۲۶:
- فایروال برنامه macOS با تنظیم «مسدود کردن اتصالات ورودی» روی حالت strict. فایل باینری مربوط به پورت ۵۷۵۷۳ را به لیست مجاز در تنظیمات سیستم → شبکه → فایروال اضافه کنید.
- عدم تطابق پروفایل فایروال ویندوز دیفندر. یک ابزار توسعه جدید از شما میخواهد که اجازه دسترسی بدهید. شما با یک واکنش غیرارادی روی لغو کلیک میکنید. این ابزار بیسروصدا مسدود میشود. `wf.msc` را باز کنید، قانون رد دسترسی را حذف کنید و دفعه بعد درخواست را بپذیرید.
- لینوکس ufw یا iptables با سیاستهای پیشفرض سختگیرانهتر. `ufw status verbose` قوانین را فهرست میکند. `ufw allow from 127.0.0.1` صراحتاً loopback را باز میکند. اکثر پیشفرضهای توزیعها از قبل `lo` را مجاز میدانند، اما برخی از تصاویر مقاومسازیشده این امکان را ندارند.
- یک VPN شرکتی یا یک عامل zero-trust که ترافیک را رهگیری میکند. برخی از عاملها از طریق یک شنونده فضای کاربری، اتصالات محلی را پروکسی میکنند و بیسروصدا loopback را منگوله میکنند. برای تأیید، عامل را به مدت یک دقیقه غیرفعال کنید.
- آنتی ویروس یا محافظت از نقاط پایانی. محصولات EDR گاهی اوقات فایلهای باینری توسعه را که به پورتهای بالا متصل میشوند، تا زمانی که آنها را در لیست سفید قرار ندهید، مسدود میکنند.
در هر محیط سازمانی مدیریتشده، انتظار میرود حداقل یکی از این موارد فعال شود. روند تشخیص مشابه است: تنظیمات فایروال خود را بررسی کنید، سپس `curl http://127.0.0.1:57573` را از همان پوستهای که سرور را راهاندازی کرده است، اجرا کنید. Curl کار میکند اما مرورگر از کار میافتد؟ شما به رابط کاربری اشتباهی (اغلب `::1` به جای 127.0.0.1) برخورد میکنید یا یک سیاست دسترسی به شبکه خصوصی در حال اجرا است. Curl هم از کار میافتد؟ هسته یا فایروال قبل از اینکه بسته به کد شما برسد، آن را رهگیری میکند. توسعهدهندگان وب و مدیران شبکه این نکات را در ویکیهای داخلی رد و بدل میکنند زیرا علائم تا زمانی که دو بار به آنها برخورد نکرده باشید، یکسان به نظر میرسند.
میزبان محلی در Docker، WSL و GitHub Codespaces
سه جایی که localhost دیگر آنطور که انتظار دارید رفتار نمیکند.
اول داکر. درون یک کانتینر، ۱۲۷.۰.۰.۱ حلقهی برگشتی کانتینر است. نه مال شما. بنابراین اگر لپتاپ شما سرویسی را روی ۱۲۷.۰.۰.۱:۵۷۵۷۳ اجرا میکند، کانتینر نمیتواند تحت همان آدرس به آن دسترسی پیدا کند. همیشه. دروازهی میزبان در جای دیگری قرار دارد: `host.docker.internal` در مک و ویندوز، و یک IP پل در لینوکس. جهت معکوس (سرویس کانتینر، فراخوانیکنندهی میزبان) به یک پرچم انتشار نیاز دارد. `docker run -p 127.0.0.1:57573:57573 my-image`. `-p` را حذف کنید و پورت به سادگی در خارج از کانتینر وجود ندارد.
WSL2 شخصیت خاص خودش را دارد. حالت شبکه آینهای (opt-in در ویندوز 11 نسخه 22H2 و بالاتر، از طریق `[wsl2] networkingMode=mirrored`) پشته شبکه میزبان را با ماشین مجازی WSL به اشتراک میگذارد. در این حالت، یک سرویس روی آدرس 127.0.0.1:57573 در WSL در ویندوز با همان آدرس پاسخ میدهد. حالت پیشفرض NAT همچنان پورتها را ارسال میکند، اما فقط برای رشتههای `localhost`، نه همیشه برای آدرس واقعی 127.0.0.1. همچنین یک اشکال شناخته شده در آنجا وجود دارد که با نام Microsoft WSL #40169 ردیابی میشود. حالت آینهای بیسروصدا تعداد زیادی از پورتهای پرسرعت را قفل میکند. تلاشهای اتصال روی 127.0.0.1 با `WinError 10013` شکست میخورند، که پایتون به خوبی آن را به عنوان `PermissionError` گزارش میدهد. وقتی یک پورت بدون هیچ دلیل واضحی از اتصال به ویندوز خودداری میکند، ابتدا این را بررسی کنید.
GitHub Codespaces و VS Code Remote SSH در جهت مخالف عمل میکنند. آنها پورتهای شما را به طور خودکار ارسال میکنند. یک سرور را درون یک Codespace روی آدرس 127.0.0.1:57573 راهاندازی کنید و ویرایشگر یک تونل برای شما باز میکند و آن پورت را در یک URL منحصر به فرد github.dev نمایش میدهد. تب مرورگری که روی لپتاپ خود باز میکنید با آن URL ارتباط برقرار میکند، نه 127.0.0.1، و درخواست از طریق تونل به فضای کاری برمیگردد.
بنابراین نام نقطه پایانی یکسان به نظر میرسد. مسیر واقعی که بسته طی میکند در هر محیط به شدت متفاوت است. پنج دقیقه صرف کردن برای فهمیدن اینکه در کدام محیط هستید، بیست دقیقه صرف خیره شدن به پیام "اتصال رد شد" را صرفهجویی میکند.
HTTPS در لوکال هاست: بهترین شیوهها برای توسعه محلی امن
مرورگرهای مدرن و بسیاری از APIها حتی برای توسعه محلی نیز بر HTTPS اصرار دارند. سرویس ورکرها. موقعیت جغرافیایی. API کلیپبورد. هر کوکی که با عنوان «امن» مشخص شده باشد. همه آنها از کار کردن روی HTTP ساده خودداری میکنند. یک استثنا وجود دارد: 127.0.0.1 که مرورگر از قبل آن را به عنوان یک زمینه امن در نظر میگیرد. این استثنا اکثر توسعهدهندگان معمولی را پوشش میدهد. برای هر چیز دیگری، TLS را به صورت محلی اجرا کنید.
با اختلاف زیاد، تمیزترین ابزار mkcert است که توسط Filippo Valsorda نوشته شده است. آن را یک بار با `mkcert -install` و سپس `mkcert localhost 127.0.0.1 ::1` اجرا کنید، و یک گواهی `localhost+2.pem` به همراه یک کلید دریافت خواهید کرد. سرور توسعه خود را به سمت این دو نشان دهید. مرورگر یک قفل تمیز و بدون هشدار نشان میدهد، زیرا mkcert یک گواهی ریشه محلی را در سیستم شما و فروشگاههای اعتماد Firefox نصب کرده است. Let's Encrypt نمیتواند یک گواهی واقعی برای `127.0.0.1` صادر کند، زیرا هیچ دامنهای برای اعتبارسنجی وجود ندارد، بنابراین یک گواهی محلی پاسخ استاندارد است.
چند الگوی دیگر که ارزش دانستن دارند:
- برای تستهای خودکار، یک سرویس DNS جادویی (`nip.io`، `sslip.io`، `traefik.me`، `localhost.direct`) را برای تبدیل یک IP به یک نام میزبان واقعی مانند `127.0.0.1.nip.io` انتخاب کنید. Let’s Encrypt یا ZeroSSL میتوانند این موارد را تأیید کنند، و `localhost.direct` حتی یک گواهی wildcard از پیش صادر شده منتشر میکند.
- سرویس خود را به 127.0.0.1 متصل کنید، نه 0.0.0.0، تا گواهی (که `127.0.0.1` را پوشش میدهد) در واقع مطابقت داشته باشد.
- گواهیهای توسعهدهندگان را از گیت دور نگه دارید. mkcert بهطور پیشفرض آنها را در دایرکتوری کاری شما ذخیره میکند. این جفت را فوراً به `.gitignore` اضافه کنید.
- هر چند ماه یکبار CA محلی را تغییر دهید. `mkcert -uninstall` آن را پاک میکند.
- اگر پشت یک پروکسی MITM شرکتی مینشینید، بپذیرید که پروکسی گواهیهای شما را تعویض میکند. اگر ابزار شما از آن پشتیبانی میکند، پروکسی را روی `127.0.0.1` غیرفعال کنید.
مرورگرها همچنین یک قانون ویژه دارند که ارزش دانستن دارد. طبق مشخصات W3C Secure Contexts، `http://127.0.0.1`، `http://localhost` و `http://[::1]` به عنوان "بالقوه قابل اعتماد" محسوب میشوند، که به یک صفحه HTTPS اجازه میدهد بدون ایجاد بلوک محتوای مختلط، آنها را دریافت کند. این تفکیک به طور خاص برای توسعهدهندگان محلی وجود دارد.
Localhost آنطور که توسعهدهندگان اغلب تصور میکنند، یک مرز امنیتی نیست. مرورگرها را میتوان از طریق DNS rebinding از وبسایتهای دلخواه فریب داد تا به آن دسترسی پیدا کنند، جایی که یک سایت مخرب نام میزبان خود را به 127.0.0.1 تغییر میدهد و به جاوا اسکریپت در صفحه مهاجم اجازه میدهد تا با سرویسهای محلی تحت مبدا سایت اصلی ارتباط برقرار کند. CVE زوم در سال 2019 (CVE-2019-13450) مورد اصلی است. زوم یک وب سرور پنهان را در `localhost:19421` در macOS نصب کرد تا لینکهای جلسه بتوانند برنامه دسکتاپ را اجرا کنند و هر وبسایتی میتواند از آن برای اتصال اجباری کاربر به جلسه با دوربین روشن استفاده کند. تقریباً 4 میلیون مک تحت تأثیر قرار گرفتند، به علاوه سیزده کلاینت با برچسب سفید که با همان موتور عرضه شدند. کروم 142 که در اواخر سال 2025 منتشر شد، تلاش قدیمیتر Private Network Access را با Local Network Access جایگزین کرد. صفحات عمومی اکنون قبل از رسیدن به آدرسهای loopback یا خصوصی، به یک درخواست مجوز صریح نیاز دارند که این امر اکثر ترفندهای Singularity خودکار گروه NCC را از بین میبرد. یک توصیهنامه Straiker در سال ۲۰۲۵، همین حمله را علیه سرورهای Model Context Protocol که به صورت محلی اجرا میشوند، مستند کرده است، که با اجرای عوامل LLM بیشتر توسط توسعهدهندگان در loopback، به یک سطح رو به رشد تبدیل شده است. کاملاً به ۱۲۷.۰.۰.۱ متصل شوید، به auth نیاز داشته باشید، هدر `Origin` را بررسی کنید و از wildcard CORS در APIهای توسعهدهندگان خودداری کنید. این چهار عادت، اکثر این موارد را به خود جلب میکنند.
نکات عیبیابی و یک چک لیست تشخیص سریع
وقتی 127.0.0.1:57573 از پاسخ دادن امتناع میکند، قبل از اینکه به جادوی عمیقتری شک کنید، این لیست کوتاه را مرور کنید.
۱. مطمئن شوید که سرور واقعاً در حال اجرا است. به ترمینالی که آن را اجرا کردهاید نگاه کنید. اگر از کار افتاده باشد، رد پشته (stack trace) همانجا قرار دارد.
۲. مطمئن شوید که به ۱۲۷.۰.۰.۱ محدود شده است، نه به ۰.۰.۰.۰ یا ::۱ به تنهایی. اکثر فریمورکها آدرس اتصال را در هنگام راهاندازی چاپ میکنند. خط را بخوانید.
۳. دستور `curl -v http://127.0.0.1:57573` را در همان shell امتحان کنید. Curl کار میکند؟ مشکل از مرورگر است، نه سرور.
۴. بفهمید چه کسی صاحب پورت است. لینوکس، `ss -tlnp | grep :57573`. مک، `lsof -i :57573`. ویندوز، `netstat -ano | findstr :57573`.
۵. آیا پردازش اشتباهی مسئول آن است؟ آن را متوقف کنید، سپس سرور خود را مجدداً راهاندازی کنید.
۶. اصلاً چیزی در حال گوش دادن نیست؟ به گزارش راهاندازی نگاه کنید. `EACCES` به معنی پورت ممتاز است. `EADDRINUSE` معمولاً به معنی TIME_WAIT قدیمی است.
۷. فرم IPv6 را امتحان کنید. `curl http://[::1]:57573`. اگر یکی از `127.0.0.1` یا `::1` کار کرد و دیگری کار نکرد، سرویس شما تک پشتهای است.
۸. یک پورت دیگر را امتحان کنید: `--port 12345` (یا هر مقدار دیگری) را وارد کنید و دوباره بارگذاری کنید. پورت جدید کار میکند؟ شما با یک تداخل خاص پورت مواجه هستید.
۹. VPN، آنتیویروس و عوامل endpoint را به مدت یک دقیقه غیرفعال کنید. اگر ۵۷۵۷۳ شروع به پاسخگویی کرد، یکی از آنها در حال مصرف ترافیک بوده است.
۱۰. راهاندازی مجدد، یا حداقل راهاندازی مجدد رابط شبکه. تقریباً هیچوقت جواب نمیدهد. وقتی هیچ چیز دیگری این کار را نمیکند، سوکتهای قدیمی و وضعیت فایروال را پاک میکند.
برای اکثر مشکلات توسعهدهندگان، آن چهار مرحله اول عیبیابی، علت خرابی اتصال را مشخص میکنند. بقیه موارد واقعاً عجیب را پوشش میدهند، جایی که عدم تطابق IPv6، سوکتهای قدیمی یا یک لایه فایروال خصمانه، خرابی واقعی را پنهان میکند. پیام خطا را بخوانید، سپس لیست را دنبال کنید.
یک نکته مرتبط با Plisio. وقتی وبهوکهای یک پردازنده پرداخت ارز دیجیتال را ادغام میکنید، درگاه به یک URL عمومی نیاز دارد که بتواند به آن POST کند. فاکتورهای Plisio یک `callback_url` را در API payload میپذیرند و سیستم بهروزرسانیهای وضعیت را به آن نقطه پایانی POST میکند. سرور محلی شما در 127.0.0.1:57573 طبق تعریف از طریق اینترنت عمومی قابل دسترسی نیست، بنابراین راهحل استاندارد یک تونل است. در سال 2026، گزینههای معمول عبارتند از ngrok (شخصی 8 دلار در ماه، حرفهای 20 دلار در ماه)، Cloudflare Tunnel (رایگان تا 50 کاربر در Zero Trust) و Tailscale Funnel (رایگان برای استفاده شخصی، تیمهای پولی از 6 دلار در ماه به بالا). هر کدام یک نام میزبان عمومی میگیرند و ترافیک را به 127.0.0.1:57573 لپتاپ شما هدایت میکنند. کیتهای توسعه نرمافزار پایتون، PHP و Node شرکت Plisio یک کمککنندهی `validate_callback` ارائه میدهند که `verify_hash` مربوط به HMAC-SHA1 را روی بدنهی JSON مرتبشده تأیید میکند، بنابراین پس از اتصال تونل، همان کنترلکننده در محیط توسعه و تولید بهطور یکسان کار میکند.
