تفاوت پروکسی شفاف، ناشناس و elite چیست؟

وقتی به یک فهرست پروکسی یا صفحه محصول یک ارائه‌دهنده نگاه می‌کنید، کنار نشانی‌ها برچسب‌های «transparent»، «anonymous» و «elite» را می‌بینید. در فارسی به این‌ها پروکسی شفاف، ناشناس و بسیار ناشناس (elite) می‌گویند. هر سه درخواست شما را از یک سرور دیگر عبور می‌دهند، اما درخواستی که به سایت مقصد می‌رسد یکسان نیست: در یکی نشانی IP واقعی شما به شکل یک سطر نوشته شده است، در دیگری فقط یادداشتی هست که می‌گوید «در میانه یک پروکسی قرار دارد» و در سومی هیچ‌کدام وجود ندارد.

در این نوشته توضیح می‌دهیم سطح ناشناسی بر چه پایه‌ای تعیین می‌شود، هدرهای Via، X-Forwarded-For و Forwarded چه چیزی را حمل می‌کنند و یک درخواست یکسان در سه سطح چگونه به مقصد می‌رسد. سپس می‌گوییم چرا این سطح‌ها در ترافیک HTTPS و SOCKS5 معنای خود را از دست می‌دهند، سطح پروکسی خودتان را چگونه می‌بینید و برچسب «elite» چه چیزی را تضمین نمی‌کند. نمونه Python پایان نوشته را با یک پروکسی آزمایشی محلی در هر سه سطح اجرا کرده‌ایم.

سطح ناشناسی پروکسی چیست؟#

پروکسی سرور میانی‌ای است که درخواست شما را از طرف شما به مقصد می‌رساند. چون سایت مقصد اتصال را از پروکسی می‌گیرد، نشانی IP پروکسی را می‌بیند. منطق کلی کار را در نوشته سرور پروکسی چیست و چگونه کار می‌کند؟ توضیح داده‌ایم؛ جدول انواع در آن نوشته پروکسی‌ها را بر پایه پروتکل، منبع IP و چرخش دسته‌بندی می‌کند. سطح ناشناسی پرسش چهارمی است که به این سه محور افزوده می‌شود: پروکسی هنگام رساندن درخواست، درباره شما به مقصد چه می‌گوید؟

پاسخ این پرسش در نشانی IP نیست و در سطرهای هدر درخواست است. پروکسی HTTP می‌تواند یک درخواست رمزنشده را باز کند، بخواند و پیش از رساندن، سطرهایی به آن بیفزاید. بسته به سطری که می‌افزاید سه نتیجه به دست می‌آید:

• مقصد هم می‌فهمد پروکسی در کار است و هم نشانی IP واقعی شما را می‌داند (شفاف).
• مقصد می‌فهمد پروکسی در کار است ولی نشانی واقعی شما را نمی‌داند (ناشناس).
• مقصد از هدرها چیزی نمی‌فهمد (elite).

پاسخ کوتاه پرسش «پروکسی ناشناس چیست؟» هم از همین‌جا به دست می‌آید: پروکسی‌ای که نشانی IP واقعی شما را به مقصد نمی‌رساند. هم سطح دوم و هم سطح سوم در این تعریف می‌گنجند. در کاربرد روزمره «پروکسی ناشناس» بیشتر در همین معنای گسترده گفته می‌شود؛ اما برچسب «anonymous» در فهرست‌ها در معنای محدود خود سطح دوم را نشان می‌دهد، یعنی پروکسی‌ای که نشانی را پنهان می‌کند ولی خودش را آشکار می‌کند.

این دسته‌بندی یک استاندارد نیست. هیچ RFC اصطلاحی به نام «elite proxy» تعریف نمی‌کند و این نام‌ها عادت سایت‌های فهرست پروکسی است. آنچه استاندارد است خود هدرهایی است که این سطح‌ها را پدید می‌آورند.

کدام هدرهای HTTP سطح را تعیین می‌کنند؟#

Via#

