Nginx، Caddy یا Traefik: کون سا proxy چنیں؟

Nginx بمقابلہ Caddy بمقابلہ Traefik: مختصر جواب

Nginx، Caddy اور Traefik reverse proxy کے طور پر ایک ہی کام کرتے ہیں: port 443 پر listening کرتے ہیں، ہر request میں hostname پڑھتے ہیں، اور اسے آپ کے VPS پر درست service تک پہنچاتے ہیں۔ ان تینوں میں سے کوئی بھی ایک public IP address کے پیچھے چار self-hosted ایپس چلا سکتا ہے، اور یہ سب اتنے تیز ہیں کہ سست رفتاری کی اصل وجہ آپ کی ایپس ہوں گی۔ فرق اس بات میں ہے کہ ہر proxy TLS (transport layer security) certificate کیسے حاصل کرتا ہے اور ہر اضافی ایپ کے لیے configuration میں کتنی محنت درکار ہوتی ہے۔ دوسرا فرق بعد میں ظاہر ہوتا ہے، جب آپ کو ایسی ضرورت پیش آتی ہے جسے عام tutorials نظرانداز کر دیتے ہیں۔

اگر آپ HTTPS خودکار طور پر manage کروانا چاہتے ہیں اور آپ کی services عام web apps ہیں تو Caddy منتخب کریں۔ اگر سب کچھ Docker Compose میں چلتا ہے اور آپ ہر چند ہفتوں بعد نئی service شامل کرتے ہیں تو Traefik منتخب کریں۔ اگر آپ پہلے ہی Nginx چلا رہے ہیں، یا آپ کو response caching، client certificates، raw TCP forwarding یا پہلے سے موجود بڑی configuration درکار ہے جسے دوبارہ لکھنا نہیں چاہتے، تو Nginx منتخب کریں۔

ہر ایک کو TLS certificate کیسے ملتا ہے؟

زیادہ تر لوگوں کے لیے فیصلہ اسی بنیاد پر ہوتا ہے، اس لیے یہیں سے شروع کریں۔ آخرکار تینوں کو ایک ہی authority سے ایک ہی certificate ملتا ہے۔ وہاں تک پہنچنے کے لیے آپ جو اقدامات کرتے ہیں، وہ مختلف ہیں۔

Caddy certificate اس لیے طلب کرتا ہے کیونکہ آپ نے hostname دیا ہے۔ app.example.com کو site address کے طور پر لکھیں، اور Caddy ACME (automatic certificate management environment) کے ذریعے Let's Encrypt سے certificate طلب کرتا ہے۔ اگر یہ ناکام ہو تو ZeroSSL استعمال کرتا ہے، port 80 پر HTTP سے HTTPS redirect فراہم کرتا ہے، اور خود renew کرتا ہے۔ کسی دوسرے tool یا کسی timer کو چیک کرنے کی ضرورت نہیں۔ Certificates caddy user کی data directory میں محفوظ ہوتے ہیں۔ Package installation میں یہ directory /var/lib/caddy/.local/share/caddy ہے، اس لیے اس path کو backups میں شامل کریں یا rebuild کے بعد نیا certificate جاری ہونے کو قبول کریں۔ اگر hostname public نہ ہو تو Caddy اپنی local certificate authority سے tls internal کے ذریعے sign کرتا ہے۔ نتیجہ وہی ہوتا ہے جو Ubuntu پر self-signed certificate بنانا سے حاصل ہوتا ہے، لیکن renewal خودکار طور پر ہو جاتی ہے۔

Nginx میں ACME client شامل نہیں ہوتا۔ Certbot certificate حاصل کرتا ہے، اور اس کا --nginx plugin آپ کے server block میں تبدیلی کر کے 443 listener اور redirect شامل کرتا ہے۔ Renewal package کے نصب کردہ systemd timer کے ذریعے چلتی ہے، اس لیے دو الگ اجزا اور دو چیزوں کی تصدیق ضروری ہے: systemctl list-timers | grep certbot سے معلوم ہوتا ہے کہ timer موجود ہے، جبکہ sudo certbot renew --dry-run ثابت کرتا ہے کہ renewal path اب بھی کام کر رہا ہے۔ مرحلہ وار طریقہ Nginx کے ساتھ Ubuntu 24.04 پر Certbot میں موجود ہے۔ یہی tool DNS-01 challenge کے ذریعے wildcard certificate کے لیے بھی استعمال ہوتا ہے، جب subdomains اتنے زیادہ ہوں کہ آپ انہیں الگ الگ درج نہیں کرنا چاہتے۔

