Apache AllowCONNECT dan Port Destinasi HTTPS

Proksi Apache anda mendengar pada port 3128. Klien berjaya mencapainya, tetapi perkhidmatan HTTPS pada port 8443 gagal. Mengubah port pendengaran proksi tidak mungkin menyelesaikan perbezaan itu.

Klien mula-mula bersambung ke pendengar proksi. Permintaan CONNECTnya kemudian menamakan hos dan port destinasi yang berasingan. Apache boleh menerima sambungan pertama dan menolak operasi kedua.

Baca AllowCONNECT sebagai dasar destinasi

Bagi Apache 2.4, mod_proxy_connect mengendalikan permintaan CONNECT yang masuk. Arahan AllowCONNECT mengawal port destinasi yang tersedia untuk permintaan tersebut. Lalai yang didokumenkan ialah 443 dan 563.

AllowCONNECT 443 8443

Contoh ini memilih kedua-dua port destinasi itu. Ia menggantikan pilihan lalai; ia tidak menambah 8443 sambil diam-diam mengekalkan setiap port lalai. Gunakan arahan dalam konfigurasi pelayan atau hos maya yang berkenaan.

Kekalkan peraturan kebenaran klien proksi di tempatnya. Port destinasi yang dibenarkan tidak menyatakan klien mana yang boleh menggunakan perkhidmatan, dan ia bukan pengganti sekatan hos destinasi apabila perlu.

Contoh proksi terbalik menjawab soalan yang berbeza

Hasil carian untuk Apache dan HTTPS sering menunjukkan laman web awam yang memajukan ke backend tetap. Konfigurasi itu bukan cara pelayar meminta proksi hadapan membuka terowong CONNECT ke laman web yang dipilih. Menyalin arah laluannya boleh membiarkan masalah proksi asal tidak tersentuh.

Semasa mendiagnosis kegagalan, catatkan pendengar yang dicapai klien, kuasa CONNECT yang dimintanya dan balasan proksi. Jika CONNECT berjaya dan TLS gagal selepas itu, kebenaran port destinasi sudah menjalankan peranannya. Teruskan dengan kegagalan TLS dan bukan meluaskan AllowCONNECT berulang kali.