پروکسی‌های فرم وب مبدأ مرورگر را تغییر می‌دهند، نه فقط IP خروجی را
یک وب‌سایت پروکسی با کادر ورود URL را از پروکسی بومی مرورگر جدا کنید و توضیح دهید چرا ورودهای پیچیده و اسکریپت‌ها می‌توانند متفاوت رفتار کنند.
صفحه‌ای که کادر URL دارد یک برنامه وب است. وارد کردن یک مقصد در آنجا از آن برنامه می‌خواهد محتوا را بیاورد و نمایش دهد. این ترتیبی متفاوت از گفتن به مرورگر برای استفاده از پروکسی HTTP یا SOCKS است.
با تنظیم پروکسی بومی، مرورگر همچنان URL مقصد را همان وب‌سایت می‌داند. در یک پروکسی فرم وب متعارف، صفحه قابل مشاهده از طریق طرح URL و مبدأ خود برنامه پروکسی ارائه می‌شود. سرویس ممکن است پیوندها، اسکریپت‌ها، سرآیندها یا کوکی‌ها را بازنویسی کند تا پیمایش ادامه یابد.
| رفتار | چرا این تفاوت اهمیت دارد |
|---|---|
| بررسی‌های هم‌مبدأ | مرورگر مبدأیی را ارزیابی می‌کند که واقعاً بارگذاری کرده است |
| کوکی‌ها و تغییر مسیرها | رفتار دامنه، مسیر و بافت امن باید با URLهای ارائه‌شده سازگار باشد |
| اسکریپت‌هایی که URL جدید می‌سازند | درخواست‌ها می‌توانند از یک طرح ساده بازنویسی پیوند فرار کنند |
| اتصال‌های پایدار یا WebSockets | برنامه پروکسی به مدیریت سازگار صریح نیاز دارد |
این یک نتیجه آشنا را توضیح می‌دهد: یک مقاله ساده بارگذاری می‌شود، اما ویرایشگر سند یا جریان ورود شکست می‌خورد. این شکست لزوماً به معنای رد کردن IP خروجی سرویس توسط مقصد نیست. ممکن است واسطه نتواند فرض‌های برنامه درباره URLها و امنیت مرورگر را حفظ کند.
همچنین تفکیک کنید TLS کجا پایان می‌یابد. سرویسی که محتوای مقصد را می‌آورد و دوباره منتشر می‌کند، در موقعیت اعتماد متفاوتی از یک رله معمولی CONNECT است که یک نشست رمزنگاری‌شده را حمل می‌کند. دیدن HTTPS روی نشانی خود وب‌سایت پروکسی، اتصال TLS سرتاسری از مرورگر به وب‌سایت اصلی را اثبات نمی‌کند.
اگر هدف، مرور معمولی از خروجی دیگری است، یک نقطه پایانی HTTP یا SOCKS از سرویس خود یا از یک فهرست پروکسی انتخاب کنید و از پیکربندی پروکسی بومی پشتیبانی‌شده استفاده کنید، مانند تنظیمات اتصال فایرفاکس. این کار معمولاً بخش بیشتری از معناشناسی عادی مقصد در مرورگر را حفظ می‌کند. یک وب‌سایت با کادر URL همچنان می‌تواند برنامه‌ای آگاهانه انتخاب‌شده باشد، اما نباید به‌عنوان همان رابط با راه‌اندازی کمتر معرفی شود.