Traefik اپنا ACME client ساتھ رکھتا ہے۔ Static configuration میں ایک certificate resolver configure کریں، پھر ہر router اسے استعمال کر سکتا ہے۔ تمام state، account key اور certificates سمیت، ایک ہی acme.json file میں محفوظ ہوتی ہے۔ اگر یہ file اس کے owner کے علاوہ کسی اور کے لیے readable ہو تو Traefik اسے استعمال کرنے سے انکار کرتا ہے اور resolver کو ختم کرنے سے پہلے اس کی اطلاع دیتا ہے:

The ACME resolver "le" is skipped from the resolvers list because: unable to get ACME account: permissions 660 for /letsencrypt/acme.json are too open, please use 600

ایک directory mount کریں اور Traefik کو file خود بنانے دیں۔ اسے پہلے touch کے ذریعے بنائیں۔ اس طرح اس پر آپ کا umask لاگو ہوگا، اور زیادہ تر لوگ اسی طرح اس سطر کی شرط پوری کرتے ہیں۔

تینوں کے لیے ایک بات یکساں ہے۔ HTTP-01 challenge کے لیے port 80 کا internet سے reachable ہونا ضروری ہے، کیونکہ certificate authority اسی port سے واپس connect کرتی ہے۔ صرف 443 کھولنے سے issuance ناکام ہو جاتی ہے، اور خرابی کا پیغام DNS fault جیسا دکھائی دے سکتا ہے۔

تین configurations میں وہی دو ایپس routing کا کام

کام یہ ہے: app.example.com کو 127.0.0.1:8080 پر موجود service تک، اور files.example.com کو 127.0.0.1:8081 پر موجود service تک پہنچانا ہے، دونوں HTTPS کے ذریعے۔ ذیل میں ہر proxy کے لیے مکمل configuration دی گئی ہے، تاکہ verbosity کا فرق صرف بیان کرنے کے بجائے واضح طور پر نظر آئے۔

Nginx

# /etc/nginx/sites-available/app.example.com
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

پھر اس کا link بنائیں، configuration test کریں، reload کریں، اور certificate شامل کریں۔

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d app.example.com

nginx -t میں syntax is ok اور test is successful دکھانا وہ check ہے جو ہر reload سے پہلے چلانا چاہیے۔ دوسری app کے لیے یہی block hostname اور port تبدیل کر کے استعمال کریں۔ proxy_set_header والی lines محض ظاہری نہیں ہیں: جب proxy_pass کسی address کا نام ہو تو nginx default طور پر Host: 127.0.0.1:8080 upstream کو بھیجتا ہے۔ اس لیے جو app Host header سے absolute URLs بناتی ہو، وہ صارفین کو localhost پر بھیج دے گی۔ ان چاروں headers کا مقصد کیا ہے، اور proxy_pass کے آخر میں trailing slash خاموشی سے app کو موصول ہونے والا path کیوں بدل دیتی ہے، یہ سب nginx server block کی اس walkthrough میں directive بہ directive بیان کیا گیا ہے۔

Caddy

app.example.com {
	reverse_proxy 127.0.0.1:8080
}

files.example.com {
	reverse_proxy 127.0.0.1:8081
}

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

یہ پوری file ہے۔ reverse_proxy خود X-Forwarded-For، X-Forwarded-Proto اور X-Forwarded-Host set کرتا ہے، اور default طور پر client کی جانب سے بھیجے گئے ان headers کو نظرانداز کرتا ہے۔ اس لیے request backend کو اپنے origin کے بارے میں غلط معلومات نہیں دے سکتی۔ Certificates، port 80 سے redirect، اور renewal سب ان دو site addresses سے خود بخود متعین ہوتے ہیں۔ File میں کسی اور configuration کی ضرورت نہیں۔

Traefik

Traefik کو routing شروع کرنے سے پہلے static configuration درکار ہوتی ہے۔ Compose service کے طور پر، اور August 2026 تک موجودہ image tag کے ساتھ:

services:
  traefik:
    image: traefik:v3.7
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.email=you@example.com"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt

اس کے بعد ہر application اپنی routing اپنی compose file میں labels کے ذریعے رکھتی ہے:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.routers.app.tls.certresolver=le"
      - "traefik.http.services.app.loadbalancer.server.port=8080"

