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

پروکسی سرور (Proxy Server) یک سرور واسط است که بین کلاینت (دستگاه شما) و سرور مقصد قرار می‌گیرد. هنگامی که از پروکسی استفاده می‌کنید، درخواست‌های شما مستقیماً به وب‌سایت نمی‌روند، بلکه ابتدا از طریق پروکسی سرور عبور می‌کنند که سپس آن‌ها را به مقصد نهایی ارسال می‌کند.

مفهوم اصلی کارکرد

بدون پروکسی (اتصال مستقیم):
┌──────────┐                                    ┌──────────┐
│  کلاینت  │ ────────── درخواست مستقیم ────────→│   سرور  │
│   (شما)  │ ←───────── پاسخ مستقیم ──────────│  (سایت)  │
└──────────┘                                    └──────────┘
   IP: 192.168.1.10                                IP: 93.184.216.34

با پروکسی (از طریق واسطه):
┌──────────┐           ┌──────────┐           ┌──────────┐
│  کلاینت  │ ─────────→│  سرور   │ ─────────→│   سرور  │
│   (شما)  │           │  پروکسی │           │  (سایت)  │
│          │ ←─────────│          │ ←─────────│          │
└──────────┘           └──────────┘           └──────────┘
   IP: 192.168.1.10      IP: 203.0.113.45       IP: 93.184.216.34

سرور IP پروکسی (203.0.113.45) را می‌بیند، نه IP شما را!

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

🔒 امنیت و ناشناس بودن

آدرس IP واقعی شما را از سرورهای مقصد پنهان می‌کند و شما را در اینترنت ناشناس می‌سازد.

🌍 دور زدن محدودیت‌های جغرافیایی

دسترسی به محتوایی را که به دلیل محدودیت‌های جغرافیایی مسدود شده است، فراهم می‌کند.

⚡ کارایی

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

🛡️ فیلترینگ ترافیک

پروکسی‌های سازمانی محتوای ناخواسته را مسدود کرده و از تهدیدات محافظت می‌کنند.

⚖️ توازن بار

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

🔍 نظارت و لاگ‌برداری

تمام درخواست‌ها را برای تحلیل، امنیت یا انطباق با سیاست‌ها ردیابی می‌کند.

💡 تفاوت اصلی با VPN

پروکسی در سطح اپلیکیشن (مثلاً فقط مرورگر) کار می‌کند، در حالی که VPN تمام ترافیک دستگاه را در سطح شبکه رمزگذاری می‌کند. پروکسی سریع‌تر و انعطاف‌پذیرتر است، VPN برای کل ترافیک امن‌تر است.

🎭 نقش پروکسی به عنوان واسطه

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

وظایف پروکسی به عنوان واسطه

۱. تغییر درخواست‌ها

پروکسی می‌تواند هدرهای HTTP را قبل از ارسال درخواست به سرور مقصد تغییر دهد:

User-Agent: اطلاعات مرورگر را تغییر می‌دهد (می‌تواند وانمود کند که Firefox به جای Chrome است)
X-Forwarded-For: اطلاعات IP واقعی کلاینت را اضافه می‌کند
Accept-Language: زبان محتوای ترجیحی را تغییر می‌دهد
Referer: منبع ارجاع را پنهان یا جایگزین می‌کند

۲. بررسی سیاست‌های دسترسی

پروکسی بررسی می‌کند که آیا دسترسی به منبع درخواستی بر اساس موارد زیر مجاز است یا خیر:

آدرس IP کلاینت (لیست‌های سفید/سیاه)
احراز هویت (ورود/رمز عبور، توکن‌ها)
زمان روز (دسترسی به شبکه‌های اجتماعی فقط پس از کار)
دسته بندی محتوا (مسدود کردن بازی‌ها، پورنو، تورنت‌ها)

۳. کش کردن محتوا

پروکسی نسخه‌ای از منابع درخواستی مکرر (تصاویر، CSS، JavaScript) را ذخیره کرده و آن‌ها را از کش ارائه می‌دهد، بدون اینکه به سرور مراجعه کند. این کار ترافیک را ذخیره کرده و بارگذاری را ۵۰ تا ۹۰ درصد تسریع می‌کند.

۴. تغییر پاسخ‌ها

پروکسی می‌تواند محتوا را قبل از ارسال به کلاینت تغییر دهد:

فشرده‌سازی محتوا (gzip, brotli) برای صرفه‌جویی در ترافیک
مسدود کردن تبلیغات و ردیاب‌ها
اضافه/حذف هدرهای امنیتی
تزریق اسکریپت‌ها (مثلاً برای تحلیل سازمانی)

۵. لاگ‌برداری و تحلیل

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

نظارت بر مصرف ترافیک
شناسایی ناهنجاری‌ها و حملات
رعایت سیاست‌های سازمانی
عیب‌یابی و تشخیص مشکلات

⚙️ سه حالت کار پروکسی

🔵 Passthrough (حالت عبور)

پروکسی داده‌ها را بدون تغییر صرفاً عبور می‌دهد. حداقل پردازش، حداکثر سرعت.

🟢 Intercepting (حالت رهگیری)

پروکسی فعالانه درخواست‌ها/پاسخ‌ها را تحلیل و تغییر می‌دهد. برای فیلترینگ، بهینه‌سازی، امنیت استفاده می‌شود.

🟡 Hybrid (حالت ترکیبی)

پروکسی برای هر درخواست تصمیم می‌گیرد: یا بدون تغییر عبور دهد یا پردازش کند. مثلاً فقط محتوای استاتیک را کش کند و درخواست‌های API را مستقیماً عبور دهد.

🔄 شمای درخواست-پاسخ از طریق پروکسی

بیایید ببینیم دقیقاً چه اتفاقی در هر مرحله می‌افتد، زمانی که یک صفحه وب را از طریق سرور پروکسی درخواست می‌کنید.

شمای گام به گام کارکرد پروکسی

گام ۱: کلاینت درخواست را به پروکسی می‌فرستد

GET http://example.com/page.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Proxy-Authorization: Basic dXNlcjpwYXNz
Connection: keep-alive

↓ درخواست به سمت سرور پروکسی می‌رود (نه مستقیماً به example.com)

کلاینت طوری تنظیم شده که از پروکسی استفاده کند، بنابراین حتی برای درخواست به example.com، اتصال با سرور پروکسی برقرار می‌شود.

گام ۲: پروکسی درخواست را دریافت و بررسی می‌کند

سرور پروکسی مجموعه‌ای از بررسی‌ها را انجام می‌دهد:

✅ احراز هویت: نام کاربری/رمز عبور در هدر Proxy-Authorization را بررسی می‌کند
✅ مجوز دسترسی: آیا این کاربر اجازه دسترسی به example.com را دارد؟
✅ فیلترینگ: آیا دامنه example.com توسط سیاست‌ها مسدود شده است؟
✅ کش: آیا نسخه به‌روز شده‌ای از /page.html در کش موجود است؟

گام ۳الف: اگر در کش باشد، بلافاصله برمی‌گرداند

✅ CACHE HIT — در کش یافت شد!

HTTP/1.1 200 OK
Content-Type: text/html
Age: 120
X-Cache: HIT from proxy-server

<html>...محتوای صفحه...</html>

↑ پروکسی محتوا را از کش برمی‌گرداند (بسیار سریع!)

هدر Age: 120 به این معنی است که محتوا ۱۲۰ ثانیه است که در کش قرار دارد.

گام ۳ب: اگر در کش نباشد، از سرور درخواست می‌کند

❌ CACHE MISS — در کش نیست، درخواست به سرور