هدر Via ثبت می‌کند که درخواست از چه واسطه‌هایی گذشته است. بخش Via در ⁦RFC 9110⁩ این هدر را به سطرهای Received در ایمیل تشبیه می‌کند: هر واسطه نسخه پروتکلی را که درخواست را با آن گرفته و نام خودش را به انتهای فهرست می‌افزاید.

Via: 1.1 proxy-a.example, 1.1 cache-2

استاندارد در این باره روشن است: پروکسی باید به هر پیامی که می‌رساند یک هدر Via مناسب بیفزاید. همان بخش اجازه می‌دهد اگر نام سرور اطلاعات حساس به شمار می‌آید، به‌جای نام واقعی یک نام مستعار نوشته شود. پس Via نشانی IP واقعی شما را حمل نمی‌کند و فقط می‌گوید «این درخواست از یک واسطه گذشته است». هدری که سطح ناشناس را پدید می‌آورد همین است. پروکسی‌هایی که elite نامیده می‌شوند این سطر را اصلاً نمی‌افزایند و به این ترتیب آگاهانه از آن بند استاندارد پیروی نمی‌کنند.

X-Forwarded-For#

هدر X-Forwarded-For نشانی IP کلاینتی را حمل می‌کند که به پروکسی وصل شده است. این هدر هیچ‌گاه استاندارد رسمی نشد، اما به گفته صفحه MDN درباره X-Forwarded-For یک استاندارد عملی است. اگر بیش از یک واسطه در مسیر باشد، نشانی‌ها با ویرگول پشت سر هم می‌آیند: در سمت چپ کلاینتی که درخواست را آغاز کرده و در سمت راست آخرین واسطه قرار می‌گیرد.

X-Forwarded-For: 203.0.113.7, 198.51.100.24

این هدر در اصل برای متعادل‌کننده‌های بار و ریورس پروکسی‌ها ساخته شد: برنامه‌ای که پشت آن‌هاست نشانی بازدیدکننده را از این سطر می‌خواند. اینکه سایت مقصد تا چه اندازه می‌تواند به این سطر اعتماد کند را در بخش «آیا می‌توان به هدر X-Forwarded-For اعتماد کرد؟» از نوشته فوروارد پروکسی و ریورس پروکسی: تفاوت در چیست؟ توضیح داده‌ایم. در سمت فوروارد پروکسی همین سطر در جهت وارونه کار می‌کند: اگر پروکسی این هدر را بیفزاید، نشانی‌ای که می‌خواستید پنهان بماند به شکل متن ساده در لاگ مقصد ثبت می‌شود. هدری که سطح شفاف را پدید می‌آورد همین است.

Forwarded#

هدر Forwarded شکل استاندارد همان کار است. ⁦RFC 7239⁩ در یک هدر چهار پارامتر تعریف می‌کند: for (فرستنده درخواست)، by (واسطه‌ای که درخواست را گرفته)، host و proto.

Forwarded: for=203.0.113.7;proto=http;by=198.51.100.24

این RFC می‌گوید هدر اختیاری است و به دلیل حساسیت اطلاعاتی که حمل می‌کند باید به‌طور پیش‌فرض خاموش باشد. در بخش مقدمه هم جمله روشنی آمده است: اگر هدف پروکسی فراهم کردن ناشناسی برای کلاینت باشد، پروکسی از این قابلیت استفاده نمی‌کند. دو راه میانه تعریف شده است: واسطه می‌تواند for=unknown بنویسد یا از یک شناسه تصادفی که با زیرخط آغاز می‌شود (for=_hidden) استفاده کند. در هر دو حالت مقصد نشانی شما را نمی‌داند ولی می‌فهمد واسطه‌ای در میانه هست؛ این با سطح ناشناس برابر است.

ردهای دیگر#

ابزارهایی که فهرست‌های پروکسی را می‌آزمایند به چند سطر غیراستاندارد هم نگاه می‌کنند: X-Real-IP، Client-IP و Proxy-Connection که کلاینت به پروکسی می‌فرستد و یک پروکسی بی‌دقت آن را بی‌تغییر به مقصد می‌رساند. اگر این سطرها به مقصد برسند، یکی از همان دو چیز را می‌گویند: یا نشانی شما را، یا اینکه واسطه‌ای در میانه هست.