loadbalancer.server.port container کے اندر موجود port ہے، published port نہیں، کیونکہ Traefik shared Docker network کے ذریعے container تک پہنچتا ہے۔ App میں ports: line کی کوئی ضرورت نہیں۔ یہی اصل فائدہ ہے: صرف Traefik published ہوتا ہے۔ Shared network اور redirect middleware سمیت مکمل build Traefik اور Docker Compose کے ساتھ متعدد apps کی routing میں موجود ہے۔

ہر اضافی ایپ کے لیے کتنی configuration درکار ہوتی ہے؟

[
  {
    "tool": "Nginx",
    "proxy_setup_lines": 0,
    "lines_per_app": 11
  },
  {
    "tool": "Caddy",
    "proxy_setup_lines": 0,
    "lines_per_app": 3
  },
  {
    "tool": "Traefik",
    "proxy_setup_lines": 17,
    "lines_per_app": 5
  }
]

اوپر دیے گئے blocks کی بنیاد پر حساب کریں۔ Nginx server block میں 11 non-blank lines ہیں، اور ہر hostname کے لیے اسے دوبارہ لکھنا پڑتا ہے۔ Caddy site block میں 3 lines ہیں۔ Traefik کو ایک بھی request serve کرنے سے پہلے static configuration کی 17 lines درکار ہوتی ہیں، اس کے بعد ہر ایپ کے لیے 5 labels درکار ہوتے ہیں۔

صرف فاتح نہ دیکھیں؛ اس trade-off کو سمجھیں۔ پہلی ایپ سے پہلے Traefik کی لاگت سب سے زیادہ ہے، لیکن اس کے بعد ہر اضافی ایپ کی لاگت سب سے کم رہتی ہے۔ دونوں totals تقریباً تیسری site پر برابر ہو جاتے ہیں۔ اس سے کم sites پر static configuration غیر ضروری overhead ہے۔ اس سے زیادہ sites پر labels آگے نکل جاتے ہیں اور فرق بڑھتا رہتا ہے، کیونکہ routing اسی service کے ساتھ رہتی ہے جسے وہ route کرتی ہے۔ Service delete کریں تو اس کا route بھی ختم ہو جاتا ہے۔ یہی وہ کام ہے جس میں مرکزی config file کمزور ہوتی ہے: ایسی apps کے stale server blocks باقی رہ جاتے ہیں جو کئی ماہ پہلے ختم ہو چکی ہوں۔

Line count Nginx کے حق میں بھی تصویر کو زیادہ اچھا دکھاتا ہے۔ ہر block کے لیے ایک symlink، ایک nginx -t، ایک reload اور ایک certbot run درکار ہوتا ہے، جبکہ Caddy edit کے لیے ایک reload کافی ہے اور Traefik edit کے لیے کسی command کی ضرورت نہیں ہوتی۔ تینوں live connections ختم کیے بغیر reload ہو جاتے ہیں۔ اصل فرق ان الگ الگ steps کی تعداد ہے جنہیں آپ کو رات 1 بجے بھی یاد رکھنا پڑتا ہے۔

آپ کے containers کے بارے میں کون جانتا ہے؟

Traefik، Docker socket کی نگرانی کرتا ہے اور containers کے شروع یا بند ہوتے ہی ان کے labels سے routers بناتا ہے۔ یہاں کوئی اور یہ کام نہیں کرتا۔ نیا container ظاہر ہونے پر Nginx اور Caddy دونوں میں config edit کرکے reload کرنا پڑتا ہے۔ انہیں ایسا address بھی درکار ہوتا ہے جس تک وہ پہنچ سکیں: یا تو loopback پر publish کیا گیا port، یا ایسا مشترکہ Docker network جس سے proxy منسلک ہو۔

اس سہولت کی ایک قیمت ہے، اور اسے واضح طور پر بیان کرنا ضروری ہے۔ Traefik /var/run/docker.sock پڑھتا ہے۔ جو بھی اس socket سے رابطہ کر سکتا ہے، وہ ایسا container شروع کر سکتا ہے جس میں host filesystem mount ہو۔ اس سے اسے host پر root access حاصل ہو جاتا ہے۔ اسے read only mount کرنے سے خطرہ کم ہوتا ہے، لیکن ختم نہیں ہوتا۔ اگر آپ کے threat model میں یہ اہم ہے تو درمیان میں socket proxy رکھیں، جو صرف وہ container list endpoints ظاہر کرے جن کی Traefik کو ضرورت ہے۔