پروکسی هدرها را تغییر می‌دهد:

GET /page.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
X-Forwarded-For: 192.168.1.10          ← IP واقعی شما را اضافه می‌کند
Via: 1.1 proxy-server                  ← نشان می‌دهد که درخواست از طریق پروکسی است
Connection: keep-alive

↓ پروکسی درخواست را از IP خود به example.com ارسال می‌کند

گام ۴: سرور مقصد درخواست را پردازش می‌کند

سرور example.com درخواست را از پروکسی دریافت کرده و موارد زیر را می‌بیند:

🌐 IP منبع: 203.0.113.45 (IP پروکسی، نه IP شما 192.168.1.10)
📋 X-Forwarded-For: 192.168.1.10 (اختیاری، اگر پروکسی شفاف باشد)
🔗 Via: 1.1 proxy-server (اطلاعات در مورد پروکسی)

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12345
Cache-Control: max-age=3600
Last-Modified: Wed, 13 Jan 2025 10:00:00 GMT

<html>...محتوای صفحه...</html>

گام ۵: پروکسی پاسخ را پردازش می‌کند

پروکسی پاسخ را دریافت کرده و اقدامات زیر را انجام می‌دهد:

💾 کش کردن: محتوا را برای ۳۶۰۰ ثانیه (۱ ساعت) بر اساس Cache-Control ذخیره می‌کند
🗜️ فشرده‌سازی: ممکن است محتوا را برای صرفه‌جویی در ترافیک فشرده کند
🔍 فیلترینگ: محتوا را برای ویروس‌ها بررسی کرده، تبلیغات را مسدود می‌کند
📊 لاگ‌برداری: ثبت می‌کند که چه کسی، چه زمانی، چه چیزی درخواست کرده و حجم پاسخ چقدر بوده است

گام ۶: پروکسی پاسخ را به کلاینت برمی‌گرداند

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12345
X-Cache: MISS from proxy-server        ← درخواست به سرور انجام شد
X-Cache-Lookup: MISS from proxy-server
Via: 1.1 proxy-server

<html>...محتوای صفحه...</html>

↑ کلاینت محتوا را دریافت می‌کند

⚡ کارایی: با کش در مقابل بدون کش

مرحله	بدون کش	با کش
DNS Lookup	50ms	0ms
اتصال TCP	100ms	0ms
TLS Handshake	200ms	0ms
پردازش درخواست	150ms	0ms
انتقال داده	300ms	50ms
مجموع	800ms	50ms (۱۶ برابر سریع‌تر!)

🏗️ معماری پروکسی سرور

پروکسی سرور مدرن یک سیستم پیچیده است که از چندین مؤلفه برای اطمینان از کارایی، امنیت و قابلیت اطمینان همکاری می‌کنند.

اجزای اصلی معماری

۱. Connection Manager (مدیریت اتصالات)

وظایف:

پذیرش اتصالات TCP ورودی از کلاینت‌ها
مدیریت استخر اتصالات به سرورهای مقصد (connection pooling)
استفاده مجدد از اتصالات (HTTP Keep-Alive) برای صرفه‌جویی در منابع
مدیریت تایم‌اوت‌ها و قطع شدن اتصالات

تکنولوژی‌ها: معماری مبتنی بر رویداد (epoll, kqueue)، I/O ناهمزمان

۲. Request Parser (تجزیه‌کننده درخواست)

وظایف:

تجزیه درخواست‌های HTTP (متد، URL، هدرها، بدنه)
اعتبارسنجی صحت درخواست
استخراج پارامترهای احراز هویت
تشخیص نوع درخواست (GET, POST, CONNECT و غیره)

۳. Authentication & Authorization (احراز هویت و مجوز دسترسی)

روش‌های احراز هویت:

Basic Auth: نام کاربری:رمز عبور در base64 (بدون HTTPS ناامن است)
IP Whitelist: دسترسی فقط از آدرس‌های IP مشخص
Token Auth: توکن‌های دسترسی (JWT, OAuth)
Certificate Auth: گواهی‌های SSL کلاینت

۴. Cache Engine (موتور کش)

وظایف:

ذخیره کپی منابع در حافظه/دیسک
بررسی به‌روز بودن کش (Cache-Control, ETag, Last-Modified)
استفاده از الگوریتم‌های جایگزینی (LRU, LFU) در صورت کمبود فضا
پشتیبانی از درخواست‌های شرطی (If-Modified-Since, If-None-Match)

محل ذخیره‌سازی: Memcached, Redis, Varnish، پیاده‌سازی‌های اختصاصی

۵. Upstream Handler (مدیریت سرورهای بالادستی)

وظایف:

انتخاب سرور مقصد از لیست (توازن بار)
برقراری اتصال با سرور بالادستی
ارسال درخواست با هدرهای اصلاح شده
مدیریت خطاها و منطق تلاش مجدد (retry)

۶. Response Processor (پردازشگر پاسخ)

وظایف:

تغییر هدرهای پاسخ
فشرده‌سازی محتوا (gzip, brotli)
فیلتر کردن/مسدود کردن محتوای ناخواسته
اضافه کردن هدرهای امنیتی و کش

۷. Logging & Monitoring (لاگ‌برداری و نظارت)

چه چیزی لاگ می‌شود:

مهر زمانی، IP کلاینت، URL درخواستی
کد پاسخ، حجم داده منتقل شده
زمان پردازش درخواست
آمار کش hit/miss
خطاها و ناهنجاری‌ها

↔️ پروکسی فوروارد در مقابل ریورس

دو نوع اصلی پروکسی سرور وجود دارد که نقش‌های متضادی را ایفا می‌کنند: پروکسی فوروارد (Forward Proxy) از کلاینت‌ها محافظت می‌کند، پروکسی ریورس (Reverse Proxy) از سرورها محافظت می‌کند.

➡️ پروکسی فوروارد

کلاینت‌ها → پروکسی فوروارد → اینترنت

کلاینت۱ ┐
کلاینت۲ ├─→ پروکسی → سرور۱
کلاینت۳ ┘    فوروارد   سرور۲
                        سرور۳

ویژگی‌ها:

استفاده کننده: کلاینت‌ها (کاربران)
هدف: پنهان کردن کلاینت‌ها از سرورها
مکان: سمت کلاینت
آگاه از پروکسی: کلاینت‌ها

مثال‌های کاربرد:

✅ دور زدن مسدودسازی‌ها و سانسور
✅ ناشناس ماندن در اینترنت
✅ فیلتر محتوای سازمانی
✅ وب اسکرپینگ با چرخش IP
✅ دور زدن محدودیت‌های جغرافیایی

راه‌حل‌های رایج:

Squid, ProxyCove, پروکسی‌های مسکونی (Residential Proxies), پروکسی SOCKS5

⬅️ پروکسی ریورس

اینترنت → پروکسی ریورس → سرورها

کلاینت۱     پروکسی  ┌─→ بک‌اند۱
کلاینت۲  ──→ ریورس ─┼─→ بک‌اند۲
کلاینت۳          └─→ بک‌اند۳

ویژگی‌ها:

استفاده کننده: صاحبان سرورها
هدف: محافظت و بهینه‌سازی سرورها
مکان: سمت سرور
آگاه از پروکسی: مدیران سیستم

مثال‌های کاربرد:

✅ توازن بار (Load Balancing)
✅ خاتمه SSL/TLS
✅ کش کردن محتوای استاتیک
✅ محافظت در برابر حملات DDoS
✅ پنهان کردن سرورهای واقعی

راه‌حل‌های رایج:

Nginx, HAProxy, Cloudflare, AWS ELB, Varnish

🔍 جدول مقایسه

پارامتر	پروکسی فوروارد	پروکسی ریورس
محافظت از	کلاینت‌ها	سرورها
قابلیت مشاهده	کلاینت‌ها از پروکسی آگاهند	کلاینت‌ها آگاه نیستند
IP که سرور می‌بیند	IP پروکسی	IP کلاینت (از طریق X-Forwarded-For)
تنظیمات	روی کلاینت	روی سرور
کش کردن	برای تسریع کلاینت‌ها	برای کاهش بار سرورها
کاربرد معمول	ناشناس ماندن، دور زدن مسدودسازی	توازن بار، امنیت

👁️ پروکسی شفاف در مقابل صریح

پروکسی سرورها همچنین بر اساس اینکه آیا کلاینت از وجود پروکسی آگاه است، طبقه‌بندی می‌شوند: شفاف (Transparent) و صریح (Explicit).

👻 پروکسی شفاف

نحوه کارکرد:

پروکسی ترافیک را در سطح شبکه (از طریق روتر یا فایروال) بدون نیاز به تنظیمات کلاینت رهگیری می‌کند. کلاینت فکر می‌کند مستقیماً به سرور متصل می‌شود، اما ترافیک از پروکسی عبور می‌کند.

کلاینت فکر می‌کند:
GET example.com → مستقیماً

در واقعیت:
GET example.com → [پروکسی شفاف] → example.com

کلاینت از پروکسی اطلاعی ندارد!

ویژگی‌ها:

✅ نیازی به تنظیمات در کلاینت ندارد
✅ برای تمام اپلیکیشن‌ها به طور خودکار کار می‌کند
⚠️ از متدهای معمولی GET/POST استفاده می‌کند
⚠️ کار با HTTPS دشوار است (نیاز به MITM)
❌ پشتیبانی از احراز هویت کلاینت ندارد

کاربرد:

شبکه‌های سازمانی (فیلترینگ بدون تنظیمات)
پروکسی ISP (کش کردن محتوا توسط ارائه‌دهنده)
کنترل والدین در وای‌فای عمومی

📢 پروکسی صریح

نحوه کارکرد:

کلاینت صراحتاً برای استفاده از پروکسی تنظیم شده است. تمام درخواست‌ها به سرور پروکسی ارسال می‌شوند که سپس آن‌ها را به سرورهای مقصد فوروارد می‌کند.

مرورگر برای پروکسی تنظیم شده:
Proxy: proxy.example.com:8080

درخواست HTTP:
GET http://example.com/ HTTP/1.1
Host: example.com
Proxy-Authorization: Basic xyz123

درخواست HTTPS:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic xyz123

ویژگی‌ها:

✅ کلاینت از پروکسی آگاه است
✅ پشتیبانی از احراز هویت
✅ استفاده از متد CONNECT برای HTTPS
✅ کنترل کامل در سطح اپلیکیشن
⚠️ نیاز به تنظیمات در هر اپلیکیشن

کاربرد:

ناشناس ماندن شخصی (ProxyCove)
وب اسکرپینگ و پارسینگ
تست با IPهای مختلف
مدیریت چند اکانت

🔑 تفاوت کلیدی: متد CONNECT

پروکسی شفاف برای HTTPS درخواست‌های CONNECT دریافت نمی‌کند، زیرا مرورگر فکر می‌کند مستقیماً متصل می‌شود. از متدهای GET/POST معمولی استفاده می‌کند.

پروکسی صریح درخواست‌های CONNECT برای HTTPS دریافت می‌کند، که به پروکسی اجازه می‌دهد یک تونل بدون رمزگشایی ترافیک ایجاد کند (رمزگذاری سرتاسری حفظ می‌شود).

پروکسی‌های حرفه‌ای برای هر نیازی

حالا می‌دانید پروکسی‌ها چگونه کار می‌کنند — وقت آن است که از این دانش در عمل استفاده کنید!
ProxyCove — زیرساخت مدرن با پروکسی در ۱۹۵+ کشور.
ثبت‌نام با کد تخفیف ARTHELLO = +$1.3 اعتبار اولیه

شروع با ProxyCove →

تعرفه‌های ProxyCove ۲۰۲۵:

🏠 مسکونی (Residential) — ۲.۷ دلار/گیگ 📱 موبایل (Mobile) — ۳.۸ دلار/گیگ 🏢 دیتاسنتر (Datacenter) — ۱.۵ دلار/گیگ

📖 ادامه در بخش ۲: جزئیات فنی — پروتکل‌ها (HTTP، SOCKS)، هدرها، متد CONNECT، TLS Handshake از طریق پروکسی و ویژگی‌های کار با HTTPS.

نحوه کار پروکسی سرور — بخش ۲

جزئیات فنی: پروتکل‌های HTTP و SOCKS، هدرها، متد CONNECT، TLS Handshake از طریق پروکسی و ویژگی‌های کار با HTTPS.

به‌روزرسانی شده: ژانویه ۲۰۲۵ | زمان مطالعه: ۱۷ دقیقه | سطح: پیشرفته

🔌 پروتکل‌های پروکسی سرورها

پروکسی سرورها از پروتکل‌های مختلفی برای ارتباط با کلاینت‌ها استفاده می‌کنند. هر پروتکل ویژگی‌ها، مزایا و محدودیت‌های خاص خود را دارد.

پروتکل‌های اصلی

۱. پروکسی HTTP

سطح OSI: لایه کاربرد (Layer 7)
پروکسی چه چیزی را منتقل می‌کند: فقط ترافیک HTTP/HTTPS
پروتکل‌ها: HTTP/1.1, HTTP/2, HTTP/3
ویژگی‌ها: هدرهای HTTP را درک می‌کند، می‌تواند درخواست‌ها را تغییر دهد
استفاده: مرورگرها، کلاینت‌های API، وب اسکرپرها

۲. پروکسی HTTPS (HTTP CONNECT)

سطح OSI: لایه کاربرد (Layer 7)
پروکسی چه چیزی را منتقل می‌کند: HTTPS از طریق تونل‌سازی
متد: HTTP CONNECT برای ایجاد تونل
ویژگی‌ها: محتوای HTTPS را نمی‌بیند (رمزگذاری سرتاسری)
استفاده: پروکسی امن HTTPS

۳. پروکسی SOCKS4

سطح OSI: لایه جلسه (Layer 5)
پروکسی چه چیزی را منتقل می‌کند: فقط اتصالات TCP
ویژگی‌ها: پروتکل ساده، از UDP و احراز هویت پشتیبانی نمی‌کند
استفاده: در سال ۲۰۲۵ به ندرت استفاده می‌شود

۴. پروکسی SOCKS5

سطح OSI: لایه جلسه (Layer 5)
پروکسی چه چیزی را منتقل می‌کند: ترافیک TCP و UDP (هر پروتکلی)
ویژگی‌ها: پشتیبانی از احراز هویت، UDP، IPv6
استفاده: تورنت‌ها، بازی‌ها، VoIP، پروکسی‌سازی همه‌منظوره

📊 مقایسه پروتکل‌ها

ویژگی	HTTP	HTTPS	SOCKS4	SOCKS5
ترافیک HTTP	✅	✅	✅	✅
ترافیک HTTPS	❌	✅	✅	✅
FTP, SMTP, POP3	❌	❌	✅	✅
ترافیک UDP	❌	❌	❌	✅
احراز هویت	✅	✅	❌	✅
سرعت	بالا	بالا	بسیار بالا	بسیار بالا
کش کردن	✅	✅	❌	❌

