AllowCONNECT آپاچی و پورت‌های مقصد HTTPS
پورتی که کلاینت‌ها برای رسیدن به پروکسی آپاچی استفاده می‌کنند را از پورت‌های مقصدی که mod_proxy_connect در تونل‌ها مجاز می‌کند، تشخیص دهید.
پروکسی آپاچی شما روی پورت 3128 گوش می‌دهد. یک کلاینت با موفقیت به آن می‌رسد، اما سرویس HTTPS روی پورت 8443 شکست می‌خورد. تغییر پورت شنود پروکسی به احتمال زیاد این تفاوت خاص را حل نمی‌کند.
کلاینت ابتدا به شنونده پروکسی متصل می‌شود. سپس درخواست CONNECT آن یک میزبان و پورت مقصد جداگانه را نام می‌برد. آپاچی می‌تواند اتصال اول را بپذیرد و عملیات دوم را رد کند.
AllowCONNECT را به‌عنوان خط‌مشی مقصد بخوانید
برای آپاچی 2.4، mod_proxy_connect درخواست‌های CONNECT ورودی را مدیریت می‌کند. دستورالعمل AllowCONNECT آن پورت‌های مقصد موجود برای این درخواست‌ها را کنترل می‌کند. مقدار پیش‌فرض مستند 443 و 563 است.
AllowCONNECT 443 8443این مثال همان دو پورت مقصد را انتخاب می‌کند. گزینش پیش‌فرض را جایگزین می‌کند؛ 8443 را اضافه نمی‌کند و در همان حال همه پورت‌های پیش‌فرض را بی‌صدا نگه نمی‌دارد. دستورالعمل را در پیکربندی سرور یا میزبان مجازی مربوطه به کار ببرید.
قواعد مجوزدهی کلاینت پروکسی را در جای خود نگه دارید. یک پورت مقصد مجاز چیزی درباره اینکه کدام کلاینت می‌تواند از سرویس استفاده کند نمی‌گوید و در صورت نیاز جایگزین محدودیت میزبان مقصد نیست.
مثال یک پروکسی معکوس به پرسش دیگری پاسخ می‌دهد
نتایج جست‌وجو برای آپاچی و HTTPS اغلب یک وب‌سایت عمومی را نشان می‌دهند که به یک بک‌اند ثابت هدایت می‌کند. آن پیکربندی نحوه درخواست مرورگر از یک پروکسی پیش‌رو برای باز کردن تونل CONNECT به یک وب‌سایت انتخاب‌شده نیست. کپی‌کردن دستورالعمل‌های مسیریابی آن می‌تواند مسئله اصلی پروکسی را دست‌نخورده بگذارد.
هنگام عیب‌یابی یک شکست، شنونده‌ای که کلاینت به آن رسید، مرجع CONNECT درخواستی و پاسخ پروکسی را ثبت کنید. اگر CONNECT موفق شود و TLS پس از آن شکست بخورد، مجوز پورت مقصد کار خود را انجام داده است. ادامه دهید با خطای TLS به‌جای گسترش مکرر AllowCONNECT.