Docker ریورس پروکسی: nginx-proxy بمقابلہ Traefik

Docker ریورس پروکسی ایک ہی اینٹری پوائنٹ ہے جو آپ کے کنٹینرز کے آگے چلتا ہے اور ہر آنے والی درخواست کو ہوسٹ نیم کے مطابق درست سروس تک پہنچاتا ہے۔ یہ گائیڈ اسی کام کے لیے دو مقبول ترین اختیارات، nginx-proxy اور Traefik، کا موازنہ کرتی ہے، ساتھ میں ہر ایک کے لیے چلنے والی docker-compose.yml، Let’s Encrypt کے ذریعے خودکار TLS، اور فیصلہ کرنے کے لیے واضح میٹرکس بھی دیتی ہے۔

اس کا دائرہ جان بوجھ کر محدود رکھا گیا ہے: اپنے سیلف ہوسٹڈ کنٹینرز کے آگے Docker ریورس پروکسی کیسے چلائیں۔ یہ باہر جانے والے ٹریفک کو پروکسی کے ذریعے بھیجنے کے بارے میں نہیں ہے، کیونکہ وہ بالکل الگ ٹول ہے اور آخر کے قریب برج نوٹ میں بتایا گیا ہے۔

DataImpulse ایک اخلاقی پروکسی فراہم کنندہ ہے جو 195 ممالک میں 9 کروڑ سے زیادہ ریزیڈنشل، موبائل اور ڈیٹا سینٹر IP ایڈریسز پیش کرتا ہے۔ یہ 1 ڈالر فی GB سے شروع ہونے والا استعمال کے مطابق ادائیگی کا ماڈل دیتا ہے جس میں ٹریفک کی میعاد ختم نہیں ہوتی، اور اسے ویب سکریپنگ، اشتہارات کی تصدیق، قیمتوں کی نگرانی، مارکیٹ ریسرچ اور متعدد اکاؤنٹس کے انتظام کے لیے استعمال کیا جاتا ہے۔

آپ کو کون سا Docker ریورس پروکسی استعمال کرنا چاہیے؟

ویب کنٹینرز کے چھوٹے اور مستحکم سیٹ کے لیے nginx-proxy استعمال کریں، خاص طور پر جب آپ کم سے کم پیچیدگی چاہتے ہوں۔ Traefik اس وقت بہتر ہے جب کنٹینرز اکثر بنتے اور ختم ہوتے رہیں اور آپ لیبلز سے چلنے والی روٹنگ چاہتے ہوں۔ دونوں آپ کو ایک عوامی پورٹ، TLS ٹرمینیشن اور سرٹیفکیٹس کی خودکار تجدید دیتے ہیں۔

اگر آپ کی سروسز زیادہ تر جامد ہیں اور آپ شاذ و نادر ہی نئی سروس شامل کرتے ہیں، تو nginx-proxy اپنے acme-companion کے ساتھ چلتے ہوئے HTTPS تک پہنچنے کا سب سے مختصر راستہ ہے۔ اگر آپ بار بار ڈیپلائے کرتے ہیں، بہت سے عارضی کنٹینرز چلاتے ہیں، یا ڈیش بورڈ اور مڈل ویئر چاہتے ہیں، تو Traefik سیکھنے کی اضافی محنت کے باوجود فائدہ دیتا ہے۔ Caddy تیسرا قابلِ غور اختیار ہے اور پیچیدگی کے لحاظ سے دونوں کے بیچ میں آتا ہے۔

Docker ریورس پروکسی کیا ہے اور اسے کیوں استعمال کریں؟

Docker ریورس پروکسی ایک کنٹینر ہے جو پورٹ 80 اور 443 پر آنے والا تمام ویب ٹریفک وصول کرتا ہے، پھر مطلوبہ ہوسٹ نیم یا راستے کی بنیاد پر ہر درخواست کو درست بیک اینڈ کنٹینر تک بھیج دیتا ہے۔ اس کے بغیر، ہر کنٹینر جسے عوامی رسائی چاہیے اسے اپنا الگ ہوسٹ پورٹ شائع کرنا پڑے گا، اور TLS سرٹیفکیٹس مختلف سروسز میں بکھر جائیں گے۔

