SOCKS5 کنکشن کی ناکامی کے کوڈ پڑھیں
ہر SOCKS خرابی کو مردہ پراکسی سمجھنے سے پہلے معلوم کریں کہ SOCKS گفت و شنید، تصدیق یا منزل میں سے کون سا مرحلہ ناکام ہوا۔
SOCKS5 سرور TCP کنکشن قبول کر کے بھی منزل تک پہنچنے کی درخواست مسترد کر سکتا ہے۔ کون سا اینڈپوائنٹ ناکام ہوا یہ طے کرنے سے پہلے درست مرحلے کا جواب پڑھیں۔
سب سے پہلے طریقہ منتخب ہوتا ہے۔ صارف نام اور پاس ورڈ کی تصدیق منتخب ہو تو اس کا اپنا نتیجہ ہوتا ہے۔ اس کے بعد ہی سرور CONNECT یا کسی دوسرے SOCKS کمانڈ کا جواب دیتا ہے۔ ایک مرحلے کی بائٹ ویلیو کو دوسرے مرحلے کی جدول سے نہیں سمجھا جا سکتا۔
درخواست کے جوابات مختلف ناکامیاں الگ کرتے ہیں
| جواب کی قدر | SOCKS5 درخواست کے جواب میں مطلب |
|---|---|
| 0x01 | سرور کی عمومی ناکامی۔ |
| 0x02 | قواعد کا مجموعہ کنکشن کی اجازت نہیں دیتا۔ |
| 0x03 | نیٹ ورک تک رسائی نہیں۔ |
| 0x04 | ہوسٹ تک رسائی نہیں۔ |
| 0x05 | کنکشن مسترد۔ |
| 0x06 | TTL ختم ہو گیا۔ |
| 0x07 | کمانڈ کی معاونت نہیں۔ |
| 0x08 | پتے کی قسم کی معاونت نہیں۔ |
مثلاً درخواست کی سطح پر انکار SOCKS سروس تک پہنچنے کے بعد رپورٹ ہوتا ہے۔ یہ آپریٹنگ سسٹم کے اس سروس سے ابتدائی TCP کنکشن مسترد کرنے سے مختلف ہے۔
پتے کی قسم کی خرابی IPv4، IPv6 یا ہوسٹ نام کی نمائندگی سے متعلق ہو سکتی ہے۔ اس کا خودکار مطلب یہ نہیں کہ پورا اینڈپوائنٹ SOCKS5 کو سپورٹ نہیں کرتا۔ اسی طرح غیر معاون UDP کمانڈ الگ TCP CONNECT درخواست کے بارے میں قطعی نتیجہ نہیں دیتی۔
وہ سیاق جمع کریں جو کوڈ کو مفید بناتا ہے
غلطی کی رپورٹ لکھتے وقت نتیجے کے ساتھ پراکسی کا پتہ، کمانڈ، ہدف ہوسٹ اور پورٹ، پتوں کی فیملی، اور DNS موڈ محفوظ رکھیں۔ اگر آپ اینڈپوائنٹ چلاتے ہیں تو سرور کی پالیسی لاگز مفید ہیں۔ قواعد کا انکار متعلقہ اجازت جانچنے کی وجہ ہے، کنکشن ٹائم آؤٹ بڑھانے کی نہیں۔
جواب سرور کی رپورٹ ہے، ہدف نیٹ ورک کی مکمل آزاد تشخیص نہیں۔ کلائنٹس کے الفاظ بھی بدلتے ہیں۔ جب دستیاب ہوں تو مرحلہ اور بنیادی جواب درج کریں، صرف مختصر ترجمہ شدہ خطا پیغام پر انحصار نہ کریں۔