یک درخواست یکسان در سه سطح چگونه به مقصد می‌رسد؟#

مسیر یک درخواست رمزنشده http:// چنین است:

1. کلاینت کل درخواست را به پروکسی می‌فرستد. نشانی مقصد، هدرها و در صورت وجود بدنه برای پروکسی خوانا هستند.
2. پروکسی هویت شما را تأیید می‌کند و فقط سطرهایی را که به خودش مربوط است (مانند Proxy-Authorization) جدا می‌کند.
3. بسته به پیکربندی، سطرهای تازه‌ای به درخواست می‌افزاید یا چیزی نمی‌افزاید. سطح در همین گام تعیین می‌شود.
4. از نشانی IP خودش اتصال تازه‌ای به مقصد باز می‌کند و درخواست را می‌رساند.
5. مقصد دو داده را با هم می‌بیند: نشانی‌ای که اتصال از آن آمده (IP خروجی پروکسی) و آنچه در هدرها نوشته شده است.

پروکسی آزمایشی محلی خود را با سه پیکربندی جداگانه اجرا کردیم و یک درخواست یکسان را به یک نقطه پایانی پژواک فرستادیم. نقطه پایانی پژواک سروری است که هدرهای دریافتی را همان‌گونه که هست برمی‌گرداند. کلاینت روی 127.0.0.1 و نشانی خروجی پروکسی 127.0.0.2 بود و سه نتیجه در ادامه آمده است؛ سطرهای نامربوط مانند Accept را کوتاه کرده‌ایم.

پیکربندی شفاف:

Host: 127.0.0.1:8318
User-Agent: python-requests/2.34.2
Via: 1.1 test-proxy
X-Forwarded-For: 127.0.0.1
Forwarded: for=127.0.0.1;proto=http

پیکربندی ناشناس:

Host: 127.0.0.1:8318
User-Agent: python-requests/2.34.2
Via: 1.1 test-proxy

پیکربندی elite:

Host: 127.0.0.1:8318
User-Agent: python-requests/2.34.2

در هر سه حالت سرور پژواک گزارش داد که اتصال از نشانی 127.0.0.2 آمده است و تفاوت فقط در هدرها بود.

تفاوت‌های پروکسی شفاف، ناشناس و elite چیست؟#

چون نام‌ها از فهرستی به فهرست دیگر تغییر می‌کند، نگاه کردن به خود هدرها مطمئن‌تر از نگاه کردن به برچسب است. گونه میانی که «distorting» نامیده می‌شود در سطر X-Forwarded-For به‌جای نشانی واقعی یک نشانی ساختگی می‌نویسد. از دید مقصد نتیجه با سطح ناشناس یکی است: نشانی شما را نمی‌داند، ولی از وجود یک واسطه باخبر می‌شود.

پروکسی شفاف چیست و کجا با آن روبه‌رو می‌شوید؟#

«پروکسی شفاف» در دو معنای جدا به کار می‌رود و این دو معنا بارها با هم آمیخته می‌شوند.

نخستین معنا در سطح شبکه است. بخش 3.7 از ⁦RFC 9110⁩ که واسطه‌ها را شرح می‌دهد، ساختاری را که کلاینت انتخابش نکرده و شبکه خودبه‌خود ترافیک را به آن هدایت می‌کند «interception proxy» می‌نامد و یادآوری می‌کند که نام رایج آن «transparent proxy» است. بر پایه همان بخش، این ساختار بیشتر در نقاط دسترسی عمومی که پیش از اتصال به اینترنت ورود می‌خواهند و در فایروال‌های سازمانی که قواعد استفاده را اعمال می‌کنند دیده می‌شود. شما در مرورگر هیچ تنظیمی انجام نمی‌دهید. رابطه این ساختارها با فایروال را در نوشته پروکسی و فایروال: تفاوت در چیست؟ توضیح داده‌ایم.

