تغییر مسیر درخواست‌های HTTP انتخاب‌شده از Squid به HTTPS
برای سایت‌های شناخته‌شده‌ای که از HTTPS پشتیبانی می‌کنند، یک تغییر مسیر سمت کلاینت برگردانید، به‌جای تغییر بی‌صدا همه URLهای مبدأ HTTP یا فرض اینکه پروکسی می‌تواند پشتیبانی TLS را در مبدأ ایجاد کند.
Squid می‌تواند از مرورگر بخواهد یک URL انتخاب‌شده HTTP را از طریق HTTPS دوباره امتحان کند. مقصد باید از پیش منبع مربوط را از طریق HTTPS ارائه دهد؛ اجرای Squid روی Raspberry Pi آن توانایی را در وب‌سایت ایجاد نمی‌کند.
برای رابط url_rewrite_program در Squid 7، یک helper می‌تواند تغییر مسیر سمت کلاینت مانند این برگرداند:
OK status=307 url="https://www.example.com/help"این یک پاسخ نمونه helper برای یک درخواست منطبق است، نه یک برنامه helper کامل. مرورگر تغییر مسیر را دریافت می‌کند و درخواست جدیدی به URL HTTPS می‌فرستد. URLی خارج از سیاست ارتقا می‌تواند OK بگیرد و بدون تغییر بماند.
از فهرستی شناخته‌شده از مقصدهای دارای قابلیت HTTPS استفاده کنید و URL ورودی را تحلیل کنید. مسیر و query موردنظر را حفظ کنید، پورت‌های صریح را در نظر بگیرید و روش‌های درخواست را آگاهانه مدیریت کنید. جایگزینی کورکورانه هر پیشوند http فرض می‌کند هر مبدأ یک سرویس HTTPS معادل دارد.
helper باید به هر خط ورودی با پروتکل نسخه نصب‌شده Squid پاسخ دهد. اگر کانال‌های helper هم‌زمان فعال باشند، شناسه کانال را در پاسخ حفظ کنید. نمونه قدیمی و لخت 301:URL با قالب فعلی result-and-key/value قابل تعویض نیست.
وقتی مرورگر باید URL جدید را بداند، تغییر مسیر سمت کلاینت را انتخاب کنید. پاسخ rewrite-url در عوض از Squid می‌خواهد URL دیگری را پشت درخواست اصلی کلاینت بیاورد، که می‌تواند URLهای برنامه و وضعیت آن را ناسازگار بگذارد.
درخواست اولیه HTTP پیش از آنکه helper بتواند تغییر مسیرش دهد، به Squid رسیده است. این سیاست نمی‌تواند آن درخواست را به‌صورت گذشته‌نگر محافظت کند. TLS در اتصال HTTPS بعدی آغاز می‌شود؛ یک تونل CONNECT به‌تنهایی هیچ رمزگذاری‌ای فراهم نمی‌کند.