🌐 پروکسی HTTP به تفصیل

پروکسی HTTP در لایه کاربرد کار می‌کند و ساختار پروتکل HTTP را درک می‌کند، که به آن اجازه می‌دهد درخواست‌ها را تحلیل و تغییر دهد.

درخواست از طریق پروکسی HTTP

درخواست HTTP معمولی (بدون پروکسی)

GET /api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Connection: keep-alive

→ مستقیماً به api.example.com ارسال می‌شود

درخواست HTTP از طریق پروکسی

GET http://api.example.com/api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
Proxy-Connection: keep-alive

→ به سرور پروکسی ارسال می‌شود (نه به api.example.com!)

تفاوت‌ها:

URL در خط اول — کامل (با پروتکل و دامنه)
هدر Proxy-Authorization اضافه شده است
از Proxy-Connection به جای Connection استفاده می‌شود

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

۱. پروکسی درخواست کلاینت را دریافت می‌کند
۲. Proxy-Authorization (نام کاربری:رمز عبور) را بررسی می‌کند
۳. URL مقصد را استخراج می‌کند: http://api.example.com/api/users
۴. درخواست را برای ارسال به سرور تغییر می‌دهد:

GET /api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
X-Forwarded-For: 192.168.1.100        ← IP کلاینت اضافه می‌شود
Via: 1.1 proxy-server.com              ← اطلاعات در مورد پروکسی
X-Real-IP: 192.168.1.100               ← IP واقعی کلاینت
Connection: keep-alive

۵. درخواست تغییر یافته را به api.example.com ارسال می‌کند
۶. پاسخ را از api.example.com دریافت می‌کند
۷. پاسخ را به کلاینت فوروارد می‌کند

🔐 احراز هویت در پروکسی HTTP

Basic Authentication

نام کاربری و رمز عبور در base64 کدگذاری شده و در هدر ارسال می‌شود:

Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==

به صورت: user:password رمزگشایی می‌شود

⚠️ توجه: Base64 رمزنگاری نیست!
فقط با پروکسی HTTPS استفاده کنید!

Digest Authentication

روش امن‌تر با استفاده از هش کردن:

۱. کلاینت → پروکسی: GET http://example.com/ HTTP/1.1
۲. پروکسی → کلاینت: 407 Proxy Authentication Required
   Proxy-Authenticate: Digest realm="proxy", nonce="abc123"
۳. کلاینت هش را محاسبه می‌کند:
   hash = MD5(username:realm:password)
   response = MD5(hash:nonce:MD5(method:uri))
۴. کلاینت → پروکسی:
   Proxy-Authorization: Digest username="user",
                                 response="xyz789",
                                 nonce="abc123"

🔒 متد HTTP CONNECT

CONNECT یک متد HTTP ویژه است که پروکسی را به یک تونل TCP تبدیل می‌کند. این اجازه می‌دهد تا ترافیک HTTPS بدون رمزگشایی پروکسی شود.

نحوه کارکرد CONNECT

گام ۱: کلاینت درخواست تونل می‌کند

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
User-Agent: Mozilla/5.0

→ کلاینت از پروکسی می‌خواهد یک اتصال TCP به example.com:443 برقرار کند

نکته مهم: CONNECT برای پورت ۴۴۳ (HTTPS) استفاده می‌شود، نه پورت ۸۰ (HTTP).

گام ۲: پروکسی اتصال را برقرار می‌کند

پروکسی اقدامات زیر را انجام می‌دهد:
۱. Proxy-Authorization را بررسی می‌کند
۲. یک اتصال TCP به example.com:443 برقرار می‌کند
۳. به کلاینت پاسخ می‌دهد:

HTTP/1.1 200 Connection established

→ تونل برقرار شد! اکنون پروکسی صرفاً بایت‌ها را منتقل می‌کند.

گام ۳: کلاینت TLS Handshake را آغاز می‌کند

کلاینت → پروکسی → سرور: ClientHello (آغاز TLS)
[نسخه: TLS 1.3]
[SNI: example.com] ← سیستم‌های DPI می‌توانند این را ببینند!
[Cipher Suites: ...]

سرور → پروکسی → کلاینت: ServerHello, Certificate
[گواهی سرور برای example.com]

...TLS handshake کامل می‌شود...

→ پروکسی محتوا را نمی‌بیند! فقط بایت‌ها را منتقل می‌کند.
   رمزگذاری سرتاسری بین کلاینت و سرور حفظ می‌شود.

گام ۴: تبادل داده‌های رمزگذاری شده

کلاینت → پروکسی → سرور: [داده‌های رمزگذاری شده]
سرور → پروکسی → کلاینت: [داده‌های رمزگذاری شده]

پروکسی فقط موارد زیر را می‌بیند:
- حجم داده منتقل شده
- زمان انتقال
- آدرس IP مقصد

پروکسی موارد زیر را نمی‌بیند:
- URL درخواست
- هدرهای HTTP
- محتوای صفحه
- کوکی‌ها و رمزهای عبور

📊 HTTP در مقابل CONNECT — چه چیزی پروکسی می‌بیند

اطلاعات	HTTP (پورت ۸۰)	CONNECT (پورت ۴۴۳)
دامنه	✅ می‌بیند	✅ می‌بیند
مسیر URL	✅ کامل می‌بیند	❌ نمی‌بیند
هدرهای HTTP	✅ همه را می‌بیند	❌ نمی‌بیند
محتوای صفحه	✅ کل HTML را می‌بیند	❌ رمزگذاری شده
رمزهای عبور و کوکی‌ها	✅ می‌بیند (خطرناک!)	❌ رمزگذاری شده
حجم ترافیک	✅ می‌بیند	✅ می‌بیند

⚠️ مهم برای امنیت!

هرگز از پروکسی HTTP معمولی برای وارد کردن رمزهای عبور استفاده نکنید!
پروکسی همه چیز را به صورت متن آشکار می‌بیند. همیشه از سایت‌های HTTPS از طریق متد CONNECT یا ارائه‌دهندگان پروکسی معتبر استفاده کنید.

🧦 پروتکل SOCKS

SOCKS (Socket Secure) پروتکلی است که در سطح پایین‌تری نسبت به HTTP کار می‌کند و می‌تواند هر ترافیک TCP/UDP را پروکسی کند.

SOCKS5 Handshake

مرحله ۱: انتخاب متد احراز هویت

کلاینت → سرور:
┌─────┬─────┬──────────────────┐
│0x05 │0x02 │0x00 0x02         │
└─────┴─────┴──────────────────┘
  VER  NMETHODS  روش‌ها

0x05 = نسخه SOCKS 5
0x02 = ۲ روش احراز هویت پیشنهاد شده
0x00 = بدون احراز هویت
0x02 = Username/Password

سرور → کلاینت:
┌─────┬────────┐
│0x05 │0x02    │
└─────┴────────┘
  VER   روش

0x02 = روش Username/Password انتخاب شد

مرحله ۲: احراز هویت (در صورت نیاز)

کلاینت → سرور:
┌─────┬──────┬──────────┬──────┬──────────┐
│0x01 │ ULEN │ USERNAME │ PLEN │ PASSWORD │
└─────┴──────┴──────────┴──────┴──────────┘

0x01 = نسخه زیرمجموعه
ULEN = طول نام کاربری
USERNAME = نام کاربری
PLEN = طول رمز عبور
PASSWORD = رمز عبور

سرور → کلاینت:
┌─────┬────────┐
│0x01 │0x00    │
└─────┴────────┘
  VER   وضعیت

