فوروارد پروکسی و ریورس پروکسی: تفاوت در چیست؟

واژه «پروکسی» برای دو ساختار متفاوت به کار می‌رود و این دو همیشه با هم اشتباه گرفته می‌شوند. وقتی یک توسعه‌دهنده می‌گوید «جلوی سایت پروکسی گذاشتیم»، منظورش ریورس پروکسی است. وقتی تیم داده می‌گوید «درخواست‌های ما از پروکسی می‌گذرند»، منظورش فوروارد پروکسی است. هر دو واسطه‌ای میان دو طرف‌اند؛ تفاوت در این است که از طرف چه کسی کار می‌کنند و چه کسی آن‌ها را تنظیم می‌کند.

این نوشته هر دو ساختار را جداگانه تعریف می‌کند، گام‌به‌گام نشان می‌دهد درخواست چگونه از هر کدام می‌گذرد و تفاوت‌ها را در یک جدول می‌آورد. سپس به کاربردهای ریورس پروکسی (توزیع بار، پایان‌دهی TLS، کش)، جایگاه CDNها و یک پیکربندی کوتاه Nginx می‌پردازیم.

فوروارد پروکسی چیست؟#

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

در زبان روزمره «پروکسی» تقریباً همیشه یعنی فوروارد پروکسی. پروکسی‌های مسکونی، دیتاسنتر و موبایلی که ارائه‌دهندگان می‌فروشند همگی فوروارد پروکسی هستند. سازوکار پایه را در سرور پروکسی چیست و چگونه کار می‌کند؟ مفصل توضیح داده‌ایم.

مسیر یک درخواست از فوروارد پروکسی چنین است:

1. کاربر آدرس پروکسی را در مرورگر یا کد تنظیم می‌کند.
2. کلاینت به‌جای سایت مقصد به پروکسی وصل می‌شود و برای HTTPS درخواست CONNECT target.com:443 را می‌فرستد.
3. پروکسی در صورت نیاز کلاینت را احراز هویت می‌کند و با IP خودش به سایت مقصد وصل می‌شود.
4. سایت مقصد درخواست را با IP پروکسی ثبت می‌کند و پاسخ را به آن می‌فرستد.
5. پروکسی پاسخ را به کلاینت برمی‌گرداند.

استفاده از فوروارد پروکسی در خط فرمان تنها یک گزینه است:

curl -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip

اینجا کلاینت از وجود پروکسی خبر دارد، چون خودش آدرس را داده است.

ریورس پروکسی چیست؟#

ریورس پروکسی واسطه‌ای است که جلوی یک یا چند سرور قرار می‌گیرد. وقتی بازدیدکننده به example.com وصل می‌شود، در واقع به ریورس پروکسی وصل شده است؛ ریورس پروکسی درخواست را به یکی از سرورهای برنامه پشت خود می‌فرستد و پاسخ را به بازدیدکننده برمی‌گرداند. بازدیدکننده نمی‌داند کدام ماشین پاسخ داده و نیازی هم به دانستنش ندارد.

استاندارد HTTP یعنی ⁦RFC 9110⁩ این ساختار را «gateway» یا «reverse proxy» می‌نامد و آن را واسطه‌ای توصیف می‌کند که از دید کلاینت همچون سرور اصلی رفتار می‌کند. برای کلاینت، ریورس پروکسی همان سایت است.

مسیر یک درخواست از ریورس پروکسی چنین است:

1. بازدیدکننده example.com را باز می‌کند؛ DNS نام را به آدرس IP ریورس پروکسی resolve می‌کند.
2. ریورس پروکسی اتصال را می‌پذیرد و معمولاً رمزگشایی TLS را همین‌جا انجام می‌دهد.
3. بر اساس مسیر درخواست، نام میزبان یا بار فعلی، یکی از سرورهای پشتی را انتخاب می‌کند.
4. درخواست را به آن سرور می‌فرستد و IP واقعی بازدیدکننده را در هدر X-Forwarded-For یا Forwarded اضافه می‌کند.
5. پاسخ سرور برنامه را می‌گیرد، اگر پیکربندی شده باشد در کش نگه می‌دارد و به بازدیدکننده می‌فرستد.

