خواندن کدهای شکست اتصال SOCKS5
پیش از اینکه هر خطای SOCKS را پراکسی ازکارافتاده بدانید، مشخص کنید مذاکره، احراز هویت یا دسترسی به مقصد شکست خورده است.
سرور SOCKS5 می‌تواند اتصال TCP را بپذیرد اما درخواست دسترسی به مقصد را رد کند. پیش از تشخیص نقطهٔ خراب، پاسخ را در مرحلهٔ درست بخوانید.
ابتدا روش انتخاب می‌شود. احراز هویت نام کاربری و گذرواژه، اگر انتخاب شود، نتیجهٔ خودش را دارد. تنها پس از آن سرور پاسخ CONNECT یا فرمان SOCKS دیگری را می‌دهد. مقدار بایت یک مرحله را نمی‌توان با جدول مرحلهٔ دیگر تفسیر کرد.
پاسخ درخواست‌ها شکست‌های متفاوت را مشخص می‌کند
| مقدار پاسخ | معنا در پاسخ درخواست SOCKS5 |
|---|---|
| 0x01 | شکست عمومی سرور. |
| 0x02 | اتصال در مجموعهٔ قواعد مجاز نیست. |
| 0x03 | شبکه دسترس‌ناپذیر است. |
| 0x04 | میزبان دسترس‌ناپذیر است. |
| 0x05 | اتصال رد شد. |
| 0x06 | TTL منقضی شد. |
| 0x07 | فرمان پشتیبانی نمی‌شود. |
| 0x08 | نوع نشانی پشتیبانی نمی‌شود. |
برای نمونه، رد در سطح درخواست پس از رسیدن به سرویس SOCKS گزارش می‌شود. این با رد اتصال TCP اولیه به آن سرویس توسط سیستم‌عامل فرق دارد.
خطای نوع نشانی می‌تواند به نمایش IPv4، IPv6 یا نام میزبان مربوط باشد. این خودبه‌خود به معنی نبود پشتیبانی SOCKS5 در کل نقطه نیست. همچنین فرمان UDP پشتیبانی‌نشده نتیجهٔ قطعی دربارهٔ درخواست جداگانهٔ TCP CONNECT نمی‌دهد.
زمینه‌ای را جمع کنید که کد را مفید می‌کند
هنگام نوشتن گزارش خطا، نشانی پراکسی، فرمان، میزبان و پورت هدف، خانوادهٔ نشانی و حالت DNS را همراه نتیجه نگه دارید. اگر نقطه را مدیریت می‌کنید، لاگ سیاست‌های سرور مفید است. رد ناشی از قواعد دلیل بررسی مجوز مربوط است، نه افزایش مهلت اتصال.
پاسخ گزارش سرور است، نه تشخیص مستقل کامل شبکهٔ مقصد. واژگان کلاینت‌ها هم فرق می‌کند. در صورت دسترسی، مرحله و پاسخ زیرین را ثبت کنید و تنها به پیام کوتاه ترجمه‌شدهٔ خطا متکی نباشید.