دومین معنا همان است که در فهرست‌های پروکسی می‌آید: پروکسی‌ای که نشانی IP واقعی شما را با هدر به مقصد می‌رساند. این دو معنا بیشتر وقت‌ها در یک سرور به هم می‌رسند، چون دغدغه پروکسی شبکه سازمان پنهان کردن شما نیست؛ کش کردن، پالایش و ثبت گزارش است.

نمونه خوب آن Squid است که نرم‌افزار پروکسی متن‌باز و پرکاربردی است. بر پایه مستندات forwarded_for در Squid (این دستور در نسخه v7 و نسخه‌های پیش از آن وجود دارد) مقدار پیش‌فرض on است و در این حالت نشانی IP کلاینت به سطر X-Forwarded-For افزوده می‌شود. اگر مقدار off شود سطر به شکل unknown می‌رود و اگر delete شود هدر به‌کلی پاک می‌شود. در همان نسخه‌ها هدر Via هم به‌طور پیش‌فرض روشن است. چنین پروکسی‌ای که با تنظیمات پیش‌فرض نصب شده باشد به همین دلیل در سطح شفاف کار می‌کند؛ «ناشناس» یا «elite» بودن یک پروکسی از نوع نرم‌افزار نمی‌آید و از چند سطر پیکربندی می‌آید که گرداننده آن نوشته است.

پروکسی elite (بسیار ناشناس) چیست؟#

پروکسی elite پروکسی‌ای است که حتی در درخواست‌های رمزنشده نه نشانی شما و نه ردی از یک واسطه را به مقصد نمی‌رساند. درخواست را می‌گیرد، سطرهای مربوط به خودش را جدا می‌کند و باقی را بی‌دست‌کاری از نشانی IP خودش می‌فرستد.

در سرویس‌های پروکسی پولی این رفتار امتیاز ویژه نیست و وضعیت عادی است: سرویسی که نشانی مشتری را برای مقصد بنویسد معنایی ندارد. واژه «elite» معنای اصلی خود را در فهرست‌های رایگان پیدا می‌کند: در میان آن نشانی‌ها سرورهایی هستند که با تنظیمات پیش‌فرض رها شده‌اند، نادرست پیکربندی شده‌اند یا به دست دیگران افتاده‌اند و اینکه کدام‌یک هدر می‌افزاید جز از برچسب از جای دیگری فهمیده نمی‌شود. جنبه امنیتی این فهرست‌ها را در نوشته پروکسی رایگان و سایت‌های وب پروکسی امن هستند؟ بررسی کرده‌ایم.

برچسب elite نمی‌گوید که پروکسی سریع است، نشانی IP پاک است یا ترافیک شما ثبت نمی‌شود. فقط می‌گوید در درخواست رسانده‌شده دو سطر وجود ندارد.

چرا سطح‌ها در HTTPS و SOCKS5 معنای خود را از دست می‌دهند؟#

هر سه سطح بر این فرض استوارند که پروکسی می‌تواند درخواست را بخواند و تغییر دهد. این فرض فقط در HTTP رمزنشده درست است.

در درخواست HTTPS کلاینت با متد CONNECT به پروکسی می‌گوید «به پورت 443 این سرور یک تونل باز کن». بر پایه ⁦RFC 9110⁩ پس از برقرار شدن تونل، کار پروکسی فقط این است که داده را در دو جهت چشم‌بسته منتقل کند. دست‌دهی TLS میان کلاینت و مقصد انجام می‌شود؛ هدرها درون کانال رمزشده‌اند و پروکسی نمی‌تواند سطری به آن‌ها بیفزاید. این را هم در آزمایش محلی سنجیدیم: پروکسی در پیکربندی شفاف به درخواست http:// سه سطر افزود، ولی در درخواست https:// که از همان پروکسی گذشت حتی یک سطر اضافه به سرور پژواک نرسید. استثنای آن پروکسی‌های بازرسی سازمانی‌اند که ترافیک را باز و دوباره رمز می‌کنند؛ آن‌ها هم بدون نصب گواهی ریشه خودشان روی دستگاه شما نمی‌توانند این کار را انجام دهند.