0x00 = احراز هویت موفقیت‌آمیز بود

مرحله ۳: درخواست اتصال

کلاینت → سرور:
┌─────┬─────┬─────┬──────┬──────────┬──────┐
│0x05 │CMD  │0x00 │ATYP  │DST.ADDR  │PORT  │
└─────┴─────┴─────┴──────┴──────────┴──────┘

0x05 = SOCKS5
CMD:
  0x01 = CONNECT (اتصال TCP)
  0x02 = BIND (انتظار اتصال ورودی)
  0x03 = UDP ASSOCIATE (انتقال UDP)
0x00 = رزرو شده
ATYP:
  0x01 = آدرس IPv4 (۴ بایت)
  0x03 = نام دامنه (متغیر)
  0x04 = آدرس IPv6 (۱۶ بایت)

مثال برای example.com:443
0x05 0x01 0x00 0x03 0x0B example.com 0x01BB

سرور → کلاینت:
┌─────┬─────┬─────┬──────┬──────────┬──────┐
│0x05 │0x00 │0x00 │0x01  │0.0.0.0   │0x0000│
└─────┴─────┴─────┴──────┴──────────┴──────┘

0x00 = اتصال با موفقیت برقرار شد

مرحله ۴: انتقال داده

پس از برقراری اتصال، پروکسی SOCKS مانند یک تونل TCP عمل می‌کند:

کلاینت → SOCKS → سرور: [داده‌های اپلیکیشن]
سرور → SOCKS → کلاینت: [داده‌های اپلیکیشن]

SOCKS صرفاً بایت‌ها را بدون تحلیل محتوا منتقل می‌کند!

مزایای SOCKS5

✅ همه‌کاره بودن: کار با هر پروتکلی (HTTP, FTP, SMTP, BitTorrent, بازی‌ها)
✅ پشتیبانی از UDP: تنها پروتکل پروکسی با پشتیبانی کامل UDP
✅ کارایی: سربار کم، بسیار سریع
✅ امنیت: ترافیک را تحلیل نمی‌کند، شفافیت کامل برای اپلیکیشن‌ها
✅ پشتیبانی از IPv6: پشتیبانی بومی از آدرس‌های IPv6

🔐 SSL/TLS Handshake از طریق پروکسی

درک نحوه عملکرد TLS در پروکسی‌ها برای امنیت حیاتی است. در سال ۲۰۲۵، TLS 1.3 استاندارد است.

فرآیند کامل HTTPS از طریق پروکسی

۱. کلاینت → پروکسی: TCP Handshake
   SYN → SYN-ACK → ACK (اتصال با پروکسی برقرار شد)

۲. کلاینت → پروکسی: HTTP CONNECT
   CONNECT example.com:443 HTTP/1.1
   Host: example.com:443
   Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
   User-Agent: Mozilla/5.0

۳. پروکسی → سرور: TCP Handshake
   (پروکسی اتصالی به example.com:443 برقرار می‌کند)

۴. پروکسی → کلاینت: 200 Connection established

۵. کلاینت → پروکسی → سرور: TLS ClientHello
   [نسخه: TLS 1.3]
   [Cipher Suites: TLS_AES_128_GCM_SHA256, ...]
   [SNI: example.com] ← سیستم‌های DPI می‌توانند این را ببینند!
   [Supported Groups: x25519, secp256r1]

۶. سرور → پروکسی → کلاینت: TLS ServerHello
   [Cipher انتخاب شده: TLS_AES_128_GCM_SHA256]
   [گواهی سرور برای example.com]
   [Key Share]

۷. کلاینت → پروکسی → سرور: TLS Finished
   [Client Key Exchange - رمزگذاری شده]
   [Change Cipher Spec]

۸. سرور → پروکسی → کلاینت: TLS Finished
   [Server Finished - رمزگذاری شده]

۹. جلسه رمزگذاری شده برقرار شد
   کلاینت ⇄ پروکسی ⇄ سرور: [تمام داده‌های بعدی رمزگذاری شده‌اند]

   GET /api/secret HTTP/1.1
   Host: example.com
   Authorization: Bearer secret_token_12345

   ↑ پروکسی این درخواست را نمی‌بیند! فقط بایت‌های رمزگذاری شده.

⚠️ اطلاعاتی که سیستم‌های DPI ممکن است ببینند

حتی از طریق تونل CONNECT، سیستم‌های DPI (بازرسی عمیق بسته) می‌توانند اطلاعاتی را استخراج کنند:

📌 SNI (Server Name Indication): نام دامنه در ClientHello (در TLS 1.2 و پایین‌تر به صورت آشکار ارسال می‌شود)
📌 آدرس IP مقصد: مقصد اتصال
📌 حجم ترافیک: میزان داده منتقل شده
📌 الگوهای زمان‌بندی: الگوهای فعالیت ممکن است نوع محتوا را مشخص کنند

🛡️ محافظت: ECH (Encrypted Client Hello)

در سال ۲۰۲۵، سرورهای مدرن از ECH (Encrypted Client Hello) پشتیبانی می‌کنند — یک استاندارد TLS 1.3 که SNI را رمزگذاری می‌کند. این کار شناسایی دامنه از طریق DPI را غیرممکن می‌سازد.

🔓 SSL Interception (پروکسی MITM)

برخی پروکسی‌های سازمانی SSL Interception — رمزگشایی ترافیک HTTPS — را انجام می‌دهند:

کلاینت → [TLS به پروکسی] → پروکسی → [TLS به سرور] → سرور

پروکسی دو بار TLS Handshake انجام می‌دهد:
۱. با کلاینت (با استفاده از گواهی خود)
۲. با سرور (از طرف کلاینت)

پروکسی همه محتوا را می‌بیند!

⚠️ نیاز به نصب گواهی ریشه پروکسی روی کلاینت دارد
⚠️ مرورگر در صورت عدم اعتماد به گواهی هشدار می‌دهد

کاربرد: شبکه‌های سازمانی برای نظارت بر کارمندان، آنتی‌ویروس‌ها برای بررسی HTTPS، سیستم‌های DLP.

📋 هدرهای HTTP مهم برای پروکسی

X-Forwarded-For

شامل آدرس IP واقعی کلاینت است. توسط پروکسی اضافه می‌شود.

X-Forwarded-For: 192.168.1.100

X-Real-IP

جایگزینی برای X-Forwarded-For، شامل یک IP است.

X-Real-IP: 192.168.1.100

Via

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

Via: 1.1 proxy1, 1.1 proxy2

X-Forwarded-Proto

پروتکل درخواست اصلی (http/https) را مشخص می‌کند.

X-Forwarded-Proto: https

X-Forwarded-Host

هدر Host اصلی که کلاینت ارسال کرده است.

X-Forwarded-Host: example.com

Proxy-Authorization

اعتبارات لازم برای احراز هویت در سرور پروکسی.

Proxy-Authorization: Basic xyz123

🔍 سرور چگونه پروکسی را تشخیص می‌دهد؟

سرور می‌تواند پروکسی را بر اساس نشانه‌های زیر شناسایی کند:

وجود هدرهای X-Forwarded-* و Via
آدرس IP از پایگاه داده شناخته شده پروکسی‌ها
عدم تطابق موقعیت جغرافیایی IP با سایر پارامترها (زبان، منطقه زمانی)
الگوهای فعالیت غیرعادی (درخواست‌های بسیار سریع)

💾 مکانیزم‌های کش کردن در پروکسی

