પ્રોક્સી સાથે WRONG_VERSION_NUMBER: HTTP અને HTTPS તપાસો

ભૂલ કહે છે “ખોટી આવૃત્તિ”, તેથી TLS આવૃત્તિઓ બદલવાનું શરૂ કરવાનું મન થાય. પ્રોક્સી સાથે, પહેલીની એક શક્યતા તપાસો: શું ક્લાયન્ટે સાદા HTTPની રાહ જોતા પોર્ટ પર TLS હેન્ડશેક મોકલ્યો હતો?

https://example.com/ જેવું લક્ષ્ય અને http://proxy.example:8080 જેવી પ્રોક્સી સામાન્ય જોડ છે. બીજી URLને HTTPSમાં બદલવાથી ક્લાયન્ટને પ્રોક્સી સાથે જ પોતાની વાતચીત એન્ક્રિપ્ટ કરવાનું કહેવાય છે. તે HTTPS સાઇટ્સની પરવાનગી આપવાની સૂચના નથી.

પ્રથમ TLS વાતચીત શોધો

HTTP પ્રોક્સી સાથે, ક્લાયન્ટ પહેલાં CONNECT મોકલીને HTTP જવાબ મેળવી શકે છે. ત્યાર પછી જ ટનલની અંદર લક્ષ્યનું TLS શરૂ કરે છે. HTTPS પ્રોક્સી સાથે પહેલાં પ્રોક્સી સાથે અલગ TLS જોડાણ આવે છે.

HTTP ભૂલ પૃષ્ઠ કે બીજો સાદો ટેક્સ્ટ મળતાં TLS પાર્સર પ્રોટોકોલ ભૂલ જણાવી શકે છે. આ શબ્દરચના સાઇટ કઈ TLS આવૃત્તિઓને ટેકો આપે છે, અથવા સાઇટનો સંપર્ક થયો હતો કે નહીં, તે પણ સ્થાપિત કરતી નથી.

1. પ્રોક્સીની URL, તેની સ્કીમ સહિત, અને એન્ડપોઇન્ટનો દસ્તાવેજીકૃત પ્રોટોકોલ નોંધો.
2. નિષ્ફળતા CONNECT જવાબ પહેલાં, લક્ષ્યના TLS દરમિયાન, કે પ્રોક્સીના પોતાના પ્રમાણપત્રની ચકાસણી વખતે થઈ હતી તે શોધો.
3. જૂના ઉપાયની સરખામણી કરતી વખતે ક્લાયન્ટ અને નિર્ભરતાઓની વાસ્તવિક આવૃત્તિઓ તપાસો. અગાઉના પ્રોક્સી અમલીકરણો ક્યારેક સ્કીમને જુદી રીતે વાપરતા હતા.

કેટલાક સુધારા જુદાં જુદાં કારણોસર ખોટા હોઈ શકે. HTTP પ્રોક્સી સૂચિ આવા માર્ગે મંજૂર જાહેર વિનંતીઓ માટે સામાન્ય HTTP એન્ડપોઇન્ટ ઉમેદવારો આપે છે. સાદા HTTP એન્ડપોઇન્ટને HTTP પ્રોક્સી સ્કીમ જોઈએ; ખરેખર TLS-સક્ષમ એન્ડપોઇન્ટે HTTPS અને તેની પ્રમાણપત્ર ચકાસણી રાખવી જોઈએ. CONNECT નકારતી પ્રોક્સીને સમર્થિત સેવા કે નીતિ જોઈએ, લાઇબ્રેરીનું મનમાન્યું ડાઉનગ્રેડ નહીં.

પ્રથમ નિરીક્ષણક્ષમ નિષ્ફળતા રાખો. પ્રમાણપત્ર ચકાસણી બંધ કરવાથી ફક્ત HTTP બોલતું શ્રોતા TLS બોલતું થઈ શકતું નથી, અને જૂની સાઇફર નીતિ પસંદ કરવાથી સાઇટના હેન્ડશેક પહેલાં મોકલાયેલો HTTP ઇનકાર સમજાવી શકાતો નથી.