در SOCKS5 وضعیت از آغاز همین است. پروکسی SOCKS به زبان HTTP سخن نمی‌گوید و فقط بایت‌ها را جابه‌جا می‌کند؛ لایه‌ای ندارد که بتواند در آن هدر بیفزاید. تفاوت این دو پروتکل را در نوشته تفاوت پروکسی SOCKS و HTTP: کدام را انتخاب کنیم؟ مقایسه کرده‌ایم. با رفتن وب به سوی HTTPS، میدان عملی تفکیک سطح‌ها کوچک شده است: صفحه‌های رمزنشده، APIهای قدیمی و فراخوانی‌های HTTP ساده‌ای که دستگاه‌ها انجام می‌دهند. در صفحه‌های پروکسی HTTPS و پروکسی SOCKS5 می‌بینید هر پروتکل برای چه کاری مناسب است.

این به آن معنا نیست که مقصد در HTTPS هیچ چیز نمی‌فهمد. فقط راه هدرها بسته می‌شود و نشانه‌های دیگری که در ادامه می‌آید سر جای خود می‌مانند.

سطح پروکسی خودتان را چگونه می‌بینید؟#

تنها چیزی که لازم است یک نقطه پایانی پژواک است. سرویس متن‌باز httpbin.org برای این کار بسیار به کار می‌رود. دو نکته نتیجه را تعیین می‌کند:

• نشانی باید با http:// آغاز شود. در نشانی https:// پروکسی نمی‌تواند هدر بیفزاید و به همین دلیل هر پروکسی elite به نظر می‌رسد.
• پارامتر show_env=1 باید افزوده شود. سرویس httpbin به‌طور پیش‌فرض سطرهایی مانند Via و X-Forwarded-For را از پاسخ حذف می‌کند. در درخواست بدون این پارامتر، با اینکه این هدرها را فرستاده بودیم در پاسخ دیده نشدند و با افزودن پارامتر دیده شدند.

برای آزمودن بدون کدنویسی کافی است پروکسی را در مرورگر تنظیم کنید و نشانی http://httpbin.org/get?show_env=1 را باز کنید. در بخش headers صفحه ببینید آیا سطر Via یا سطری که نشانی خودتان را دارد وجود دارد یا نه. در خط فرمان همین درخواست چنین است (گزینه‌های پروکسی cURL در نوشته استفاده از cURL با پروکسی: دستورها و مثال‌ها آمده است):

curl -s -x http://user:pass@pr.proxynet.io:8000 "http://httpbin.org/get?show_env=1"

هنگام خواندن پاسخ یک نکته می‌تواند گمراه‌کننده باشد: httpbin پشت یک متعادل‌کننده بار کار می‌کند و آن متعادل‌کننده بار نشانی‌ای را که به آن وصل شده در سطر X-Forwarded-For می‌نویسد. حتی در درخواست بدون پروکسی هم این سطر را می‌بینید. اگر در سطر فقط نشانی خروجی پروکسی باشد نشتی وجود ندارد؛ نشت زمانی است که نشانی خودتان هم در آن سطر باشد.

اسکریپت زیر این تفکیک را خودش انجام می‌دهد. نخست با یک درخواست بدون پروکسی نشانی شما را می‌یابد، سپس از راه پروکسی به همان نقطه پایانی می‌رود و هدرهای رسیده را دسته‌بندی می‌کند. چون هر دو نشانی را می‌آزماید، اثر تونل را هم نشان می‌دهد.

import requests

PROXY = "http://user:pass@pr.proxynet.io:8000"
ECHO_URLS = [
    "http://httpbin.org/get?show_env=1",   # plain HTTP: the proxy can read the request and add headers
    "https://httpbin.org/get?show_env=1",  # HTTPS: the request travels inside the CONNECT tunnel
]
# Known headers that intermediary servers add to a request
PROXY_HEADERS = ["via", "forwarded", "x-forwarded-for", "x-real-ip", "client-ip", "proxy-connection"]


