Windows को portproxy नियमले TCP लाई एउटा कन्फिगर गरिएको गन्तव्यमा रिले गर्छ। यसले ब्राउजरको HTTP प्रोक्सी अनुरोध वा SOCKS गन्तव्य अनुरोधमा वार्तालाप गर्दैन।

सेवागन्तव्य कसले छान्छ?
स्थिर TCP रिलेसुन्नेको फर्वार्डिङ कन्फिगरेसन।
SOCKS5 प्रोक्सीग्राहकको अनुरोध, सर्भर नीतिभित्र।
HTTP फर्वार्ड प्रोक्सीHTTP प्रोक्सी अनुरोध, सामान्य HTTPS टनेलिङका लागि CONNECT सहित।

netsh interface portproxy show all सँग विद्यमान रिले निरीक्षण गर्नुहोस्। यसको कन्फिगर गरिएको ब्याकएन्डलाई तपाईंको ग्राहकले पठाउने प्रोटोकलसँग तुलना गर्नुहोस्। netsh सन्दर्भ ले सुन्ने र गन्तव्यको ठेगाना/पोर्ट वर्णन गर्छ; TCP स्वीकार गर्नु HTTP वा SOCKS ह्यान्डशेक स्थापना गर्दैन।

साधारण रिलेमा पठाइएको SOCKS वार्तालाप त्यो स्थिर ब्याकएन्डसम्म पुग्छ मात्र। यसले SOCKS नभएको सेवालाई अनुरोध बुझ्न वा नयाँ लक्ष्य छान्न बाध्य पार्न सक्दैन।

साँचो प्रोक्सीअगाडिको रिले फरक हुन्छ। अपस्ट्रिम प्रोक्सीले अझै गन्तव्य र प्रमाणीकरणमा वार्तालाप गर्छ; रिलेले जडान त्यहाँसम्म बोक्छ। सञ्जालमा खुला रिलेले त्यो ब्याकएन्डमा पहुँच विस्तार गर्न सक्छ, त्यसैले सुन्नेको पहुँच सीमा जानाजान राख्नुहोस्।

आवश्यकता सामान्य HTTP वा SOCKS निकास भएमा प्रोटोकल-सक्षम सेवा छान्नुहोस्। फर्वार्ड गरिएको पोर्ट त्यो बाटोको एउटा भाग मात्र हो।

सम्बन्धित लेखहरू