پراکسی‌های IPv4 و IPv6: کدام اتصال به پشتیبانی نیاز دارد؟
اتصال کلاینت به پراکسی و پراکسی به سایت می‌توانند از خانواده‌های آدرس متفاوت استفاده کنند. پیش از انتخاب نقطهٔ اتصال، هر دو را بررسی کنید.
شنوندهٔ پراکسی IPv6 به مسیر IPv6 از کلاینت شما نیاز دارد. اتصال خروجی آن به سایت همچنان می‌تواند از IPv4 استفاده کند. برعکس، شنوندهٔ IPv4 می‌تواند به مقصد IPv6 برسد، اگر پراکسی پشتیبانی و مسیر لازم را داشته باشد.
| اتصال | پشتیبانی لازم |
|---|---|
| کلاینت → پراکسی | مسیری به آدرس نقطهٔ اتصال و یک سرویس شنوندهٔ دسترس‌پذیر. |
| پراکسی → مقصد | آدرس مناسب مقصد، حل‌کنندهٔ نام، مسیر خروجی و سیاست دسترسی در پراکسی. |
در URL کامل پراکسی، آدرس عددی IPv6 را در کروشه بگذارید:
http://[2001:db8::10]:8080آدرس مستندات را با نقطهٔ اتصال واقعی جایگزین کنید. فیلدهای جداگانهٔ میزبان و پورت ممکن است آدرس بدون کروشه بخواهند؛ قالب برنامه را رعایت کنید. دستور درست، مسیر IPv6 گمشده را نمی‌سازد؛ پس پیش از مقصر دانستن شنونده، وضعیت IPv6 شبکه یا مقصد IPv6 دیگری را بررسی کنید.
کدام طرف آدرس مقصد را انتخاب می‌کند؟
درخواست CONNECT مبتنی بر نام میزبان، اتصال مقصد را به پراکسی می‌سپارد. SOCKS5 بسته به حالت کلاینت می‌تواند آدرس IPv4، آدرس IPv6 یا نام دامنه را حمل کند. اجبار خانوادهٔ آدرس در کلاینت لزوماً نامی را که از راه دور حل می‌شود محدود نمی‌کند؛ مشخص کنید این گزینه بر کدام اتصال اثر دارد.
بنابراین گزارش IPv4 در ابزار بررسی IP پس از انتخاب شنوندهٔ IPv6 بدون اتصال دوم کلاینت هم ممکن است. ابتدا مشخص کنید ابزار همتای TCP خودش، یک هدر برنامه یا درخواست دیگری از مرورگر را گزارش می‌کند. ارسال HTTP رمزنگاری‌نشده می‌تواند اطلاعات آدرس کلاینت را اضافه کند؛ رلهٔ معمولی CONNECT نمی‌تواند هدر را در HTTP رمز‌شدهٔ مقصد وارد کند. اطلاعات Forwarded به سیاست اعتماد نیاز دارد و به‌خودی‌خود وجود اتصال شبکهٔ دیگری را ثابت نمی‌کند.
نقطهٔ اتصال، هدف، پروتکل و نخستین شکست را ثبت کنید. نرسیدن به شنونده با پاسخ آن مبنی بر دسترس‌ناپذیری مقصد متفاوت است. گردآورندهٔ پشت فهرست پراکسی ProxyHub فعلاً رکوردهای IPv4 می‌پذیرد؛ این مثال‌های IPv6 رفتار عمومی را توضیح می‌دهند، نه فیلتر IPv6 فعلی فهرست را.