کسی بھی سیٹ اپ کو سمجھنے کے لیے اس کے بنیادی حصوں کو نام دینا مددگار ہوتا ہے۔ اسے 5 مرحلوں والا کنٹینر ریورس پروکسی اسٹیک کہیں: اینٹری پوائنٹ، راؤٹر، سروس ڈسکوری، TLS اور کنٹینر۔ اینٹری پوائنٹ عوامی پورٹ ہے۔ راؤٹر ایک ہوسٹ نیم کو ایک اصول سے ملاتا ہے۔ سروس ڈسکوری وہ طریقہ ہے جس سے پروکسی کو معلوم ہوتا ہے کہ کون سے کنٹینرز موجود ہیں۔ TLS وہ حصہ ہے جہاں سرٹیفکیٹس جاری کیے جاتے ہیں اور ٹریفک terminate ہوتا ہے۔ کنٹینر آپ کی اصل ایپلیکیشن ہے۔ نیچے دیا گیا ہر ٹول انہی پانچ مرحلوں کو نافذ کرتا ہے؛ فرق صرف اتنا ہے کہ ہر ایک کا کتنا حصہ خودکار ہے۔

• روٹنگ: ہر ایپ کے لیے ایک ہوسٹ نیم، اور سب کچھ ایک ہی اینٹری پوائنٹ کے ذریعے، تاکہ انٹرنیٹ پر صرف پورٹ 80 اور 443 ہی ظاہر ہوں۔
• TLS ٹرمینیشن: سرٹیفکیٹس ہر ایپلیکیشن کے اندر رکھنے کے بجائے ایک ہی جگہ مانگے، محفوظ اور تجدید کیے جاتے ہیں۔
• ایک واحد اینٹری پوائنٹ: لاگنگ، ریٹ لِمِٹس اور رسائی کے اصولوں کے لیے ایک ہی کنٹرول پوائنٹ۔

ہم نے ریورس پروکسی اختیارات کا موازنہ کیسے کیا؟

ہر ٹول کو اوپر دیے گئے پانچ مرحلوں اور سیٹ اپ کی لاگت کے لحاظ سے پرکھا گیا، اور صرف ہر پروجیکٹ کی سرکاری سائٹ پر درج رویے کو بنیاد بنایا گیا۔ مقصد روزمرہ کے عمل کو پرکھنا تھا، تھروپٹ کا بینچ مارک کرنا نہیں۔

موازنہ چار عملی عوامل کو اہمیت دیتا ہے: سروس ڈسکوری کتنی خودکار ہے، TLS کیسے حاصل اور تجدید ہوتا ہے، سروسز بڑھنے کے ساتھ کنفیگریشن کتنی پڑھنے کے قابل رہتی ہے، اور پہلی بار کے صارف کو کتنے پیشگی علم کی ضرورت ہے۔ فیچرز کی تفصیلات Traefik کی دستاویزات (traefik.io، 2026-07-22 تک)، nginx-proxy اور acme-companion کے پروجیکٹ صفحات (github.com/nginx-proxy، 2026-07-22 تک) اور Caddy کی دستاویزات (caddyserver.com، 2026-07-22 تک) سے آتی ہیں۔ کارکردگی کے اعداد یہاں نہیں گھڑے گئے، کیونکہ وہ آپ کے ہارڈ ویئر اور ورک لوڈ پر بہت زیادہ منحصر ہوتے ہیں۔

آپ Docker ریورس پروکسی سرور کیسے سیٹ اپ کرتے ہیں؟

پروکسی کو docker-compose.yml میں ایک سروس کے طور پر بیان کریں، اسے دو عوامی پورٹس دیں، اور Docker socket کو صرف پڑھنے کے موڈ میں ماؤنٹ کریں تاکہ پروکسی آپ کے دوسرے کنٹینرز دریافت کر سکے۔ یہاں خودکار TLS کے ساتھ ایک کم سے کم Traefik اینٹری پوائنٹ ہے۔

services:
  traefik:
    image: traefik:v3.1
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.tlschallenge=true"
      - "[email protected]"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./letsencrypt:/letsencrypt"