Caddy، community plugin کے ذریعے label-based discovery کر سکتا ہے، لیکن Caddy plugins binary میں compile کیے جاتے ہیں۔ اس لیے آپ کو xcaddy کے ساتھ custom binary یا custom image بنانی ہوگی، اور پھر اس build اور اس کی updates کی ذمہ داری بھی آپ کی ہوگی۔ تین یا چار services کے لیے Caddyfile میں edit کرنا کم محنت کا کام ہے۔

WebSocket اور streaming: کیا خراب ہوتا ہے، اور کیوں

مدد کی ضرورت Nginx کو ہوتی ہے۔ WebSocket connection کا آغاز ایک HTTP request سے ہوتا ہے جس میں Upgrade: websocket شامل ہوتا ہے، لیکن nginx upstream کو hop-by-hop headers اس وقت تک منتقل نہیں کرتا جب تک آپ اسے ایسا کرنے کی ہدایت نہ دیں۔

# /etc/nginx/conf.d/upgrade-map.conf
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

اس کے بعد location block کے اندر تینوں lines کا موجود ہونا ضروری ہے:

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

اگر یہ lines شامل نہ ہوں تو browser console میں WebSocket connection to 'wss://app.example.com/ws' failed ظاہر ہوتا ہے، جبکہ backend log میں عام GET نظر آتا ہے۔ map اس لیے موجود ہے کہ hardcoded Connection: upgrade ہر request کے ساتھ بھیجا جائے گا، ان عام requests کے ساتھ بھی جن میں close ہونا چاہیے۔

Nginx کی دو مزید default settings بھی مسئلہ پیدا کرتی ہیں۔ proxy_read_timeout کی قدر 60 seconds ہے، اور upgrade کے بعد یہ tunnel پر لاگو ہوتی ہے۔ اس لیے ایک minute تک network traffic نہ رکھنے والا WebSocket proxy کے ذریعے بند ہو جاتا ہے۔ Server-sent events اس وقت تک تاخیر سے یا bursts کی صورت میں پہنچتے ہیں جب تک آپ اس location پر proxy_buffering off; مقرر نہ کریں، کیونکہ nginx response کو اپنے buffer میں رکھتا ہے جبکہ آپ کا page اس کا انتظار کرتا ہے۔

Caddy بغیر کسی directive کے upgrade مکمل کرتا ہے اور connection کو two-way tunnel میں تبدیل کر دیتا ہے۔ جب response text/event-stream ہو یا اس کی length معلوم نہ ہو، تو یہ فوراً flush بھی کرتا ہے، اس لیے streaming کے لیے اضافی configuration درکار نہیں ہوتی۔ Traefik upgrades کو آگے منتقل کرتا ہے اور responses کو buffer نہیں کرتا، جب تک آپ خود اس کا buffering middleware شامل نہ کریں۔ اگر آپ کی services میں chat، web terminal، log tails یا live dashboards شامل ہیں تو آپ کو لکھنے اور debug کرنے والی configuration کی مقدار میں یہ ایک حقیقی فرق ہے۔

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name app.example.com;
    client_max_body_size 64m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        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;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

جب آپ کو کوئی غیر معمولی چیز درکار ہو تو کیا ہوتا ہے؟

یہ وہ مرحلہ ہے جہاں Nginx کی اضافی configuration مؤثر ثابت ہوتی ہے۔

