Apache AllowCONNECT och HTTPS-destinationsportar

Din Apache-proxy lyssnar på port 3128. En klient når den, men en HTTPS-tjänst på port 8443 misslyckas. Att ändra proxyns lyssnarport löser knappast just den skillnaden.

Klienten ansluter först till proxyns lyssnare. Dess CONNECT-begäran anger sedan en separat destinationsvärd och -port. Apache kan acceptera den första anslutningen och avvisa den andra åtgärden.

Läs AllowCONNECT som en destinationspolicy

För Apache 2.4 hanterar mod_proxy_connect inkommande CONNECT-begäranden. Direktivet AllowCONNECT styr de destinationsportar som är tillgängliga för dessa begäranden. Det dokumenterade standardvärdet är 443 och 563.

AllowCONNECT 443 8443

Det här exemplet väljer dessa två destinationsportar. Det ersätter standardurvalet; det lägger inte till 8443 medan alla standardportar behålls i tysthet. Använd direktivet i den aktuella server- eller virtual host-konfigurationen.

Behåll proxyns klientauktoriseringsregler på plats. En tillåten destinationsport säger inget om vilken klient som får använda tjänsten, och den ersätter inte en begränsning av destinationsvärden när en sådan behövs.

Ett omvänt proxy-exempel svarar på en annan fråga

Sökresultat för Apache och HTTPS visar ofta en offentlig webbplats som vidarebefordrar till en fast backend. Den konfigurationen är inte hur en webbläsare ber en forward-proxy öppna en CONNECT-tunnel till en vald webbplats. Att kopiera dess routingdirektiv kan lämna det ursprungliga proxyproblemet orört.

När du diagnostiserar ett fel, notera lyssnaren klienten nådde, den CONNECT-auktoritet den begärde och proxyns svar. Om CONNECT lyckas och TLS misslyckas efteråt har destinationsportstillståndet redan gjort sitt. Fortsätt med TLS-felet i stället för att gång på gång vidga AllowCONNECT.