کش کردن یکی از عملکردهای کلیدی سرورهای پروکسی است که می‌تواند سرعت بارگذاری محتوا را ۵۰ تا ۹۰ درصد افزایش داده و بار روی سرورهای بک‌اند را کاهش دهد.

نحوه کار کش کردن

الگوریتم تصمیم‌گیری برای کش کردن

۱. درخواست به پروکسی می‌رسد
   GET /images/logo.png

۲. پروکسی کلید کش را محاسبه می‌کند:
   key = hash(method + URL + headers)
   key = "GET:example.com:/images/logo.png"

۳. بررسی کش:
   if (کش وجود دارد AND کش معتبر است):
       ✅ CACHE HIT
       - بررسی Cache-Control: max-age
       - بررسی هدر Expires
       - اگر معتبر است → از کش برگردانده می‌شود
       - اگر منقضی شده → درخواست شرطی (If-Modified-Since)
   else:
       ❌ CACHE MISS
       - درخواست از سرور اصلی (origin)
       - اگر قابل کش شدن است → در کش ذخیره می‌شود
       - به کلاینت برگردانده می‌شود

۴. تعیین اینکه آیا می‌توان کش کرد:
   ✅ بله، اگر:
      - متد HTTP: GET یا HEAD
      - وضعیت: 200, 301, 304, 404
      - Cache-Control: public, max-age > 0
      - هدرهای: Set-Cookie, Authorization وجود نداشته باشد
   ❌ خیر، اگر:
      - Cache-Control: no-store, private
      - Pragma: no-cache
      - درخواست‌های POST, PUT, DELETE
      - محتوای داینامیک با Set-Cookie

هدرهای کش کردن

هدر	مقدار	اقدام پروکسی
Cache-Control: max-age=3600	کش کردن به مدت ۱ ساعت	✅ کش می‌کند
Cache-Control: no-cache	همیشه با سرور بررسی شود	⚠️ درخواست شرطی
Cache-Control: no-store	هرگز کش نشود	❌ کش نمی‌کند
Cache-Control: public	قابل کش عمومی است	✅ کش می‌کند
Cache-Control: private	فقط برای یک کلاینت	❌ کش نمی‌کند
ETag: "abc123"	شناسه نسخه	✅ برای اعتبارسنجی
Last-Modified: date	تاریخ آخرین تغییر	✅ برای اعتبارسنجی

درخواست‌های شرطی (Conditional Requests)

هنگامی که کش منقضی می‌شود، پروکسی می‌تواند با درخواست‌های شرطی، به‌روز بودن را بررسی کند:

سناریو ۱: بررسی بر اساس ETag
────────────────────────────────────
پروکسی → سرور:
GET /image.jpg HTTP/1.1
If-None-Match: "abc123"

اگر فایل تغییر نکرده باشد:
سرور → پروکسی:
HTTP/1.1 304 Not Modified
ETag: "abc123"

→ پروکسی از کش استفاده می‌کند (صرفه‌جویی در ترافیک!)

اگر فایل تغییر کرده باشد:
سرور → پروکسی:
HTTP/1.1 200 OK
ETag: "xyz789"
[محتوای جدید]

→ پروکسی کش را به‌روز می‌کند


سناریو ۲: بررسی بر اساس تاریخ
────────────────────────────────────
پروکسی → سرور:
GET /style.css HTTP/1.1
If-Modified-Since: Wed, 13 Jan 2025 10:00:00 GMT

سرور → پروکسی:
HTTP/1.1 304 Not Modified

→ کش معتبر است، از کش استفاده می‌کنیم

الگوریتم‌های جایگزینی کش

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

۱. LRU (کمترین استفاده اخیر)

عناصری که اخیراً کمتر به آن‌ها دسترسی شده، حذف می‌شوند. محبوب‌ترین الگوریتم.

image1.jpg (آخرین دسترسی: ۲ دقیقه پیش)
style.css (آخرین دسترسی: ۱۰ دقیقه پیش) ← اولین مورد حذف شده
logo.png (آخرین دسترسی: ۱ دقیقه پیش)

۲. LFU (کمترین استفاده مکرر)

عناصری که کمترین دفعات درخواست شده‌اند، حذف می‌شوند.

logo.png (درخواست‌ها: ۱۰۰۰)
style.css (درخواست‌ها: ۵۰) ← اولین مورد حذف شده
image1.jpg (درخواست‌ها: ۵۰۰)

۳. FIFO (اولین ورودی، اولین خروجی)

قدیمی‌ترین عناصر حذف می‌شوند. ساده اما همیشه کارآمد نیست.

۴. الگوریتم‌های آگاه از اندازه

اندازه عناصر را در نظر می‌گیرند. مثلاً فایل‌های بزرگ با دسترسی کم را حذف می‌کنند تا فضای بیشتری برای فایل‌های کوچک پرطرفدار آزاد شود.

📊 کارایی کش کردن

آمار معمول کش پروکسی وب:

📈 نرخ Hit: ۶۰ تا ۸۰٪ برای محتوای استاتیک (تصاویر، CSS، JS)
📉 نرخ Hit: ۵ تا ۲۰٪ برای محتوای داینامیک (API، HTML)
⚡ تسریع: Cache hit در ۱۰ تا ۵۰ میلی‌ثانیه در مقابل ۲۰۰ تا ۸۰۰ میلی‌ثانیه برای cache miss
💾 صرفه‌جویی در ترافیک: کاهش ۴۰ تا ۷۰ درصدی ترافیک خروجی به سرور اصلی
🔋 کاهش بار: ۵۰ تا ۹۰٪ کاهش درخواست‌ها به سرورهای بک‌اند

⚖️ توازن بار (Load Balancing)

پروکسی ریورس اغلب برای توزیع بار بین چندین سرور بک‌اند استفاده می‌شود تا دسترسی بالا و مقیاس‌پذیری تضمین شود.

الگوریتم‌های توازن بار

۱. Round Robin (دورانی)

درخواست‌ها به ترتیب بین سرورها توزیع می‌شوند.

درخواست ۱ → سرور A
درخواست ۲ → سرور B
درخواست ۳ → سرور C
درخواست ۴ → سرور A (چرخه تکرار می‌شود)

✅ مزایا: سادگی، توزیع یکنواخت
❌ معایب: بار سرورها را در نظر نمی‌گیرد

۲. Least Connections (کمترین اتصالات)

درخواست جدید به سروری ارسال می‌شود که کمترین تعداد اتصالات فعال را دارد.

سرور A: ۵ اتصال
سرور B: ۲ اتصال ← درخواست جدید به اینجا می‌رود
سرور C: ۸ اتصال

✅ مزایا: در نظر گرفتن بار فعلی
✅ ایده‌آل برای اتصالات طولانی‌مدت (WebSocket، استریم)

۳. IP Hash (هش بر اساس IP)

سرور بر اساس هش آدرس IP کلاینت انتخاب می‌شود. یک کلاینت همیشه به یک سرور می‌رود.

hash(192.168.1.100) % 3 = 1 → سرور B
hash(192.168.1.200) % 3 = 0 → سرور A
hash(192.168.1.150) % 3 = 2 → سرور C

✅ مزایا: حفظ نشست (Session persistence) بدون نیاز به sticky sessions
❌ معایب: توزیع نامتوازن در صورت کم بودن تعداد کلاینت‌ها

۴. Weighted Round Robin (دورانی با وزن‌دهی)

به سرورها بر اساس توانایی‌شان وزن داده می‌شود.

سرور A (وزن: ۵) → ۵ درخواست دریافت می‌کند
سرور B (وزن: ۲) → ۲ درخواست دریافت می‌کند
سرور C (وزن: ۳) → ۳ درخواست دریافت می‌کند