• Client certificates، جنہیں mTLS (mutual TLS) بھی کہا جاتا ہے، میں client کو بھی ایک certificate پیش کرنا ہوتا ہے۔ Nginx کے server block میں ssl_client_certificate /etc/ssl/ca.pem; اور ssl_verify_client on; درکار ہوتے ہیں۔ Caddy میں tls کے اندر client_auth block درکار ہوتا ہے۔ Traefik labels کے ذریعے اسے بالکل بیان نہیں کیا جا سکتا: آپ file provider میں TLS option define کرتے ہیں اور traefik.http.routers.app.tls.options=mtls@file کے ذریعے router کو اس سے منسلک کرتے ہیں۔ ہر چیز labels میں رکھنے والے model کو پہلی بار اس ضرورت پر استثنا دینا پڑتا ہے۔
• بڑی uploads۔ Nginx میں request bodies کی حد default طور پر 1 MB ہوتی ہے۔ بڑی upload پر 413 Request Entity Too Large واپس آتا ہے اور error log میں client intended to send too large body درج ہوتا ہے۔ client_max_body_size کی قدر بڑھائیں۔ Caddy اور Traefik default طور پر body کی کوئی حد مقرر نہیں کرتے، اس لیے request آپ کی app تک پہنچتی ہے اور فیصلہ app کی اپنی limit کرتی ہے۔
• Response caching۔ Nginx میں proxy_cache موجود ہے اور یہ پختہ implementation ہے۔ Caddy کے لیے plugin کو build میں compile کرنا پڑتا ہے۔ Traefik کی open source build میں HTTP cache بالکل موجود نہیں، جو ان لوگوں کے لیے حیران کن ہو سکتا ہے جو سمجھتے ہیں کہ ہر proxy caching کرتا ہے۔
• Raw TCP یا UDP، مثلاً database port یا game server کے لیے۔ Nginx میں stream module موجود ہے۔ Traefik میں اپنے الگ entrypoints پر TCP اور UDP routers ہوتے ہیں۔ Caddy کے لیے ایک اور plugin درکار ہوتا ہے، اس لیے ایک اور custom build بنانا پڑتا ہے۔
• Proxy کے پیچھے پہلے سے موجود web server۔ اگر service ایک classic PHP application ہے تو Ubuntu 24.04 پر LAMP stack میں Apache پہلے ہی شامل ہوتا ہے۔ اس کے سامنے proxy رکھنے سے آپ کے پاس headers set کرنے کی دو جگہیں اور URL rewrite کرنے کی دو جگہیں بن جاتی ہیں۔ فیصلہ کریں کہ TLS کون terminate کرے گا، پھر دوسرے server کو loopback پر plain HTTP کے ساتھ bind رکھیں۔

اس انتخاب کے بعد سامنے آنے والا firewall trap

reverse proxy کا مقصد یہ ہے کہ صرف 80 اور 443 کھلے ہوں۔ Docker خاموشی سے اس ترتیب کو بدل دیتا ہے۔ -p 8080:80 کے ذریعے port publish کرنے سے nat table میں DNAT rule شامل ہو جاتا ہے۔ یہ rule ان INPUT rules سے پہلے evaluate ہوتا ہے جنہیں ufw manage کرتا ہے۔ اس لیے ufw deny 8080 اسے block نہیں کرتا، اور آپ کی app اس proxy کے ساتھ public internet پر دستیاب ہو جاتی ہے جسے آپ نے احتیاط سے configure کیا تھا۔ Published ports کو 127.0.0.1:8080:80 کے ذریعے loopback پر bind کریں، یا ports: کو مکمل طور پر ہٹا دیں اور proxy کو Docker network کے ذریعے container تک پہنچنے دیں۔ اوپر دیا گیا Traefik example بھی یہی طریقہ استعمال کرتا ہے۔ اس mechanism اور fix کی وضاحت Docker کے published ports ufw کو bypass کیوں کرتے ہیں میں ہے۔

اسے ایسی machine سے test کریں جو VPS نہ ہو، کیونکہ خود VPS پر چلایا گیا check ہمیشہ کامیاب ہوتا ہے:

curl --max-time 5 http://your.server.address:8080

آپ کو Connection refused یا timeout کا نتیجہ ملنا چاہیے۔ HTTP response کا مطلب ہے کہ app آپ کے proxy سے گزرے بغیر reachable ہے، اور اوپر configure کی گئی تمام چیزیں محض دکھاوا ہیں۔

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

زیادہ تر static sites، اور ساتھ ایک یا دو ایپس: Caddy۔ خودکار HTTPS آپ کے سب سے بڑے بار بار ہونے والے انتظامی کام کو ختم کر دیتا ہے۔ Configuration اتنی مختصر رہتی ہے کہ ایک ہی screen پر پڑھی جا سکے، اور static site اسی site block کے اندر ایک root line اور ایک file_server line ہوتی ہے۔ اس کا نقصان یہ ہے کہ کوئی غیر معمولی خرابی آنے پر copy-paste کے لیے دستیاب حل کم ہوتے ہیں۔

ایسا docker-compose homelab جس میں آپ مسلسل نئی سروسز شامل کرتے رہتے ہیں: Traefik۔ تیسری service کے بعد labels میں ترمیم کرنا مرکزی file میں تبدیلی کرنے سے کم محنت طلب ہوتا ہے، اور حذف کی گئی service اپنا route بھی ساتھ لے جاتی ہے۔ پہلی setup کے لیے ایک دوپہر مختص کریں، کیونکہ entrypoints، routers، services اور middlewares سب نئی اصطلاحات ہیں۔ label میں typo عموماً start ہونے میں failure کے بجائے Traefik کی طرف سے 404 دکھاتا ہے، اس لیے app کو خراب سمجھنے سے پہلے parse error کے لیے docker logs traefik پڑھیں۔