تفاوت این دو چیست؟#

هر دو ساختار ترافیک را از یک سو می‌گیرند و به سوی دیگر می‌دهند. سریع‌ترین راه دیدن تفاوت این است که بپرسیم واسطه به منافع چه کسی خدمت می‌کند.

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

ریورس پروکسی به چه کاری می‌آید؟#

ریورس پروکسی کارهایی را بر عهده می‌گیرد که خود برنامه نباید درگیرشان شود:

• توزیع بار. درخواست‌های ورودی را میان چند سرور برنامه پخش می‌کند. اگر یکی از سرورها پاسخ ندهد، ترافیک به بقیه می‌رود و بازدیدکنندگان متوجه نمی‌شوند.
• پایان‌دهی TLS. مدیریت گواهی و رمزگشایی در یک نقطه انجام می‌شود. سرورهای پشتی می‌توانند در شبکه داخلی HTTP ساده صحبت کنند یا گواهی داخلی جداگانه داشته باشند.
• کش و فشرده‌سازی. صفحه‌ها و فایل‌های ایستای پرتقاضا را نگه می‌دارد و پاسخ‌ها را فشرده می‌کند تا درخواست‌های کمتری به سرور برنامه برسد.
• لایه امنیتی. قواعد فایروال برنامه وب (WAF)، محدودیت نرخ و فیلترهای ربات را اعمال می‌کند. آدرس IP سرورهای پشتی مستقیماً در معرض حمله قرار نمی‌گیرد.
• مسیریابی بر اساس مسیر. درخواست‌های /api را به یک سرویس و درخواست‌های /blog را به سرویس دیگری می‌فرستد تا چند برنامه زیر یک دامنه اجرا شوند.
• استقرار بدون قطعی. انتشار نسخه تازه روی سرورهای تازه و انتقال تدریجی ترافیک از طریق ریورس پروکسی انجام می‌شود.

همکاری ریورس پروکسی با فایروال را در پروکسی و فایروال: تفاوت در چیست؟ آورده‌ایم.

چگونه با Nginx یک ریورس پروکسی ساده راه بیندازیم؟#

دستور اصلی ریورس پروکسی در Nginx، proxy_pass است. پیکربندی زیر ترافیکی را که به پورت 443 می‌رسد میان دو سرور برنامه پخش می‌کند و IP واقعی بازدیدکننده را به سرور پشتی می‌رساند:

upstream app {
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    location / {
        proxy_pass http://app;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

کار هر خط:

• بلوک upstream سرورهای پشتی را تعریف می‌کند. Nginx به‌طور پیش‌فرض درخواست‌ها را به نوبت پخش می‌کند؛ دستورهایی مانند least_conn یا ip_hash روش را تغییر می‌دهند.
• listen 443 ssl و خطوط گواهی، TLS را در ریورس پروکسی پایان می‌دهند.
• proxy_pass درخواست را به گروه app می‌فرستد.
• بدون خطوط proxy_set_header، برنامه پشتی همه درخواست‌ها را از IP ریورس پروکسی می‌بیند و این کار لاگ‌ها و محدودیت‌های نرخ را بی‌معنا می‌کند.

فهرست کامل دستورها در مستندات ngx_http_proxy_module آمده است.

آیا می‌توان به هدر X-Forwarded-For اعتماد کرد؟#

برنامه‌ای که پشت ریورس پروکسی است، IP بازدیدکننده را از هدر X-Forwarded-For می‌خواند. این هدر متن ساده است و کلاینت هم می‌تواند آن را بفرستد. اگر برنامه چشم‌بسته به آن اعتماد کند، بازدیدکننده می‌تواند IP جعلی بنویسد و از محدودیت نرخ یا محدودیت‌های مبتنی بر IP بگذرد.

روش درست:

• هدر را فقط در اتصال‌هایی بپذیرید که از ریورس پروکسی‌های شناخته‌شده می‌آیند. در Nginx این کار با دستورهای set_real_ip_from و real_ip_header انجام می‌شود.
• اگر چند واسطه وجود دارد، فهرست را از راست به چپ بخوانید و آدرس پیش از آخرین واسطه مطمئن را بردارید.
• هر جا زیرساخت پشتیبانی کند، هدر استاندارد Forwarded یعنی ⁦RFC 7239⁩ را ترجیح دهید.

همین منطق در سمت فوروارد پروکسی هم صادق است: سایت مقصد می‌تواند به هدرهایی که پروکسی اضافه کرده نگاه کند و کلاینت واقعی را ببیند. به همین دلیل بیشتر خدمات پروکسی هدری با IP کلاینت اضافه نمی‌کنند.

آیا CDN یک ریورس پروکسی است؟#

بله. شبکه توزیع محتوا (CDN) از سرورهای ریورس پروکسی تشکیل شده که در سراسر جهان پراکنده‌اند. وقتی سایتی را پشت CDN قرار می‌دهید، دامنه شما به آدرس‌های IP شبکه CDN resolve می‌شود؛ بازدیدکنندگان به نزدیک‌ترین سرور CDN وصل می‌شوند و CDN درخواست‌هایی را که در کش ندارد به سرور شما (مبدأ) می‌فرستد.

به همین دلیل CDNها همه کارهای ریورس پروکسی را در مقیاس بزرگ انجام می‌دهند: پایان‌دهی TLS، کش، جذب حملات DDoS، WAF و مدیریت ربات. محدودیت‌های نرخ و صفحه‌های بررسی رباتی که اسکرپر با آن‌ها روبه‌رو می‌شود معمولاً نه از خود سایت مقصد، بلکه از همین لایه ریورس پروکسی جلوی آن می‌آیند. برای نمونه‌ای از اینکه این لایه ترافیک ربات را چگونه دسته‌بندی می‌کند، Cloudflare Precursor را ببینید.

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

بیشتر درخواست‌ها از هر دو می‌گذرند. وقتی اسکریپت یک تیم داده قیمت‌ها را از یک فروشگاه اینترنتی می‌گیرد، مسیر چنین است:

1. اسکریپت درخواست را به فوروارد پروکسی تیم می‌فرستد.
2. فوروارد پروکسی دامنه سایت را resolve می‌کند و به CDN یعنی ریورس پروکسی جلوی سایت وصل می‌شود.
3. CDN درخواست را ارزیابی می‌کند و اگر در کش نباشد، آن را به سرور برنامه سایت می‌فرستد.
4. پاسخ از همان زنجیره به اسکریپت برمی‌گردد.

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

کاربردها#

• تیم جمع‌آوری داده: از فوروارد پروکسی برای دیدن قیمت‌ها در کشورهای مختلف و پخش درخواست‌ها استفاده می‌کند. برای این کار پروکسی چرخشی تنظیم می‌شود که از یک آدرس در هر اتصال IP متفاوتی می‌دهد. مقیاس‌پذیری خزش در صفحه راه‌حل وب کراولر آمده است.
• تیم فناوری اطلاعات سازمان: از فوروارد پروکسی برای خروج ترافیک کارکنان از یک نقطه و نگه‌داشتن لاگ، و از ریورس پروکسی برای در دسترس گذاشتن برنامه‌های داخلی استفاده می‌کند. بخش حفاظت از داده در صفحه راه‌حل امنیت داده آمده است.
• توسعه‌دهنده برنامه وب: برنامه را پشت Nginx یا CDN قرار می‌دهد و توزیع بار و TLS را از کد برنامه بیرون نگه می‌دارد.
• تیم آزمون نرم‌افزار: با فوروارد پروکسی می‌بیند برنامه در کشورهای دیگر چگونه باز می‌شود و با ریورس پروکسی سرویس‌های آزمون را زیر یک دامنه جمع می‌کند.
• کاربر فردی: فوروارد پروکسی‌ای مانند پروکسی HTTPS را تنظیم می‌کند تا ترافیک مرورگر از موقعیت دیگری بگذرد. اگر رمزنگاری هم لازم باشد، ابزار مناسب VPN است.

اشتباهات رایج#

• دیدن ریورس پروکسی به‌عنوان ابزار ناشناسی. ریورس پروکسی از صاحب سایت محافظت می‌کند؛ IP بازدیدکننده را پنهان نمی‌کند و در واقع آن را با X-Forwarded-For به سرور پشتی می‌رساند.
• نفرستادن هدر Host. Nginx به‌طور پیش‌فرض نام سرور موجود در آدرس proxy_pass را می‌فرستد. اگر برنامه پشتی به نام دامنه وابسته باشد، سایت نادرست یا صفحه خطا برمی‌گرداند.
• در دسترس گذاشتن مستقیم سرور پشتی. وقتی بتوان با IP خود سرور برنامه به آن رسید، قواعد امنیتی ریورس پروکسی بی‌معنا می‌شوند. پورت برنامه فقط باید برای آدرس داخلی ریورس پروکسی باز باشد.
• حمل هویت در هدرها در فوروارد پروکسی. پروکسی Squid که خودتان راه انداخته‌اید ممکن است با تنظیمات پیش‌فرض هدرهای X-Forwarded-For و Via را اضافه کند و سایت مقصد آدرس واقعی کلاینت را ببیند.
• ناهماهنگی زمان‌های انتظار. اگر timeout ریورس پروکسی از timeout برنامه کوتاه‌تر باشد، درخواست‌های طولانی با 504 Gateway Timeout قطع می‌شوند.

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

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

آیا «reverse proxy» همان «پروکسی معکوس» است؟#

بله، دو نام برای یک چیزند. مستندات فنی و تنظیمات نرم‌افزارها تقریباً همیشه «reverse proxy» را به کار می‌برند.

آیا VPN یک فوروارد پروکسی است؟#

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

آیا Nginx را می‌توان فوروارد پروکسی کرد؟#

Nginx می‌تواند درخواست‌های HTTP ساده را ارسال کند، اما نسخه استاندارد آن از متد CONNECT که برای HTTPS لازم است پشتیبانی نمی‌کند و به ماژول شخص ثالث نیاز دارد. فوروارد پروکسی‌ها معمولاً با نرم‌افزارهای ویژه‌ای مانند Squid ساخته می‌شوند.

آیا ریورس پروکسی سایت را کند می‌کند؟#

در نظریه، چون یک ایستگاه به مسیر اضافه می‌شود، تأخیر کوچکی می‌افزاید. در عمل بیشتر سایت‌ها پشت ریورس پروکسی یا CDN به لطف کش، فشرده‌سازی، استفاده دوباره از اتصال و نزدیکی به بازدیدکنندگان سریع‌تر بارگذاری می‌شوند.

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

اغلب بله. هدرهای پاسخ مانند Server، Via یا هدرهای ویژه CDN دیده می‌شوند و IP دامنه متعلق به یک CDN است. با این حال این اطلاعات آدرس سرور پشت آن را فاش نمی‌کند.

خدمات پروکسی چه نوع پروکسی‌ای می‌فروشند؟#

خدمات پروکسی مسکونی، دیتاسنتر، ISP و موبایل همگی فوروارد پروکسی‌اند. یک آدرس ورودی دریافت می‌کنید و درخواست‌هایتان از یکی از IPهای خروجی ارائه‌دهنده خارج می‌شود.

خلاصه#

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