مجموعاً ۱۰ درخواست با نسبت ۵:۲:۳ توزیع می‌شوند

✅ ایده‌آل برای سرورهای نابرابر (با قدرت متفاوت)

۵. Least Response Time (کمترین زمان پاسخ)

سروری انتخاب می‌شود که کمترین زمان پاسخ و کمترین تعداد اتصالات را داشته باشد.

سرور A: ۵۰ms، ۱۰ اتصال
سرور B: ۳۰ms، ۵ اتصال ← انتخاب می‌شود
سرور C: ۱۰۰ms، ۳ اتصال

✅ بهترین کارایی برای کلاینت‌ها
⚠️ نیاز به نظارت بر سلامت (health checks) دارد

🏥 بررسی سلامت (Health Checks)

Load balancer به طور مداوم دسترسی‌پذیری سرورهای بک‌اند را بررسی می‌کند:

بررسی‌های فعال (Active Health Checks)

پروکسی به طور فعال درخواست‌هایی را برای بررسی ارسال می‌کند:

هر ۵ ثانیه:
GET /health HTTP/1.1
Host: backend-server

پاسخ 200 OK → سرور سالم است ✅
پاسخ 5xx یا تایم‌اوت → سرور در دسترس نیست ❌

بررسی‌های غیرفعال (Passive Health Checks)

تحلیل درخواست‌های واقعی کلاینت‌ها:

اگر در ۱۰ درخواست آخر:
- ۵ مورد با خطای 5xx برگشتند
- ۳ مورد با تایم‌اوت مواجه شدند
→ سرور برای ۳۰ ثانیه به عنوان ناسالم علامت‌گذاری می‌شود

💼 مثال‌های کاربردی

🕷️

وب اسکرپینگ

وظیفه: پارس کردن ۱۰۰,۰۰۰ صفحه بدون مسدود شدن.

راه‌حل:

پروکسی‌های مسکونی چرخشی (Rotating residential)
تغییر IP هر ۱۰ درخواست
استفاده از SOCKS5 برای انعطاف‌پذیری
محدودیت نرخ: ۲ درخواست در ثانیه برای هر IP

نتیجه: ۰٪ مسدودسازی، ۹۵٪ درخواست موفق

🎯

تأیید تبلیغات

وظیفه: بررسی نمایش تبلیغات در ۵۰ کشور.

راه‌حل:

پروکسی‌های مبتنی بر موقعیت جغرافیایی (بر اساس کشور)
IPهای مسکونی برای واقع‌گرایی
گرفتن اسکرین‌شات از طریق مرورگر Headless
چرخش هدرهای User-Agent

نتیجه: تأیید دقیق محل نمایش تبلیغات

💰

نظارت بر قیمت

وظیفه: نظارت ۲۴/۷ بر قیمت رقبا.

راه‌حل:

پروکسی‌های دیتاسنتر (ارزان‌تر)
درخواست‌های زمان‌بندی شده هر ۲ ساعت
استفاده از چندین ارائه‌دهنده پروکسی
استفاده از پروکسی مسکونی به عنوان جایگزین در صورت مسدود شدن

نتیجه: هوش قیمتی بلادرنگ

🎮

ربات کفش (Sneaker Botting)

وظیفه: خرید کفش‌های محدود (drop).

راه‌حل:

پروکسی‌های مسکونی (برای دور زدن ضد ربات)
پروکسی‌های ISP برای مرحله پرداخت (پایداری)
یک IP = یک اکانت
تأخیر کم (<۵۰ms)

نتیجه: خرید موفق قبل از اتمام موجودی

📱

مدیریت شبکه‌های اجتماعی

وظیفه: مدیریت بیش از ۱۰۰ اکانت اینستاگرام.

راه‌حل:

پروکسی‌های موبایل (IPهای 4G/5G)
نشست‌های چسبنده (Sticky sessions) (۱۰-۳۰ دقیقه)
یک اکانت = یک پروکسی (برای جلوگیری از اثر انگشت)
تطابق جغرافیایی: اکانت و پروکسی از یک کشور باشند

نتیجه: ۰ بن، تعامل طبیعی

🌐

ردیابی رتبه SEO

وظیفه: ردیابی موقعیت‌ها در گوگل بر اساس مناطق مختلف.

راه‌حل:

پروکسی‌های با موقعیت جغرافیایی دقیق (شهر/منطقه)
استفاده از پروکسی‌های مسکونی برای دقت نتایج
نرخ درخواست پایین (۱-۲ در دقیقه)
پارس کردن SERP با سیستم‌های ضد کپچا

نتیجه: موقعیت‌های محلی دقیق

🎯 انتخاب نوع پروکسی برای کار شما

وظیفه	نوع پروکسی	پروتکل	هزینه
وب اسکرپینگ	مسکونی (Residential)	HTTP/SOCKS5	۲.۷ دلار/گیگ
شبکه‌های اجتماعی (اینستاگرام، تیک‌تاک)	موبایل 4G/5G	HTTP/SOCKS5	۳.۸ دلار/گیگ
نظارت بر قیمت (سایت‌های ساده)	دیتاسنتر	HTTP	۱.۵ دلار/گیگ
ربات‌های کفش (Sneaker Bots)	مسکونی + ISP	HTTP	۲.۷ دلار/گیگ
محتوای محدود جغرافیایی (نتفلیکس)	مسکونی	HTTPS/SOCKS5	۲.۷ دلار/گیگ
ردیابی رتبه SEO	مسکونی	HTTP	۲.۷ دلار/گیگ
تأیید تبلیغات	مسکونی	HTTP	۲.۷ دلار/گیگ
تست API (توسعه)	دیتاسنتر	HTTP/SOCKS5	۱.۵ دلار/گیگ

⚡ بهینه‌سازی کارایی پروکسی

بهترین شیوه‌های ۲۰۲۵

✅ Connection Pooling

اتصالات TCP به پروکسی را مجدداً استفاده کنید. HTTP Keep-Alive در هر درخواست ۱۰۰ تا ۲۰۰ میلی‌ثانیه صرفه‌جویی می‌کند.

✅ پشتیبانی از HTTP/2

از HTTP/2 برای مالتی‌پلکس کردن چندین درخواست روی یک اتصال استفاده کنید.

✅ نزدیکی جغرافیایی

پروکسی‌هایی را انتخاب کنید که از نظر جغرافیایی به سرور مقصد نزدیک باشند. تأخیر = فاصله.

✅ کش DNS

DNS Lookup ها را روی کلاینت کش کنید. جستجوی DNS ۲۰ تا ۵۰ میلی‌ثانیه زمان می‌برد.

✅ منطق تلاش مجدد (Retry Logic)

تلاش مجدد خودکار در صورت بروز خطاهای 5xx با تأخیر نمایی و استفاده از پروکسی دیگر.

✅ پایداری نشست (Session Persistence)

برای وظایفی که نیاز به نشست دارند، از sticky sessions (یک IP برای کل نشست) استفاده کنید.

⚠️ مواردی که باید از آن‌ها اجتناب کرد

❌ استفاده از پروکسی‌های رایگان (کند، ناامن، ناپایدار)
❌ نرخ محدودیت (rate limit) بیش از حد بالا (منجر به کپچا و مسدود شدن می‌شود)
❌ استفاده از یک پروکسی برای تمام درخواست‌ها (اثر انگشت‌گذاری، مسدود شدن IP)
❌ نادیده گرفتن هدرهای retry-after (محدودیت نرخ از سمت سرور)
❌ استفاده از پروکسی HTTP برای داده‌های حساس