موجودہ Nginx configuration، یا اوپر دی گئی فہرست کی کوئی بھی ضرورت: Nginx۔ اس میں response caching اور client certificates کے لیے پہلے سے حل موجود ہے، اور تقریباً ہر third-party guide اسی کو فرض کرتی ہے۔ اس کا نقصان یہ ہے کہ certificates اور websocket support ایسی چیزیں ہیں جنہیں آپ خود configure کرتے ہیں، خودکار طور پر حاصل نہیں کرتے۔

آپ کوئی بھی انتخاب کریں، ایک اصول برقرار رہتا ہے۔ Public interface پر بالکل ایک process listen کرے، اور باقی تمام processes loopback یا private Docker network پر listen کریں۔

FAQ

چند Docker ایپس کے لیے ایک ہی VPS پر کون سا reverse proxy بہتر ہے؟

اگر آپ کبھی کبھار تین یا چار services شامل کرتے ہیں تو Traefik اپنی لاگت پوری کر دیتا ہے، کیونکہ ہر app اپنی routing labels رکھتی ہے اور مرکزی file میں ترمیم کی ضرورت نہیں ہوتی۔ اگر services مستحکم ہیں اور آپ بنیادی طور پر HTTPS کی ذمہ داری خود سنبھالنا نہیں چاہتے تو Caddy سیکھنے میں آسان اور خراب ہونے کے امکانات میں کم ہے۔ Nginx اس وقت منتخب کریں جب آپ اسے پہلے سے جانتے ہوں، یا جب آپ کو ایسی feature درکار ہو جو باقی دونوں میں موجود نہ ہو، مثلاً response caching یا plain TCP listener۔

کیا Caddy کو واقعی certificate configuration کی ضرورت نہیں ہوتی؟

عام صورت میں ہاں۔ کسی public hostname کو site address کے طور پر درج کرنا ہی مکمل configuration ہے: Caddy ACME کے ذریعے certificate طلب کرتا ہے، port 80 سے redirect فراہم کرتا ہے، اور expiry سے پہلے certificate renew کرتا ہے۔ تاہم دو شرائط اب بھی ضروری ہیں۔ HTTP-01 challenge کے لیے port 80 انٹرنیٹ سے قابل رسائی ہونا چاہیے، اور hostname کا DNS A یا AAAA record پہلے سے VPS کی طرف اشارہ کر رہا ہو، کیونکہ certificate authority نام resolve کر کے اسی سے دوبارہ connect کرتی ہے۔

کیا میں ایک ہی VPS پر Nginx اور Traefik چلا سکتا ہوں؟

ایک ہی ports پر نہیں۔ جو بھی دوسری service کے بعد start ہوگی، وہ bind کرنے میں ناکام رہے گی۔ nginx bind() to 0.0.0.0:443 failed (98: Address already in use) دکھاتا ہے، جبکہ Traefik اسی نوعیت کا bind error log کر کے exit ہو جاتا ہے۔ ایک proxy کو 80 اور 443 پر چلائیں اور باقی تمام services کو اس کے پیچھے رکھیں۔ اگر آپ migration کر رہے ہیں تو hostnames ایک ایک کر کے منتقل کریں: آخری site منتقل ہونے تک front proxy کو loopback port پر موجود پرانے proxy کی طرف forward کرنے دیں۔

Nginx کے پیچھے 60 seconds کے بعد میرے websockets کیوں disconnect ہو جاتے ہیں؟

proxy_read_timeout کی default value 60 seconds ہے، اور upgrade مکمل ہونے کے بعد یہ tunnel پر لاگو ہوتی ہے۔ اس لیے ایک منٹ تک network traffic نہ ہونے پر proxy connection بند کر دیتا ہے، آپ کی app نہیں۔ اس location میں proxy_read_timeout 3600s; کے ذریعے timeout بڑھائیں، یا application کو ہر 30 seconds بعد ping frame بھیجنے دیں۔ Caddy اور Traefik ایک منٹ کے timer پر idle upgraded connections بند نہیں کرتے۔ اسی لیے وہی app ان کے پیچھے مستحکم، مگر Nginx کے پیچھے غیر مستحکم دکھائی دے سکتی ہے۔