۱۲۷.۰.۰.۱:۶۲۸۹۳: عیبیابی خطاهای شبکه میزبان محلی
شما در حال اجرای یک اسکریپت Node.js هستید، با تب به Chrome DevTools برمیگردید و ناگهان یک بنر قرمز با این متن ظاهر میشود: «اتصال از ماشین مجازی هدف قطع شد، آدرس: 127.0.0.1:62893». دیباگر از کار افتاده است. نقاط توقف شما از بین رفتهاند. و رشتهای از اعداد که هرگز عمداً تایپ نکردهاید، به شما خیره شدهاند.
به یکی از رایجترین و در عین حال اشتباهترین رشتههای خطا در توسعه نرمافزار مدرن خوش آمدید. خبر خوب: این یک خطای مبهم نیست. این صرفاً دستگاه محلی شماست که سعی میکند از طریق یک شماره پورت خاص با خودش صحبت کند و چیزی این مکالمه را مسدود کرده است. اگر این انسداد را برطرف کنید، اشکالزدا برمیگردد.
این راهنما دقیقاً توضیح میدهد که 127.0.0.1:62893 چیست، آدرسی که به عنوان آدرس loopback شناخته میشود و با یک پورت موقت در رابط loopback جفت شده است، چرا توسعهدهندگان از آدرسهای localhost و پورتهای خاصی مانند این استفاده میکنند، محل واقعی خطا کجاست و راهحلهای گام به گام که در ویندوز، macOS و لینوکس کار میکنند را شرح میدهد. همه چیز در اینجا کاربردی است. در صورت تمایل، یک ترمینال باز کنید و مراحل را دنبال کنید.
معنی ۱۲۷.۰.۰.۱:۶۲۸۹۳: آدرس و پورت حلقهبک
نخ را از وسط نصف کن. معما حل شد.
نیمه اول، `127.0.0.1`. آدرس حلقه برگشت. هر کامپیوتری در جهان آن را دارد. یک بسته به آن هدف IPv4 ارسال کنید و سیستم عامل آن را مستقیماً از طریق پشته شبکه خود شما برمیگرداند. هیچ چیز هرگز دستگاه را ترک نمیکند. کل بلوک `127.0.0.0/8` (بیش از 16 میلیون آدرس) برای حلقه برگشت تحت RFC 6890 رزرو شده است. همان RFC بلوک "Forwardable: False" و "Global: False" را علامت گذاری میکند، که کمیته استانداردها به معنای "روترها باید آن را رها کنند" است. به غیر از خود 127.0.0.1، تقریباً هیچ کس به بقیه 16 میلیون دست نمیزند. حلقه برگشت در عمل یک عدد است. IPv6 آن را `::1` هجی میکند. نام میزبان برای هر دو `localhost` است.
نیمه دوم، `62893`. شماره پورت، نه بیشتر. پورتها به سیستم عامل میگویند که کدام فرآیند باید بخشی از ترافیک را دریافت کند. شماره 62893 در محدوده پویا/خصوصی IANA 49152-65535 قرار دارد که توسط RFC 6335 برای استفاده بر اساس تقاضا و کوتاه مدت تعریف شده است. هیچ چیز واقعاً مالک آن نیست. پورت 80؟ این متعلق به HTTP است. پورت 443؟ HTTPS. پورت 62893 متعلق به هر برنامهای است که در این لحظه از سیستم عامل درخواست پورت آزاد کرده است. نکته کوچک: محدوده موقت پیشفرض لینوکس در واقع 32768-60999 است. بنابراین وقتی 62893 در لینوکس ظاهر میشود، تقریباً مطمئناً یک برنامه آن را عمداً پین کرده است، نه اینکه هسته آن را توزیع کند.
هر دو نیمه را به هم بدوزید و ترجمه ساده انگلیسی آن این است: «یک فرآیند در حال اجرا روی رایانه شما در حال گوش دادن به پورت ۶۲۸۹۳ است.» بدون ابر. بدون اتصال به اینترنت. بدون جادو. `localhost` به خود میزبان محلی اشاره دارد. `۱۲۷.۰.۰.۱` نحوه نوشتن آن توسط سیستم در IPv4 است. این پورت برای ارتباط موقت بین فرآیندهایی که به صورت محلی روی دستگاه شما اجرا میشوند، استفاده میشود. این کل داستان است.
یک مقایسه سریع با نقاط پایانی شناختهشدهتر، به درک جایگاه ۶۲۸۹۳ کمک میکند:
| آدرس | نقش | چه کسی صاحب بندر است؟ |
|---|---|---|
| ۱۲۷.۰.۰.۱:۸۰ | وب سرور محلی HTTP (پیشفرض آپاچی) | پورت سیستم شناخته شده |
| ۱۲۷.۰.۰.۱:۴۴۳ | سرور محلی HTTPS | پورت سیستم شناخته شده |
| ۱۲۷.۰.۰.۱:۳۰۰۰ | سرورهای توسعه Node.js / React | ثبت نام شده (محدوده کاربری) |
| ۱۲۷.۰.۰.۱:۸۰۸۰ | Alt HTTP، Tomcat، بسیاری از ابزارهای توسعه | ثبت نام شده (محدوده کاربری) |
| ۱۲۷.۰.۰.۱:۶۲۸۹۳ | هر فرآیند تصادفی (اغلب Node Inspector) | پویا / زودگذر |
بنابراین وقتی در یک خطا عدد ۱۲۷.۰.۰.۱:۶۲۸۹۳ را میبینید، تقریباً همیشه به ابزاری نگاه میکنید که در زمان اجرا از سیستمعامل درخواست یک پورت موقت کرده و در این راهاندازی خاص، عدد ۶۲۸۹۳ را دریافت کرده است. در راهاندازی مجدد بعدی، ممکن است به جای آن ۵۸۲۳۴ باشد. آدرس IP 127.0.0.1 ثابت است؛ شماره پورت اساساً یک بلیط بختآزمایی است.
چرا توسعهدهندگان از Localhost و پورت ۶۲۸۹۳ استفاده میکنند؟
لوکالهست به این دلیل وجود دارد که شما نمیتوانید (و نباید) همیشه کد را فقط برای آزمایش روی یک سرور زنده مستقر کنید. در عوض، توسعهدهندگان از لوکالهست برای اجرای یک برنامه به صورت محلی و بدون هیچ وابستگی خارجی استفاده میکنند، تأیید میکنند که برنامه وب کار میکند، سپس آن را به یک شبکه گستردهتر منتقل میکنند. این گردش کار دهها سال قدمت دارد و هنوز هم تقریباً برای هر محیط توسعه محلی مدرن و تیم توسعه مرکزی است. امروزه اکثر محیطهای توسعه محلی به همین دلیل به طور پیشفرض از loopback استفاده میکنند: این یک ابزار قدرتمند برای کار محلی است که به شما امکان میدهد بدون نیاز به اینترنت به هر سرویسی دسترسی داشته باشید.
چهار چیز آدرس loopback را برای آزمایش و توسعه محلی جذاب میکند:
- ایزولهسازی. ترافیک روی دستگاه محلی شما، درون سیستم، بدون افشای چیزی به خارج باقی میماند. هیچ جهش شبکه خارجی، هیچ ISP، هیچ وضوح DNS، هیچ فایروالی بین مرورگر وب شما و سروری که تازه راهاندازی کردهاید، وجود ندارد.
- سرعت. پینگ گرفتن از خودتان سریعترین روش ممکن برای رفت و برگشت به شبکه است. برای بنچمارک خوب است، برای شبیهسازی تأخیر ترافیک شبکه در دنیای واقعی بد است، اما برای حلقههای توسعه فشرده ایدهآل است.
- امنیت. سرویسی که فقط به 127.0.0.1 محدود شده است، نمیتواند از طریق رایانه دیگری قابل دسترسی باشد یا اتصالات شبکه غیرمجاز از خارج دریافت کند. به همین دلیل است که بسیاری از اشکالزداها به طور پیشفرض از loopback استفاده میکنند. اگر قصد افشای سرویس را نداشته باشید، نامرئی میماند.
- آزادی پورت. از آنجا که هیچ کس در اینترنت عمومی نیازی به دسترسی به وب سرور محلی شما ندارد، میتوانید تقریباً به هر پورت آزادی متصل شوید. پورتهای ۳۰۰۰، ۸۰۸۰، ۵۱۷۳، ۸۰۰۰ و کل محدوده دینامیکی بدون کاغذبازی قابل استفاده هستند و به توسعهدهندگان این امکان را میدهند که برنامهها را بدون نیاز به یک برنامه میزبانی پولی، به صورت محلی آزمایش کنند.
پورت ۶۲۸۹۳ اغلب در یک سناریوی بسیار خاص ظاهر میشود: پروتکل Node.js Inspector که توسط Chrome DevTools، VS Code و JetBrains IDE برای اشکالزدایی جاوا اسکریپت استفاده میشود. راهنمای رسمی اشکالزدایی Node.js، inspector را به طور پیشفرض روی `۱۲۷.۰.۰.۱:۹۲۲۹` تنظیم کرده است. یک پورت تصادفی مانند ۶۲۸۹۳ فقط زمانی ظاهر میشود که `--inspect=0` (اختصاص داده شده توسط سیستم عامل، مستند شده در Node PR #53782 از سال ۲۰۲۴) را ارسال کنید یا زمانی که یک IDE مانند WebStorm/IntelliJ یک پورت موقت آزاد برای فرآیند فرزند جلسه اشکالزدایی انتخاب کند. نخهای پشتیبانی JetBrains رشته خطای دقیق شامل ۶۲۸۹۳، ۵۵۸۱۲، ۵۸۹۲۳ و سایر اعداد دامنه پویا را مستند میکنند که همگی درجا اختصاص داده میشوند و هیچ یک از آنها "تحت مالکیت" هیچ سرویسی نیستند.
طبق نظرسنجی توسعهدهندگان Stack Overflow در سال ۲۰۲۵، جاوا اسکریپت با ۶۶٪ همچنان پرکاربردترین زبان است و ۴۵٪ از توسعهدهندگان، اشکالزدایی را از بزرگترین ناامیدیهای خود ذکر میکنند. JetBrains در نظرسنجی «وضعیت اکوسیستم توسعهدهندگان ۲۰۲۵» از ۲۴۵۳۴ توسعهدهنده در ۱۹۴ کشور، یافتههای مشابهی را گزارش کرد. به عبارت دیگر: بسیاری از مردم هر روز تعداد زیادی پورت loopback تصادفی را به هم متصل میکنند. هیچ چیز در مورد این موضوع غیرمعمول نیست. چیزی که غیرمعمول است، برخورد با خطا و ندانستن دلیل آن است.
نحوه عملکرد ۱۲۷.۰.۰.۱ و پورت ۶۲۸۹۳ در توسعه نرمافزار
در باطن، یک اتصال loopback سه بخش متحرک دارد. برنامه از سیستم عامل میخواهد که یک سوکت روی 127.0.0.1:62893 باز کند تا بتواند دادهها را با خودش ارسال و دریافت کند. پشته TCP/IP سیستم عامل، پورت را به عنوان "در حال استفاده" توسط آن فرآیند یا سرویس خاص علامتگذاری میکند. و هنگامی که هر برنامه محلی دیگری روی دستگاه (مرورگر، اشکالزدا، curl) سعی میکند به 127.0.0.1:62893 متصل شود، سیستم عامل بستهها را به صورت داخلی به هر کسی که از قبل پورت را باز کرده است، هدایت میکند. شبکه خارجی هرگز در هیچ مرحلهای درگیر نمیشود. دقیقاً به همین دلیل است که loopback معمولاً برای آزمایش و اشکالزدایی در یک محیط کنترلشده روی سیستم محلی شما استفاده میشود.
یک مثال ساده Node.js موضوع را ملموس میکند. قطعه کد زیر یک وب سرور محلی کوچک را که به رابط loopback متصل است، راهاندازی میکند. وب سرورها معمولاً در محیط عملیاتی از پورت ۸۰ یا ۴۴۳ استفاده میکنند، اما برای یک سرور محلی که در آزمایشهای شبکه استفاده میشود، هر پورتی بالاتر از ۱۰۲۴ قابل قبول است. در اینجا نحوهی عملکرد یک وب سرور برای گوش دادن به ۶۲۸۹۳ در کد آمده است:
جاوا اسکریپت
const http = نیاز ('http')؛
const server = http.createServer((req, res) => {
res.end('Hello from 127.0.0.1');
});
server.listen(62893, '127.0.0.1', () => {
console.log('Server running at http://127.0.0.1:62893');
});
```
این را با `node server.js` اجرا کنید. `http://127.0.0.1:62893` را در مرورگر باز کنید و پاسخ را دریافت خواهید کرد. مرورگر را ببندید و سرور به کار خود ادامه میدهد. فرآیند Node را متوقف کنید، پورت آزاد میشود و هر شنوندهای که آن آدرس را تماشا میکند، قطع میشود. این الگو، ستون فقرات این است که چگونه توسعهدهندگان میتوانند یک برنامه وب محلی مفید برای آزمایش APIها، فرآیندها یا سرویسهای خاص و حتی کل پشتههای میکروسرویسها را بدون نیاز به هیچ میزبانی پولی یا خدمات شبکه خارجی و بدون نیاز به خرید حتی یک بایت محاسبات ابری اجرا کنند.
روند کار Chrome/Node Inspector مشابه است اما خودکارتر. اجرای `node --inspect=0 script.js` چیزی شبیه به این را چاپ میکند:
```
دیباگر در حال گوش دادن به ws://127.0.0.1:62893/166e272e-7a30-4d09-97ce-f1c012b43c34
```
آن URL یک نقطه پایانی WebSocket در آدرس 127.0.0.1:62893 است. DevTools با باز کردن `chrome://inspect`، اضافه کردن پورت به لیست اکتشاف و کلیک روی "باز کردن DevTools اختصاصی برای Node" به آن متصل میشود. در پشت صحنه، DevTools از `/json/version` و `/json/list` روی HTTP در آن پورت نظرسنجی میکند، سپس یک WebSocket را که پروتکل Chrome DevTools (دامنه v8-inspector) را بیان میکند، باز میکند. لحظهای که فرآیند Node خارج میشود، WebSocket بسته میشود و IDE بنر استاندارد را نشان میدهد: "از ماشین مجازی هدف جدا شد، آدرس: '127.0.0.1:62893'، transport: 'socket'." آن رشته، `transport: 'socket'` و همه اینها، دقیقاً همان چیزی است که IDE های JetBrains نیز چاپ میکنند. این بنر یک اشکال نیست. این اشکالزدا است که به درستی گزارش میدهد که فرآیند هدف از بین رفته است.
خطاهای رایج در پورت ۶۲۸۹۳ و نحوه اشکالزدایی آنها
تقریباً هر مشکلی که در اطراف 127.0.0.1:62893 مشاهده خواهید کرد، در شش دسته قرار میگیرد. علامت خود را با یکی از این موارد مطابقت دهید، سپس راه حل را اعمال کنید.
- ارتباط با ماشین مجازی هدف قطع شده است. اشکالزدا (معمولاً یک فرآیند Node) از کار افتاده، خارج شده، مجدداً راهاندازی شده یا از کار افتاده است. پورت هم از بین رفته است.
- اتصال رد شد. هیچکس به آدرس 127.0.0.1:62893 گوش نمیدهد. سرویس هرگز شروع نشده، روی پورت دیگری شروع شده یا قبلاً خاموش شده است.
- آدرس قبلاً در حال استفاده است، یا `EADDRINUSE`. دو فرآیند سعی کردند یک پورت را بگیرند. حالت کلاسیک زمانی است که یک سرور توسعهدهنده پس از خرابی، پورت را به طور کامل آزاد نمیکند.
- مهلت. درخواست شما به پورت رسید، اما فرآیند هرگز به موقع پاسخ نداد. معمولاً یک حلقه بینهایت یا یک حلقه رویداد مسدود شده درون اشکالزدا.
- ۴۰۳ ممنوع یا دسترسی رد شد. مجوزهای مربوط به سوکت، پیکربندی سرور یا فایلهای پشتیبان، درخواست را مسدود میکنند.
- تداخل فایروال یا آنتی ویروس. برخی از نرمافزارهای امنیتی نیز ترافیک loopback را بررسی میکنند. این اتفاق به ندرت رخ میدهد.
تشخیص سریع پنج مرحلهای که تقریباً برای هر یک از این موارد کار میکند:
۱. مطمئن شوید که سرویس واقعاً در حال اجرا است. آیا فرآیند Node، Python یا Apache شما واقعاً شروع شده و فعال مانده است؟ به ترمینالی که آن را از آن اجرا کردهاید نگاه کنید.
۲. شماره پورت را بررسی کنید. آیا سرویس واقعاً روی ۶۲۸۹۳ در حال گوش دادن است، یا ۳۰۰۰ یا ۸۰۸۰ را انتخاب کرده و شما شماره اشتباهی را دنبال میکنید؟
۳. مطمئن شوید که هیچ چیز دیگری روی پورت قرار ندارد. یک فراخوانی `netstat` یا `lsof` به این مشکل پاسخ میدهد.
۴. پیکربندی را تأیید کنید. اگر از یک چارچوب استفاده میکنید، پورت در `package.json`، `.env`، `launch.json` یا فایل پیکربندی معادل آن قرار دارد.
۵. مطمئن شوید که فایروال به طور ناگهانی، به خصوص پس از بهروزرسانی اخیر سیستم عامل، تداخل ایجاد نمیکند.
اگر متن خطا به طور خاص «قطع ارتباط با ماشین مجازی هدف، آدرس: 127.0.0.1:62893» باشد، علت اصلی تقریباً همیشه از کار افتادن یک هدف Node inspector است. فرآیند Node را با دستور `node --inspect` مجدداً راهاندازی کنید تا DevTools دوباره متصل شود.
رفع مشکلات گام به گام برای 127.0.0.1:62893
در اینجا یک مسیر مشخص برای عیبیابی خطاهای رایج ارائه شده است. از بالا به پایین کار کنید تا خطا برطرف شود.
مرحله ۱. سرور یا سرویس را مجدداً راهاندازی کنید. سادهترین و رایجترین راه حل، هر بار. فرآیند Node، Apache، سرور توسعه پایتون یا هر چیز دیگری که به پورت متصل بوده است را متوقف کنید و دوباره آن را راهاندازی کنید. یک سرویس که به طور خاموش از کار افتاده است، میتواند پورت را تا زمانی که والد از بین برود، یتیم بگذارد. اکثر سرویسهای شبکه در شروع بعدی به طور کامل دوباره متصل میشوند.
مرحله ۲. تداخل پورت را بررسی کنید. فرآیند دیگری که روی ۶۲۸۹۳ قرار دارد، مانع از اتصال برنامه شما میشود. با ابزارهایی که در بخش بعدی پوشش داده شده است، تداخل را شکار کنید. آن را متوقف کنید یا برنامه خود را برای استفاده از پورت دیگری پیکربندی کنید (مرحله ۴).
مرحله ۳. بررسی قوانین فایروال. در ویندوز، فایروال Windows Defender را باز کنید و به دنبال قوانین خروجی که پورت را مسدود میکنند، بگردید. loopback به طور پیشفرض مجاز است، مگر اینکه سیاست پایه "all outbound blocked" اعمال شده باشد. در macOS، `/etc/pf.conf` پیشفرض PF شامل `set skip on lo0` است، بنابراین ترافیک localhost هرگز فیلتر نمیشود، اگر در loopback با "connection reject" مواجه هستید، تقریباً مطمئناً مشکل از فایروال نیست. در لینوکس، قانون استاندارد `iptables -A INPUT -i lo -j ACCEPT` معمولاً برقرار است. برای تأیید، `sudo iptables -L` یا `sudo ufw status` را اجرا کنید. اکثر پیکربندیهای پیشفرض فایروال به طور پیشفرض اجازه ترافیک loopback را میدهند، اما نرمافزار امنیتی نصب شده بعداً میتواند آن را تغییر دهد.
مرحله ۴. به یک پورت صریح متصل شوید. اگر ۶۲۸۹۳ مرتباً دزدیده میشود، به ابزار خود بگویید که از پورتی استفاده کند که هیچ چیز دیگری به آن دست نزند. برای بازرس Node، `node --inspect=127.0.0.1:9229 script.js` پورت را روی ۹۲۲۹ (پیشفرض مستند) پین میکند. توجه: Node.js اگر ۹۲۲۹ مشغول باشد، به طور خودکار به پورت دیگری نمیرود، شماره GitHub #28457 سالهاست که باز است و دقیقاً همین را درخواست میکند. شما یا فرآیند متضاد را از بین میبرید یا یک پورت صریح متفاوت ارسال میکنید. برای برنامههای Express/Node، `PORT=3001` را در محیط یا فایل پیکربندی خود تنظیم کنید.
مرحله ۵. تطبیق پیکربندیها. هر زنجیره خطا حداقل یک عدم تطابق پیکربندی پنهان در خود دارد. بررسی کنید که کلاینت شما (DevTools، curl، Postman) به همان پورتی که سرور واقعاً باز کرده است اشاره میکند. کپی-پیست بهتر از تایپ کردن است.
مرحله ۶. فقط در صورت لزوم، قوانین فایروال را بهروزرسانی کنید. اضافه کردن یک استثنای ورودی برای ۶۲۸۹۳ در loopback تقریباً هرگز لازم نیست زیرا ترافیک loopback از مسیر فایروال خارجی عبور نمیکند. اگر ابزار پیکربندی پرسید، محدوده «شبکه خصوصی» را انتخاب کنید، هرگز «عمومی» را انتخاب نکنید.
مرحله ۷. گزارشهای سرویس را بررسی کنید. Node، Apache، Nginx و هر پایگاه دادهای هنگام عدم موفقیت اتصال، پیامهای گزارش واضحی مینویسند. "EADDRINUSE 127.0.0.1:62893" بدون ابهام است: پورت اشغال شده است. قبل از حدس زدن، این گزارشها را بررسی کنید.
مرحله ۸. تغییرات اخیر را به حالت اولیه برگردانید. اگر هیچ چیز دیگری کار نکرد و خطا از امروز شروع شده است، به آخرین پیکربندی یا کد کامیت شدهی خوبِ شناخته شده برگردید. یک تنظیم پروکسی نادرست در `.env` یا یک `HOST=0.0.0.0` ناخواسته میتواند بیسروصدا اتصال را معکوس کند.
مرحله ۹. در صورت گیر کردن، درخواست پشتیبانی کنید. به مستندات پروژه، یک تاپیک Stack Overflow با خطای دقیق خود یا یک مدیر شبکه واجد شرایط در سازمان خود مراجعه کنید. پیام خطای دقیق و خروجی `lsof -i :62893` را جایگذاری کنید. سوالات خاص، پاسخهای خاص دریافت میکنند.
ابزارهایی برای بررسی شماره پورت ۶۲۸۹۳ در شبکه محلی
راستش را بخواهید، شما فقط به سه ابزار نیاز دارید تا تقریباً هر سوال مربوط به پورت را در یک جعبه توسعه پوشش دهید. وقتی این ابزارها را پیدا کنید، اساساً دیگر هرگز به سراغ چیز دیگری نخواهید رفت.
اول، netstat. مدتهاست که وجود دارد. تمام آدرسها و پورتهای متصل را فهرست میکند و وضعیت اتصال را نمایش میدهد. ویندوز، macOS، لینوکس، همه آن را دارند.
- ویندوز: `netstat -ano | findstr :62893`
- لینوکس و macOS: `netstat -an | grep 62893`
در ویندوز، پرچمهای `-ano` جادوی ماجرا هستند. شما PID فرآیند مالک را در کنار پورت، در کنار وضعیت (LISTENING، ESTABLISHED، TIME_WAIT) دریافت میکنید. یک خط خروجی. اکثر سوالات "آیا چیزی در حال گوش دادن است؟" در یک ثانیه پاسخ داده میشوند.
دوم، lsof. مخفف عبارت "لیست فایلهای باز". دستور کلاسیک در سیستمهای شبه یونیکس. تا روزی که واقعاً به آن نیاز پیدا نکنید، بیش از حد به نظر میرسد. در یونیکس، به یاد داشته باشید، همه چیز یک فایل است. سوکتها نیز شامل آن میشوند.
- macOS یا لینوکس: `sudo lsof -i :62893`
- هر پورتی که یک فرآیند خاص باز کرده است: `sudo lsof -p`
خروجی: نام دستور، PID، کاربر و جفت آدرس/پورت. همه در یک عکس. نوشتن یک اتوماسیون؟ نتیجه را از طریق `awk '{print $2}'` لولهکشی کنید تا فقط PIDها حذف شوند.
سوم، ss. جایگزین مدرن netstat در لینوکس. در میزبانهای شلوغ بسیار سریعتر:
- همه شنوندههای روی پورت: `ss -tlnp | grep 62893`
دو ابزار دیگر برای تکمیل کار. هیچکدام جایگزین سه ابزار بالا نمیشوند. هر کدام شکاف متفاوتی را پر میکنند.
curl بررسی اتصال سریع شماست. دستور `curl -v http://127.0.0.1:62893` را اجرا کنید. خواهید دید که TCP handshake و هر هدر پاسخ به صورت زنده پیمایش میشوند. "اتصال رد شد"؟ هیچ شنودی انجام نشد، انجام شد. "200 OK" با بدنه؟ پشته TCP سالم است، بنابراین اشکال واقعی شما در کد برنامه بالاتر است.
telnet بررسی خام TCP را انجام میدهد: `telnet 127.0.0.1 62893`. در سال 2026 نادرتر است زیرا دستگاههای جدید دیگر آن را ارائه نمیدهند. اگر هنوز آن را دارید، سادهترین تست اتصالی است که تاکنون انجام شده است. در غیر این صورت، `nc -zv 127.0.0.1 62893` با netcat تقریباً روی هر دستگاهی بدون هیچ تنظیماتی همین کار را انجام میدهد.
| ابزار | بهترین برای | مثال | |
|---|---|---|---|
| نتاستات | بررسی سریع پورتهای در حال شنود | دستور netstat -ano | یافتن رشته: 62893` |
| lsof | پیدا کردن PID پشت یک پورت | `sudo lsof -i :62893` | |
| اس اس | جایگزین مدرن و سریع (لینوکس) | دستور `ss -tlnp` | دستور grep 62893 |
| حلقه زدن | تأیید پاسخ HTTP به صورت محلی | `curl -v http://127.0.0.1:62893` | |
| ان سی / تل نت | کاوشگر TCP خام | `nc -zv 127.0.0.1 62893` |
پس از شناسایی یک فرآیند گیر کرده، آن را متوقف کنید. در ویندوز: `taskkill /PID /F`. در لینوکس/مک: `kill -9`. هر دو بلافاصله پورت را آزاد میکنند. مدیران شبکه در دستگاههای توسعه مشترک اغلب این را در یک اسکریپت تکخطی قرار میدهند تا بدون دسترسیهای بالا برای فرآیندهای خود توسعهدهنده اجرا شود.
خطرات امنیتی: پورت لوکال هاست را در معرض دسترسی قرار ندهید
Loopback از نظر طراحی خصوصی است. یک سرویس را فقط به 127.0.0.1 متصل کنید و از رایانه خودتان قابل دسترسی است. نه هیچ جای دیگر. همین ویژگی ساده دلیل اصلی است که توسعهدهندگان به طور پیشفرض برای نسخههای آزمایشی و محیطهای توسعه محدود از loopback استفاده میکنند. سرویسهای شبکه آزمایشی از شبکه گستردهتر دور میمانند. برنامه همچنان از داخل دستگاه کاملاً قابل دسترسی است.
اوضاع وقتی خراب میشود که کسی در یک فایل پیکربندی به طور تصادفی `127.0.0.1` را با `0.0.0.0` عوض کند. `0.0.0.0` به چه معناست؟ "به هر رابط شبکه متصل شوید." ترجمه عملی: سرویس شما اکنون از هر دستگاهی روی همان Wi-Fi و به طور بالقوه از اینترنت عمومی در صورتی که روتر یا فایروال پورت را نیز ارسال کند، قابل دسترسی است. مستندات Node.js این را به زبان ساده بیان میکند. بازرس را به یک رابط عمومی متصل کنید و "هر کلاینتی که بتواند به آدرس IP شما دسترسی پیدا کند، میتواند بدون هیچ محدودیتی به اشکالزدا متصل شود و قادر به اجرای کد دلخواه خواهد بود." اغراق نیست. خطر واقعی است.
تاریخچه اخیر پر سر و صدا است. در سال ۲۰۲۴، شرکت Oligo Security آسیبپذیری "روز ۰.۰.۰.۰" را افشا کرد، یک اشکال در سطح مرورگر که در برخی موارد درخواستهای وب را به `۰.۰.۰.۰` هدایت میکرد و به سرویسهایی که فقط برای میزبان محلی در نظر گرفته شده بودند، میرسید. کروم، سافاری و فایرفاکس همگی در اواسط سال ۲۰۲۴ اصلاحاتی را ارائه کردند. به فوریه ۲۰۱۸ برگردیم، مقیاس هنوز هم بزرگتر میشود. حمله تقویت Memcached (CVE-2018-1000115) از جعبههای Memcached که در معرض دید عموم قرار داشتند، روی UDP 11211 سوءاستفاده کرد تا ضریب تقویتی تا ۵۱۲۰۰ برابر ایجاد کند. این حمله منجر به حمله DDoS با سرعت ۱.۳ ترابیت بر ثانیه علیه GitHub در ۲۸ فوریه ۲۰۱۸ شد که هنوز هم یکی از بزرگترین حملات ثبت شده تاکنون است. رفع اشکال؟ Memcached به طور پیشفرض از نسخه ۱.۵.۶ UDP را غیرفعال کرد.
سه قانون کاربردی، سرویسهای فقط میزبان محلی را خصوصی نگه میدارند:
- پیوندهای توسعه را به صراحت روی ۱۲۷.۰.۰.۱ نگه دارید. در پیکربندی بنویسید «۱۲۷.۰.۰.۱» یا «localhost». هرگز «۰.۰.۰.۰» را وارد نکنید. هرگز IP شبکه محلی دستگاه را وارد نکنید.
- برای آزمایش به دسترسی از راه دور نیاز دارید؟ از تونلهای SSH (`ssh -L 9229:127.0.0.1:62893 user@host`) استفاده کنید، نه از یک اتصال عمومی خام. یک تونل به شما امکان میدهد از راه دور به سرویس دسترسی پیدا کنید در حالی که خود سرویس فقط به صورت loopback باقی میماند.
- هرگز یک رابط اشکالزدا یا مدیر را روی رابط عمومی سرور عملیاتی اجرا نکنید. اکثر نقضهای سرویسهای داخلی دقیقاً به همین اشتباه برمیگردند.
گزارشهای حوادث صنعتی مکرراً پورتهای توسعهای که به طور نامناسب در معرض دید قرار گرفتهاند را به عنوان سهم قابل توجهی از نقضهای داخلی نشان میدهند. درصد دقیق هر سال تغییر میکند، اما الگو ثابت است. یک اشکالزدا، پنل مدیریت یا API آزمایشی که به رابط کاربری اشتباه متصل شده است، یک مسیر حمله رایج است. با اتصالات پورت توسعه خود با همان دقتی که برای پیکربندی محصول انجام میدهید، رفتار کنید.