🎓 نتیجه‌گیری

سرورهای پروکسی ابزاری قدرتمند هستند که در اینترنت مدرن ۲۰۲۵ نقشی جدایی‌ناپذیر دارند. درک نحوه کارکرد آن‌ها به شما برتری رقابتی در بسیاری از زمینه‌ها می‌دهد.

🔑 نکات کلیدی

۱. معماری

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

۲. پروتکل‌ها

HTTP برای ترافیک وب، SOCKS5 برای همه‌کاره بودن، CONNECT برای HTTPS — هر پروتکلی برای وظیفه خاص خود.

۳. امنیت

TLS 1.3 با ECH از DPI محافظت می‌کند. متد CONNECT رمزگذاری سرتاسری را حفظ می‌کند. همیشه از HTTPS استفاده کنید.

۴. کارایی

کش کردن سرعت بارگذاری را ۵۰ تا ۹۰ درصد افزایش می‌دهد. توازن بار، دسترسی بالا را برای ترافیک توزیع می‌کند.

۵. انتخاب نوع

مسکونی برای دور زدن محدودیت‌ها، موبایل برای شبکه‌های اجتماعی، دیتاسنتر برای وظایف ساده. انتخاب صحیح = موفقیت پروژه.

۶. روندهای مدرن

HTTP/3، QUIC، ECH (Encrypted Client Hello)، مسیریابی مبتنی بر هوش مصنوعی — پروکسی‌ها همگام با اینترنت تکامل می‌یابند.

🚀 گام‌های بعدی

تمرین: پروکسی را در پروژه خود تنظیم کرده و پروتکل‌های مختلف را تست کنید
نظارت: معیارهای کلیدی (نرخ Hit، تأخیر، نرخ خطا) را ردیابی کنید
بهینه‌سازی: با تنظیمات کش و توازن بار آزمایش کنید
امنیت: لاگ‌ها را برای ناهنجاری‌ها به طور منظم بررسی کنید
مقیاس‌پذیری: با افزایش بار، سرورهای پروکسی اضافه کنید

💡 به یاد داشته باشید: پروکسی جادو نیست، بلکه یک ابزار مهندسی است. درک نحوه کارکرد آن به شما امکان می‌دهد تا به طور مؤثر از آن استفاده کنید، از خطاها دوری کنید و به حداکثر کارایی دست یابید. در سال ۲۰۲۵، یک پروکسی تنظیم شده به درستی یک مزیت رقابتی محسوب می‌شود.

آماده‌اید دانش خود را به کار بگیرید؟

حالا شما یک متخصص سرور پروکسی هستید! دانش خود را با ProxyCove به کار ببرید.
۱۹۵+ کشور، تمام پروتکل‌ها، کیفیت ممتاز، ۹۹.۹٪ آپتایم.
ثبت‌نام با کد تخفیف ARTHELLO = +$1.3 اعتبار اولیه

شروع با ProxyCove →

تعرفه‌های ProxyCove ۲۰۲۵:

🏠 مسکونی — ۲.۷ دلار/گیگ 📱 موبایل — ۳.۸ دلار/گیگ 🏢 دیتاسنتر — ۱.۵ دلار/گیگ

✅ HTTP، HTTPS، SOCKS5 | ✅ API + داشبورد | ✅ پشتیبانی ۲۴/۷ | ✅ فعال‌سازی فوری

📚 راهنمای کامل پروکسی سرورها به پایان رسید!

شما مطالعه کردید:
بخش ۱: اصول کار، معماری، فوروارد در مقابل ریورس، شفاف در مقابل صریح
بخش ۲: پروتکل‌های HTTP/SOCKS، متد CONNECT، SSL/TLS handshake، هدرها
بخش ۳: کش کردن، توازن بار، مثال‌های عملی، بهینه‌سازی

🎉 تبریک می‌گوییم! اکنون نحوه کار پروکسی سرورها در سال ۲۰۲۵ را درک می‌کنید.

نحوه کارکرد پروکسی سرور: توضیحی ساده برای مبتدیان

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

مفهوم اصلی کارکرد

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

🔒 امنیت و ناشناس بودن

🌍 دور زدن محدودیت‌های جغرافیایی

⚡ کارایی

🛡️ فیلترینگ ترافیک

⚖️ توازن بار

🔍 نظارت و لاگ‌برداری

💡 تفاوت اصلی با VPN

🎭 نقش پروکسی به عنوان واسطه

وظایف پروکسی به عنوان واسطه

۱. تغییر درخواست‌ها

۲. بررسی سیاست‌های دسترسی

۳. کش کردن محتوا

۴. تغییر پاسخ‌ها

۵. لاگ‌برداری و تحلیل

⚙️ سه حالت کار پروکسی

🔵 Passthrough (حالت عبور)

🟢 Intercepting (حالت رهگیری)

🟡 Hybrid (حالت ترکیبی)

🔄 شمای درخواست-پاسخ از طریق پروکسی

شمای گام به گام کارکرد پروکسی

گام ۱: کلاینت درخواست را به پروکسی می‌فرستد

گام ۲: پروکسی درخواست را دریافت و بررسی می‌کند

گام ۳الف: اگر در کش باشد، بلافاصله برمی‌گرداند

گام ۳ب: اگر در کش نباشد، از سرور درخواست می‌کند

گام ۴: سرور مقصد درخواست را پردازش می‌کند

گام ۵: پروکسی پاسخ را پردازش می‌کند

گام ۶: پروکسی پاسخ را به کلاینت برمی‌گرداند

⚡ کارایی: با کش در مقابل بدون کش

🏗️ معماری پروکسی سرور

اجزای اصلی معماری

۱. Connection Manager (مدیریت اتصالات)

۲. Request Parser (تجزیه‌کننده درخواست)

۳. Authentication & Authorization (احراز هویت و مجوز دسترسی)

۴. Cache Engine (موتور کش)

۵. Upstream Handler (مدیریت سرورهای بالادستی)

۶. Response Processor (پردازشگر پاسخ)

۷. Logging & Monitoring (لاگ‌برداری و نظارت)

↔️ پروکسی فوروارد در مقابل ریورس

➡️ پروکسی فوروارد

ویژگی‌ها:

مثال‌های کاربرد:

راه‌حل‌های رایج:

⬅️ پروکسی ریورس

ویژگی‌ها:

مثال‌های کاربرد:

راه‌حل‌های رایج:

🔍 جدول مقایسه

👁️ پروکسی شفاف در مقابل صریح

👻 پروکسی شفاف

نحوه کارکرد:

ویژگی‌ها:

کاربرد:

📢 پروکسی صریح

نحوه کارکرد:

ویژگی‌ها:

کاربرد:

🔑 تفاوت کلیدی: متد CONNECT

پروکسی‌های حرفه‌ای برای هر نیازی

تعرفه‌های ProxyCove ۲۰۲۵:

🔌 پروتکل‌های پروکسی سرورها

پروتکل‌های اصلی

۱. پروکسی HTTP

۲. پروکسی HTTPS (HTTP CONNECT)

۳. پروکسی SOCKS4

۴. پروکسی SOCKS5

📊 مقایسه پروتکل‌ها

🌐 پروکسی HTTP به تفصیل

درخواست از طریق پروکسی HTTP

درخواست HTTP معمولی (بدون پروکسی)

درخواست HTTP از طریق پروکسی

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

🔐 احراز هویت در پروکسی HTTP

Basic Authentication

Digest Authentication

🔒 متد HTTP CONNECT

نحوه کارکرد CONNECT