def echo(url, proxies=None):
    """Return the address and the headers the echo endpoint saw."""
    data = requests.get(url, proxies=proxies, timeout=20).json()
    headers = {name.lower(): value for name, value in data["headers"].items()}
    return data["origin"], headers


def classify(real_ip, origin, headers):
    exit_ip = origin.split(",")[-1].strip()
    found = {name: headers[name] for name in PROXY_HEADERS if name in headers}
    # The load balancer in front of the echo service writes the exit IP into X-Forwarded-For; that is not a leak
    if found.get("x-forwarded-for", "").strip() == exit_ip:
        del found["x-forwarded-for"]
    if exit_ip == real_ip:
        level = "proxy not in use (the exit IP is your own address)"
    elif real_ip in origin or any(real_ip in value for value in found.values()):
        level = "transparent (the real IP reaches the target)"
    elif found:
        level = "anonymous (IP hidden, proxy visible)"
    else:
        level = "elite (no trace in the headers)"
    return level, exit_ip, found


def main():
    proxies = {"http": PROXY, "https": PROXY}
    for url in ECHO_URLS:
        real_ip = echo(url)[0].split(",")[-1].strip()  # request without the proxy: your own address
        level, exit_ip, found = classify(real_ip, *echo(url, proxies))
        print(f"{url}\n  exit IP: {exit_ip}\n  level  : {level}")
        for name, value in found.items():
            print(f"  {name}: {value}")


main()

وقتی اسکریپت را با پیکربندی شفاف پروکسی آزمایشی محلی و یک سرور پژواک محلی که به همان شکل پاسخ می‌دهد اجرا کردیم، خروجی چنین بود:

http://127.0.0.1:8318/get
  exit IP: 127.0.0.2
  level  : transparent (the real IP reaches the target)
  via: 1.1 test-proxy
  forwarded: for=127.0.0.1;proto=http
  x-forwarded-for: 127.0.0.1
https://127.0.0.1:8319/get
  exit IP: 127.0.0.2
  level  : elite (no trace in the headers)

در پیکربندی ناشناس در بلوک نخست فقط سطر via ماند و در پیکربندی elite هیچ سطری فهرست نشد. بلوک دوم در هر سه پیکربندی یکسان بود. بررسی‌های دیگر مانند سرعت، موقعیت و DNS را به‌ترتیب در نوشته آیا پروکسی کار می‌کند؟ چگونه پروکسی را آزمایش کنیم توضیح داده‌ایم.

چرا برچسب «elite» تضمین نیست؟#

سایت‌ها برای تصمیم‌گیری درباره اینکه یک اتصال از پروکسی می‌آید یا نه، به‌ندرت به هدرها نیاز دارند. داده‌هایی در دست دارند که به هدر وابسته نیست و پروکسی نمی‌تواند آن‌ها را تغییر دهد:

• مالک نشانی IP. هر بلوک نشانی به نام یک سازمان ثبت شده است. اگر بلوک متعلق به یک شرکت میزبانی باشد، هدرها هر اندازه هم پاک باشند اتصال «ترافیک سرور» به شمار می‌آید. اینکه این رکورد چگونه خوانده می‌شود را در نوشته تفاوت پروکسی ISP و پروکسی مسکونی: کدام را انتخاب کنیم؟ توضیح داده‌ایم.
• اعتبار نشانی. سرویس‌های اطلاعات IP نشانی‌ها را بر پایه رفتار گذشته‌شان امتیاز می‌دهند. چگونگی شکل‌گیری این امتیاز در نوشته IP Fraud Score چیست و امتیاز ریسک IP چگونه خوانده می‌شود؟ آمده است.
• لیست‌های سیاه. نشانی‌ای که پیش‌تر از آن سوءاستفاده شده، کاربر امروزش هر که باشد ممکن است در فهرست بماند. جزئیات در نوشته لیست سیاه IP چیست و چگونه از آن خارج شویم؟ آمده است.
• سازگاری. اگر کشور نشانی IP با منطقه زمانی یا زبان مرورگر نخواند، یا مرورگر نشانی واقعی را از راه دیگری آشکار کند، این نکته یادداشت می‌شود. بنگرید به نشت WebRTC و DNS: چیست و چگونه جلوی آن را بگیریم.

