ඔබේ Apache ප්‍රොක්සිය 3128 වරායේ සවන් දෙයි. සේවාදායකයෙක් එයට සාර්ථකව ළඟා වේ, නමුත් 8443 වරායේ HTTPS සේවාව අසාර්ථක වේ. ප්‍රොක්සියේ සවන්දීමේ වරාය වෙනස් කිරීම එම වෙනස විසඳීමට ඉඩක් අඩුය.

සේවාදායකය මුලින්ම ප්‍රොක්සි ශ්‍රාවකයට සම්බන්ධ වේ. ඉන්පසු එහි CONNECT ඉල්ලීම වෙනම ගමනාන්ත සත්කාරකයක් සහ වරායක් නම් කරයි. Apache පළමු සම්බන්ධතාවය පිළිගෙන දෙවන ක්‍රියාව ප්‍රතික්ෂේප කළ හැකිය.

AllowCONNECT ගමනාන්ත ප්‍රතිපත්තියක් ලෙස කියවන්න

Apache 2.4 සඳහා, mod_proxy_connect එන CONNECT ඉල්ලීම් හසුරුවයි. එහි AllowCONNECT උපදෙස් එම ඉල්ලීම් සඳහා ලබා ගත හැකි ගමනාන්ත වරායන් පාලනය කරයි. ලේඛනගත පෙරනිමිය 443 සහ 563 වේ.

AllowCONNECT 443 8443

මෙම උදාහරණය එම ගමනාන්ත වරායන් දෙක තෝරයි. එය පෙරනිමි තේරීම වෙනුවට යයි; සියලු පෙරනිමි වරායන් නිශ්ශබ්දව තබා 8443 එකතු නොකරයි. අදාළ සේවාදායක හෝ අතථ්‍ය සත්කාරක වින්‍යාසයේ උපදෙස් භාවිත කරන්න.

ප්‍රොක්සියේ සේවාදායක අවසර නීති තිබිය යුතු ලෙසම තබන්න. අවසර ලත් ගමනාන්ත වරායක් කුමන සේවාදායකයට සේවාව භාවිත කළ හැකිද යන්න නොකියයි, එය අවශ්‍ය විට ගමනාන්ත සත්කාරක සීමාවක් සඳහා ආදේශකයක් නොවේ.

ප්‍රතිලෝම ප්‍රොක්සි උදාහරණයක් වෙනත් ප්‍රශ්නයකට පිළිතුරු දෙයි

Apache සහ HTTPS සඳහා සෙවුම් ප්‍රතිඵල බොහෝ විට ස්ථාවර backend එකකට යොමු කරන පොදු වෙබ් අඩවියක් පෙන්වයි. බ්‍රවුසරයක් තෝරාගත් වෙබ් අඩවියකට CONNECT උමං විවෘත කරන ලෙස ඉදිරි ප්‍රොක්සියකට කියන ආකාරය එම වින්‍යාසය නොවේ. එහි මාර්ගෝපදේශ උපදෙස් පිටපත් කිරීම මුල් ප්‍රොක්සි ගැටලුව ස්පර්ශ නොකර තැබිය හැකිය.

අසාර්ථකත්වයක් රෝග විනිශ්චය කරන විට, සේවාදායකය ළඟා වූ ශ්‍රාවකය, ඉල්ලා සිටි CONNECT අධිකාරිය සහ ප්‍රොක්සියේ පිළිතුර සටහන් කරන්න. CONNECT සාර්ථක වී පසුව TLS අසාර්ථක වුවහොත්, ගමනාන්ත වරාය අවසරය දැනටමත් තම කොටස ඉටු කර ඇත. AllowCONNECT නැවත නැවත පුළුල් කරනවාට වඩා TLS අසාර්ථකත්වය සමඟ ඉදිරියට යන්න.

අදාළ ලිපි