پھر بیک اینڈ سروس لیبلز کے ذریعے شامل ہوتی ہے۔ Traefik انہیں Docker API سے پڑھتا ہے، ایک راؤٹر بناتا ہے، اور le نامی ریزولور کے ذریعے سرٹیفکیٹ کی درخواست کرتا ہے۔ کنٹینر شروع ہونے پر پروکسی دوبارہ شروع کرنے کی ضرورت نہیں پڑتی۔

  whoami:
    image: traefik/whoami
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`app.example.com`)"
      - "traefik.http.routers.whoami.entrypoints=websecure"
      - "traefik.http.routers.whoami.tls.certresolver=le"

nginx-proxy Docker socket پر نظر رکھتا ہے اور جب بھی VIRTUAL_HOST ماحولیاتی متغیر والا کنٹینر ظاہر ہوتا ہے تو اپنی nginx کنفیگریشن دوبارہ بناتا ہے، جبکہ ایک ساتھی کنٹینر Let’s Encrypt سرٹیفکیٹس سنبھالتا ہے۔ آپ لیبلز کے بجائے ماحولیاتی متغیرات کے ذریعے مطلوبہ روٹنگ بتاتے ہیں۔

services:
  nginx-proxy:
    image: nginxproxy/nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
      - "certs:/etc/nginx/certs"
      - "vhost:/etc/nginx/vhost.d"
      - "html:/usr/share/nginx/html"
  acme:
    image: nginxproxy/acme-companion
    volumes_from:
      - nginx-proxy
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "acme:/etc/acme.sh"
    environment:
      - "[email protected]"
  app:
    image: traefik/whoami
    environment:
      - "VIRTUAL_HOST=app.example.com"
      - "LETSENCRYPT_HOST=app.example.com"
volumes:
  certs:
  vhost:
  html:
  acme:

Caddy ایک ہلکا تیسرا اختیار ہے۔ یہ پہلے سے طے شدہ طور پر سرٹیفکیٹس خود بخود حاصل کرتا اور ان کی تجدید کرتا ہے، اور اس کی کنفیگ فائل مختصر رہتی ہے۔ سروس کو compose میں بیان کریں اور ایک Caddyfile کے ساتھ سرٹیفکیٹس کے لیے ایک ڈیٹا والیوم ماؤنٹ کریں۔

services:
  caddy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "./Caddyfile:/etc/caddy/Caddyfile"
      - "caddy_data:/data"
volumes:
  caddy_data:

Caddyfile میں خود ایک لائن کا پروکسی اور خودکار TLS شامل ہے۔

app.example.com {
    reverse_proxy app:8080
}

nginx-proxy، Traefik اور Caddy کا موازنہ کیسا ہے؟

تینوں TLS ٹرمینیشن کرتے ہیں اور ہوسٹ نیم کے مطابق روٹ کرتے ہیں؛ اصل فرق کنفیگریشن کے انداز اور خودکاری کی سطح میں ہے۔ جدول عملی سمجھوتوں کا خلاصہ پیش کرتا ہے۔

آپ کو کب کون سا ریورس پروکسی منتخب کرنا چاہیے؟

ٹول کا انتخاب اس بنیاد پر کریں کہ آپ کے کنٹینرز کتنی بار بدلتے ہیں اور آپ کتنی کنفیگریشن خود سنبھالنا چاہتے ہیں۔ نیچے دیے گئے اصول موازنے کو براہِ راست فیصلے میں بدل دیتے ہیں۔

• nginx-proxy تب استعمال کریں جب آپ ویب ایپس کا ایک مقررہ سیٹ چلاتے ہیں اور تقریباً بغیر کنفیگریشن کے چلنے والا HTTPS چاہتے ہیں۔
• Traefik تب استعمال کریں جب کنٹینرز اکثر بنائے اور ختم کیے جاتے ہیں، یا آپ ڈیش بورڈ، مڈل ویئر اور لیبلز سے چلنے والی روٹنگ چاہتے ہیں۔
• Caddy تب استعمال کریں جب آپ ممکنہ حد تک مختصر کنفیگریشن چاہتے ہیں اور خودکار TLS آپ کی بنیادی ضرورت ہے۔
• nginx-proxy سے گریز کریں جب آپ کی سروسز مسلسل اسکیل اَپ اور اسکیل ڈاؤن ہوتی ہیں، کیونکہ اس رفتار پر ماحولیاتی متغیرات کے ذریعے ڈسکوری بے ڈھنگی ہو جاتی ہے۔
• Traefik سے گریز کریں جب آپ کی ٹیم نے کبھی اس کے لیبل نحو کے ساتھ کام نہیں کیا اور آپ کو صرف دو یا تین مستحکم سائٹس کو پروکسی کرنا ہے۔