به همین دلیل نشانی‌های «elite» در فهرست‌های رایگان در عمل بدترین نتیجه را می‌دهند: هدرهایشان پاک است، اما چون نشانی در فهرستی منتشر شده که برای همه باز است، به احتمال زیاد با عنوان «پروکسی باز» وارد پایگاه‌های داده IP شده است. اگر روی صفحه هشدار «Anonymous proxy detected» یعنی «پروکسی ناشناس شناسایی شد» را می‌بینید، دلیلش هم بیشتر وقت‌ها همین است: سایت هدری نخوانده و نشانی شما را در یک پایگاه داده جست‌وجو کرده است. اگر بدون اینکه اصلاً از پروکسی استفاده کنید این هشدار را می‌گیرید، دلیل‌های احتمالی و کارهایی که باید کرد را گام به گام در نوشته خطای «VPN یا پروکسی شناسایی شد» چیست و چرا می‌آید؟ آورده‌ایم.

پاک بودن هدرها لازم است، چون پروکسی‌ای که نشانی شما را به شکل یک سطر می‌رساند از آغاز به هدف خود نمی‌رسد. اما کافی نیست: اینکه یک سایت اتصال شما را چگونه ارزیابی کند بیش از سطح، به این بستگی دارد که نشانی IP از آن کیست و چه پیشینه‌ای دارد. شرایط استفاده یک پلتفرم پشت پروکسی هم به همان شکل برقرار است.

در چه کاری کدام سطح اهمیت دارد؟#

• اطلاعات تهدید و پژوهش OSINT: نشانی سازمانی تیم امنیتی که یک سرور مشکوک را بررسی می‌کند نباید در لاگ آن سرور ثبت شود. پیکربندی شفاف درست عکس این را انجام می‌دهد. چارچوب این کار در صفحه راه‌حل امنیت داده آمده است.
• پایش قیمت و موجودی در داده‌های عمومی: نشانی دفتر شما نباید به شکل یک سطر به مقصد برود؛ یک پروکسی مسکونی که هدر نمی‌افزاید ابزار معمول این کار است.
• نشست‌های طولانی همراه با ورود به حساب: افزون بر سطح، ثابت ماندن نشانی هم مهم است. پروکسی ISP یک نشانی ثابت می‌دهد که به نام یک ارائه‌دهنده اینترنت ثبت شده است.
• راستی‌آزمایی تبلیغات و تست بومی‌سازی: اگر می‌سنجید که صفحه برای یک بازدیدکننده عادی در آن کشور چگونه دیده می‌شود، درخواستی که سطر Via دارد به مقصد می‌گوید «من از یک واسطه آمده‌ام» و سنجش دیگر نماینده آن بازدیدکننده نیست.
• محدود کردن دسترسی به API خودتان: اگر فهرست مجاز بر پایه IP کار می‌کند، تعیین‌کننده هدرها نیستند و نشانی‌ای است که اتصال از آن می‌آید؛ جزئیات در نوشته IP ثابت برای دسترسی به API آمده است.

خطاهای رایج#

• سنجیدن سطح با نشانی https://. چون درون تونل نمی‌توان هدر افزود، هر پروکسی elite به نظر می‌رسد و آزمون چیزی نمی‌گوید.
• فراموش کردن پارامتر show_env=1 در httpbin. سطرهای Via و X-Forwarded-For از پاسخ حذف می‌شوند و پروکسی شفاف پاک دیده می‌شود.
• یکی گرفتن برچسب «elite» با کیفیت IP. برچسب درباره هدرهاست و نمی‌گوید نشانی در لیست سیاه هست یا نه.
• رها کردن پروکسی‌ای که خودتان راه انداخته‌اید با تنظیمات پیش‌فرض. در نرم‌افزارهای پرکاربرد پروکسی، رساندن نشانی کلاینت رفتار پیش‌فرض است.
• نگاه کردن فقط به هدرها و فراموش کردن سمت مرورگر. نشانی‌ای که از راه WebRTC یا DNS آشکار شود پاک‌ترین هدرها را هم بی‌معنا می‌کند.

