Vaše proxy Apache naslouchá na portu 3128. Klient se k němu úspěšně připojí, ale služba HTTPS na portu 8443 selhává. Změna naslouchacího portu proxy pravděpodobně tento konkrétní rozdíl nevyřeší.

Klient se nejprve připojí k naslouchajícímu proxy. Jeho požadavek CONNECT pak uvádí samostatný cílový hostitel a port. Apache může první spojení přijmout a druhou operaci odmítnout.

Čtěte AllowCONNECT jako cílovou politiku

Pro Apache 2.4 zpracovává mod_proxy_connect příchozí požadavky CONNECT. Jeho direktiva AllowCONNECT řídí cílové porty dostupné pro tyto požadavky. Dokumentovaná výchozí hodnota je 443 a 563.

AllowCONNECT 443 8443

Tento příklad vybírá tyto dva cílové porty. Nahrazuje výchozí výběr; nepřidává 8443 a zároveň tiše nezachovává všechny výchozí porty. Použijte direktivu v příslušné konfiguraci serveru nebo virtuálního hostitele.

Ponechte pravidla autorizace klientů proxy na místě. Povolený cílový port nic neříká o tom, který klient smí službu používat, a nenahrazuje omezení cílového hostitele, když je potřeba.

Příklad reverzní proxy odpovídá na jinou otázku

Výsledky hledání pro Apache a HTTPS často ukazují veřejný web přesměrovávající na pevný backend. Tato konfigurace není způsob, jakým prohlížeč žádá dopřednou proxy o otevření tunelu CONNECT k vybranému webu. Kopírování jejích směrovacích direktiv může původní problém proxy ponechat nedotčený.

Při diagnostice selhání zaznamenejte naslouchající bod, ke kterému se klient dostal, požadovanou autoritu CONNECT a odpověď proxy. Pokud CONNECT uspěje a TLS poté selže, oprávnění cílového portu už svou část splnilo. Pokračujte selháním TLS místo opakovaného rozšiřování AllowCONNECT.

Související články