حدود اور احتیاطیں کیا ہیں؟

Docker ریورس پروکسی آنے والی روٹنگ اور TLS کا مسئلہ حل کرتا ہے، لیکن یہ ہر مسئلہ حل نہیں کرتا اور اس کے حقیقی خطرات بھی ہیں۔ Docker socket کو ماؤنٹ کرنا، چاہے صرف پڑھنے کے لیے ہو، پروکسی کو آپ کے ہوسٹ پر وسیع رسائی دے دیتا ہے، اس لیے اس کنٹینر کو سیکیورٹی کے لحاظ سے حساس سمجھیں اور اسے اپ ڈیٹ رکھتے رہیں۔

دیگر عام مسائل: خودکار سرٹیفکیٹس اس وقت ناکام ہو جاتے ہیں جب DNS ابھی تک ہوسٹ کی طرف اشارہ نہ کر رہا ہو یا پورٹ 80 اور 443 بلاک ہیں، اس لیے اپنی پہلی ڈیپلائےمنٹ سے پہلے DNS کی تصدیق کریں۔ بیک اینڈ کنٹینرز کو پروکسی کے ساتھ ایک Docker نیٹ ورک شیئر کرنا چاہیے ورنہ روٹنگ خاموشی سے غلطیاں لوٹاتی ہے۔ Let’s Encrypt کی ریٹ لِمِٹس کا مطلب ہے کہ آپ کو پروڈکشن سرٹیفکیٹس پر جانے سے پہلے اس کے اسٹیجنگ ماحول کے خلاف ٹیسٹ کرنا چاہیے۔ آخر میں، ریورس پروکسی گنجائش نہیں بڑھاتا؛ اگر بیک اینڈ سست ہے، تو پروکسی صرف اسی سستی کو آگے منتقل کر دے گا۔

برج نوٹ: فارورڈ بمقابلہ ریورس۔ یہ پورا مضمون ریورس پروکسی کے بارے میں ہے، جو آپ کے کنٹینرز کی طرف آنے والا ٹریفک سنبھالتا ہے۔ اس کے برعکس کام، یعنی ویب سکریپنگ یا جیو ٹیسٹنگ کے لیے اپنی مشین سے کسی اور IP کے ذریعے ٹریفک باہر بھیجنا، فارورڈ پروکسی کا تقاضا کرتا ہے۔ دونوں کو اکثر الجھایا جاتا ہے؛ فرق ریورس پروکسی بمقابلہ فارورڈ پروکسی میں بیان کیا گیا ہے۔ اس باہر جانے والے استعمال کے لیے، DataImpulse اخلاقی طور پر حاصل کردہ ریزیڈنشل پروکسیز 1 ڈالر فی GB سے پیش کرتا ہے۔ یہ ریورس پروکسی نہیں ہے اور آپ کے کنٹینرز تک ٹریفک روٹ نہیں کرے گا، اس لیے دونوں کردار الگ رکھیں۔

اکثر پوچھے جانے والے سوالات

متعلقہ گائیڈز

• NGINX Reverse Proxy
• Cloudflare Reverse Proxy
• NGINX Forward Proxy

صرف آنے والی روٹنگ نہیں، باہر جانے والی پروکسیز بھی درکار ہیں؟

اگر آپ کے پروجیکٹ کو کئی مقامات سے ویب تک رسائی کی بھی ضرورت ہے، تو DataImpulse 195 ممالک میں اخلاقی طور پر حاصل کردہ ریزیڈنشل، موبائل اور ڈیٹا سینٹر IPs فراہم کرتا ہے، بغیر سبسکرپشن کے، 1 ڈالر فی GB سے استعمال کے مطابق ادائیگی پر۔ اپنے ریورس پروکسی سیٹ اپ کے ساتھ اسے آزمانے کے لیے ایک مفت اکاؤنٹ بنائیں۔