راهنمای انتخاب#

پرسش‌های متداول#

پروکسی ناشناس یعنی چه؟#

یعنی پروکسی‌ای که نشانی IP واقعی شما را به سایت مقصد نمی‌رساند. سایت اتصال را از نشانی پروکسی می‌بیند. در معنای محدود، یعنی همان برچسب «anonymous» در فهرست‌های پروکسی، سطح دوم را نشان می‌دهد: پروکسی‌ای که نشانی را پنهان می‌کند ولی با هدری مانند Via آشکار می‌کند که پروکسی است.

تفاوت پروکسی elite با پروکسی ناشناس چیست؟#

هر دو نشانی واقعی شما را پنهان می‌کنند. تفاوت در یک سطر است: پروکسی ناشناس ردی از واسطه (Via، Forwarded: for=unknown) در درخواست می‌گذارد و پروکسی elite نمی‌گذارد. سایت مقصد در حالت نخست از هدر می‌خواند که «این درخواست از یک پروکسی گذشته است» و در حالت دوم نمی‌تواند این را از هدر بخواند.

آیا پروکسی شفاف نشانی IP مرا پنهان می‌کند؟#

خیر. مقصد اتصال را از نشانی پروکسی می‌گیرد، اما نشانی واقعی شما در سطر X-Forwarded-For یا Forwarded نوشته شده است و در لاگ سرور ثبت می‌شود.

اگر از پروکسی elite استفاده کنم، سایت نمی‌فهمد که پروکسی دارم؟#

از هدرها نمی‌فهمد، ولی از راه‌های دیگر می‌تواند بفهمد: ثبت بودن نشانی IP به نام یک شرکت میزبانی، امتیاز اعتبار، رکوردهای لیست سیاه و نشانه‌های ناسازگاری که از مرورگر می‌آید به هدر وابسته نیستند.

آیا سطح پروکسی در سایت‌های HTTPS تفاوتی ایجاد می‌کند؟#

در عمل خیر. درخواست HTTPS از درون تونل CONNECT می‌گذرد و پروکسی نمی‌تواند به ترافیک رمزشده هدر بیفزاید. تفاوت فقط در درخواست‌های رمزنشده http:// پدیدار می‌شود.

سطح پروکسی‌ام را بدون کدنویسی چگونه بفهمم؟#

پروکسی را در مرورگر تنظیم کنید و نشانی http://httpbin.org/get?show_env=1 را باز کنید. اگر در بخش headers پاسخ Via هست، پروکسی خودش را آشکار می‌کند و اگر در هر سطری نشانی IP خودتان هست، در سطح شفاف کار می‌کند. اگر هیچ‌کدام نیست، در سطح هدر ردی به جا نمی‌گذارد.

خلاصه#

تفکیک شفاف، ناشناس و elite سه پاسخ به یک پرسش است: پروکسی هنگام رساندن یک درخواست رمزنشده چه چیزی به آن می‌افزاید؟ اگر نشانی واقعی شما را بیفزاید شفاف است، اگر فقط ردی از واسطه بیفزاید ناشناس است و اگر چیزی نیفزاید elite است. هدر Via در ⁦RFC 9110⁩ و هدر Forwarded در ⁦RFC 7239⁩ تعریف شده است و X-Forwarded-For یک استاندارد عملی است. در HTTPS و SOCKS5 پروکسی نمی‌تواند به هدرها دست بزند و این تفکیک خودبه‌خود از میان می‌رود. سطح را می‌توانید با یک آزمون پژواک روی نشانی http:// در چند ثانیه بسنجید. نتیجه به‌تنها چیزی را وعده نمی‌دهد: در ارزیابی سایت‌ها وزن اصلی با مالک و پیشینه نشانی IP است. نوع IP مناسب کارتان را می‌توانید در خدمات پروکسی ما مقایسه کنید.