Nginx vs Caddy vs Traefik: எது சிறந்த reverse proxy?

Nginx vs Caddy vs Traefik: சுருக்கமான பதில்

Nginx, Caddy மற்றும் Traefik ஆகிய மூன்றும் reverse proxy-ஆக ஒரே பணியைச் செய்கின்றன: இவை 443 port-ல் traffic-ஐக் கவனிக்கும் (listen), ஒவ்வொரு கோரிக்கையிலும் (request) உள்ள hostname-ஐப் படிக்கும், பின்னர் உங்கள் VPS-ல் உள்ள சரியான service-க்கு அதை அனுப்பும். இந்த மூன்றில் எதைப் பயன்படுத்தினாலும், நான்கு self-hosted application-களை ஒரே public IP address-க்கு பின்னால் கொண்டு வர முடியும். இவை அனைத்தும் மிக வேகமாகச் செயல்படக்கூடியவை, எனவே உங்கள் application-களே மெதுவான பகுதியாக இருக்கும். இவற்றிற்கு இடையே உள்ள வேறுபாடு, TLS (transport layer security) certificate-ஐ ஒவ்வொன்றும் எவ்வாறு பெறுகிறது மற்றும் ஒவ்வொரு புதிய application-க்கும் எவ்வளவு configuration தேவைப்படுகிறது என்பதில் உள்ளது. பொதுவான tutorial-களில் விடுபட்ட ஏதேனும் ஒரு வசதி உங்களுக்குத் தேவைப்படும்போது, மற்ற வேறுபாடுகள் வெளிப்படும்.

HTTPS தானாகவே கையாளப்பட வேண்டும் மற்றும் உங்கள் services சாதாரண web application-களாக இருந்தால், Caddy-ஐத் தேர்ந்தெடுக்கவும். அனைத்தும் Docker Compose-ல் இயங்கினால் மற்றும் நீங்கள் அடிக்கடி புதிய service-களைச் சேர்த்துக் கொண்டிருந்தால், Traefik-ஐத் தேர்ந்தெடுக்கவும். நீங்கள் ஏற்கனவே Nginx-ஐப் பயன்படுத்திக் கொண்டிருந்தாலோ, அல்லது response caching, client certificates, raw TCP forwarding போன்ற வசதிகள் தேவைப்பட்டாலோ, அல்லது ஏற்கனவே உள்ள பெரிய configuration-ஐ மீண்டும் எழுத விரும்பவில்லை என்றாலோ, Nginx-ஐத் தேர்ந்தெடுக்கவும்.

ஒவ்வொரு கருவியும் எவ்வாறு TLS certificate-ஐப் பெறுகிறது?

பெரும்பாலான பயனர்களுக்கு இந்த அம்சம் தான் முடிவெடுக்கும் காரணியாக அமைகிறது, எனவே இங்கிருந்து தொடங்குங்கள். இறுதியில் இவை மூன்றுமே ஒரே சான்றிதழ் வழங்கும் அமைப்பிலிருந்து (Certificate Authority) ஒரே மாதிரியான சான்றிதழைப் பெறுகின்றன. ஆனால், அதை அடைவதற்கான வழிமுறைகள் வெவ்வேறானவை.

Caddy ஒரு hostname-ஐக் குறிப்பிட்டவுடன் தானாகவே சான்றிதழைக் கோருகிறது. app.example.com என்பதை site address-ஆகக் குறிப்பிட்டால், Caddy Let's Encrypt-லிருந்து ACME (automatic certificate management environment) மூலம் சான்றிதழைக் கோரும். அது தோல்வியுற்றால் ZeroSSL-க்கு மாறும், port 80-ல் HTTP-லிருந்து HTTPS-க்கு redirect செய்யும், மேலும் தானாகவே சான்றிதழைப் புதுப்பிக்கும் (renew). இதற்குத் தனியான கருவியோ அல்லது கால இடைவெளியைச் சரிபார்க்கும் timer-ஓ தேவையில்லை. சான்றிதழ்கள் caddy பயனரின் data directory-ல் சேமிக்கப்படும்; package install செய்திருந்தால் அது /var/lib/caddy/.local/share/caddy-ல் இருக்கும். எனவே, அந்தப் பாதையை உங்கள் backup-ல் சேர்க்கவும் அல்லது rebuild செய்த பிறகு புதிய சான்றிதழைப் பெறவும். பொது இணையத்தில் இல்லாத hostname-களுக்கு, Caddy தனது சொந்த local certificate authority மூலம் tls internal-ஐக் கையொப்பமிடும். இது Ubuntu-வில் self-signed certificate உருவாக்குவதற்கு இணையானது, ஆனால் இதில் புதுப்பித்தல் பணி தானாகவே நடக்கும்.

Nginx-ல் ACME client கிடையாது. Certbot சான்றிதழைப் பெற்றுத் தரும், அதன் --nginx plugin உங்கள் server block-ஐ மாற்றி 443 listener மற்றும் redirect-ஐச் சேர்க்கும். சான்றிதழ் புதுப்பித்தல் பணி, package install செய்யும் systemd timer மூலம் நடக்கும். எனவே, இதில் இரண்டு பகுதிகள் உள்ளன, இரண்டையும் சரிபார்க்க வேண்டும்: systemctl list-timers | grep certbot என்பது timer இருப்பதை உறுதிப்படுத்தும், sudo certbot renew --dry-run என்பது புதுப்பித்தல் பாதை சரியாகச் செயல்படுவதை உறுதிப்படுத்தும். இதற்கான விரிவான வழிமுறைகள் Nginx உடன் Ubuntu 24.04-ல் Certbot என்பதில் உள்ளன. நீங்கள் பட்டியலிட விரும்பும் subdomain-களை விட அதிகமானவை இருந்தால், DNS-01 challenge மூலம் wildcard certificate பெறுவதற்கும் இதே கருவியைப் பயன்படுத்தலாம்.

Traefik-ல் சொந்தமாகவே ACME client உள்ளது. நீங்கள் static configuration-ல் ஒரு certificate resolver-ஐ உருவாக்கினால், ஒவ்வொரு router-ம் அதைப் பயன்படுத்திக்கொள்ளலாம். கணக்கு விசை (account key) மற்றும் சான்றிதழ்கள் உட்பட அனைத்துத் தகவல்களும் ஒரே acme.json கோப்பில் இருக்கும். அந்த உரிமையாளரைத் தவிர மற்றவர்கள் அந்தக் கோப்பைப் படிக்க முடிந்தால், 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-ஐயே அந்தக் கோப்பை உருவாக்க விடுங்கள். நீங்களாகவே touch மூலம் அதை உருவாக்கினால், அது உங்கள் umask-ஐப் பெற்றுக்கொள்ளும்; இதுவே பலருக்குப் பிழையை ஏற்படுத்தும் காரணியாக அமைகிறது.

இந்த மூன்று கருவிகளுக்கும் ஒரு பொதுவான உண்மை உண்டு. HTTP-01 challenge-க்கு இணையத்திலிருந்து port 80-ஐ அணுக முடியும், ஏனெனில் சான்றிதழ் வழங்கும் அமைப்பு மீண்டும் உங்களை இணைக்க முயற்சிக்கும். 443-ஐ மட்டும் திறந்து வைத்தால், அது DNS பிழை போன்ற ஒரு செய்தியைக் காட்டி சான்றிதழ் பெறுதலைத் தோல்வியடையச் செய்யும்.

மூன்று வெவ்வேறு கட்டமைப்புகளில் ஒரே இரண்டு-app ரூட்டிங் பணி

இந்த பணி: app.example.com என்பது 127.0.0.1:8080-ல் உள்ள ஒரு service-க்கும், files.example.com என்பது 127.0.0.1:8081-ல் உள்ள ஒரு service-க்கும் HTTPS வழியாகச் செல்ல வேண்டும். ஒவ்வொரு proxy-யிலும் இதற்கான முழுமையான கட்டமைப்பு கீழே கொடுக்கப்பட்டுள்ளது, இதன் மூலம் வார்த்தைகளின் எண்ணிக்கையில் உள்ள வேறுபாட்டை நீங்கள் நேரடியாகக் காணலாம்.

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 செய்து, சோதித்து, 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 ஆகியவற்றைச் சரிபார்ப்பது ஒவ்வொரு reload-க்கு முன்பும் செய்ய வேண்டிய கட்டாயமாகும். இரண்டாவது app-க்கு, hostname மற்றும் port-ஐ மட்டும் மாற்றி அதே தொகுப்பைப் பயன்படுத்தவும். proxy_set_header வரிகள் அலங்காரத்திற்காக அல்ல: proxy_pass ஒரு முகவரியைக் குறிப்பிடும்போது, Nginx இயல்பாகவே Host: 127.0.0.1:8080-ஐ upstream-க்கு அனுப்பும். எனவே, Host header-ஐக் கொண்டு absolute URL-களை உருவாக்கும் ஒரு app, உங்கள் பயனர்களை localhost-க்கு திருப்பிவிடும்.

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

இதுவே முழுமையான கோப்பு. reverse_proxy தானாகவே X-Forwarded-For, X-Forwarded-Proto மற்றும் X-Forwarded-Host ஆகியவற்றை அமைத்துக்கொள்ளும். இயல்பாகவே, client அனுப்பும் header-களை அது புறக்கணிக்கும், எனவே ஒரு request உங்கள் backend-க்கு அது எங்கிருந்து வந்தது என்பது குறித்து தவறான தகவலைத் தர முடியாது. Certificates, port 80 redirect மற்றும் renewal ஆகிய அனைத்தும் அந்த இரண்டு site முகவரிகளிலிருந்தே செயல்படும். கோப்பில் வேறு எதையும் இதற்காகக் குறிப்பிடத் தேவையில்லை.

Traefik

எந்தவொரு traffic-ஐயும் route செய்வதற்கு முன் Traefik-க்கு ஒரு static configuration தேவை. ஆகஸ்ட் 2026 நிலவரப்படி தற்போதைய image tag-ஐக் கொண்ட ஒரு Compose service-ஆக:

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-ம் அதன் சொந்த compose கோப்பில், 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 ஒரு பகிரப்பட்ட Docker network வழியாகவே container-ஐ அடைகிறது. இந்த app-க்கு ports: வரி தேவையே இல்லை, இதுவே இதன் உண்மையான நன்மையாகும்: Traefik மட்டுமே public-ஆக வெளியிடப்படுகிறது. பகிரப்பட்ட network மற்றும் redirect middleware உள்ளிட்ட முழுமையான கட்டமைப்பு Traefik மற்றும் Docker Compose மூலம் பல app-களை ரூட்டிங் செய்தல் பகுதியில் உள்ளது.

ஒவ்வொரு கூடுதல் application-க்கும் எவ்வளவு 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
  }
]

மேலே உள்ள தொகுதிகளிலிருந்து கணக்கிடப்பட்டுள்ளது. Nginx server block-க்கு 11 காலியாக இல்லாத வரிகள் தேவைப்படுகின்றன, மேலும் ஒவ்வொரு hostname-க்கும் இதை நீங்கள் மீண்டும் எழுத வேண்டும். Caddy site block-க்கு 3 வரிகள் தேவைப்படுகின்றன. Traefik-ல் ஒரு கோரிக்கையை (request) நிறைவேற்றுவதற்கு முன் 17 வரிகள் கொண்ட static configuration தேவைப்படுகிறது, அதன் பிறகு ஒவ்வொரு app-க்கும் 5 labels தேவைப்படும்.

இதில் எது சிறந்தது என்பதை விட, எதற்கான பலன் என்ன என்பதை கவனியுங்கள். முதல் app-க்கு முன் Traefik-க்கு அதிகப்படியான வேலை தேவைப்படுகிறது, ஆனால் அதன் பிறகு வரும் ஒவ்வொரு app-க்கும் மிகக் குறைந்த வேலையே தேவைப்படுகிறது; இந்த இரண்டு மொத்த அளவுகளும் மூன்றாவது தளத்தின் போது சமநிலையை அடைகின்றன. அதற்கு குறைவாக இருக்கும்போது, static configuration என்பது உங்களுக்குத் தேவையில்லாத கூடுதல் சுமையாகும். அதற்கு மேல் செல்லும்போது, labels முறை சிறந்து விளங்குகிறது, ஏனெனில் routing விவரங்கள் அது எந்த service-ஐ வழிநடத்துகிறதோ, அந்த service-க்கு அருகிலேயே அமைந்துவிடுகின்றன. ஒரு service-ஐ நீக்கினால் அதன் route-ம் நீக்கப்பட்டுவிடும்; இதுவே மையப்படுத்தப்பட்ட configuration கோப்புகளில் உள்ள குறைபாடு: பல மாதங்களுக்கு முன்பே நீக்கப்பட்ட application-களின் server blocks இன்னும் கோப்பில் தேங்கிக் கிடக்கும்.

இந்த வரி எண்ணிக்கை Nginx-க்கு சாதகமாகத் தோன்றலாம். அந்த ஒவ்வொரு block-க்கும் ஒரு symlink, ஒரு nginx -t, ஒரு reload மற்றும் ஒரு certbot run தேவைப்படுகிறது, அதே சமயம் Caddy மாற்றத்திற்கு ஒரு reload மட்டுமே தேவை, Traefik மாற்றத்திற்கு எந்தக் கட்டளையும் (command) தேவைப்படுவதில்லை. இவை மூன்றுமே நேரடி இணைப்புகளைத் துண்டிக்காமல் reload செய்யக்கூடியவை. அதிகாலை ஒரு மணிக்கு நீங்கள் நினைவில் வைத்திருக்க வேண்டிய தனித்தனி படிகளின் எண்ணிக்கையில்தான் உண்மையான வித்தியாசம் உள்ளது.

உங்கள் containers பற்றி எதற்குத் தெரியும்?

Traefik, Docker socket-ஐக் கண்காணித்து, containers தொடங்கும்போதும் நிற்கும்போதும் அவற்றின் labels-லிருந்து routers-ஐ உருவாக்குகிறது. மற்ற எந்த மென்பொருளும் இதைச் செய்வதில்லை. Nginx மற்றும் Caddy ஆகிய இரண்டிற்கும் புதிய container வரும்போது configuration-ஐத் திருத்தி reload செய்ய வேண்டும். மேலும், அவற்றுக்கு அணுகக்கூடிய ஒரு முகவரி தேவை: loopback-ல் வெளியிடப்பட்ட port அல்லது proxy இணைக்கப்பட்ட ஒரு shared Docker network.

இந்த வசதிக்கு ஒரு விலை உண்டு, அதைத் தெளிவாகக் கூறுவது அவசியம். Traefik, /var/run/docker.sock-ஐ வாசிக்கிறது. அந்த socket-உடன் தொடர்புகொள்ளக்கூடிய எவரும், host filesystem-ஐ உள்ளே mount செய்து ஒரு container-ஐத் தொடங்க முடியும்; இது host-ன் root access-க்குச் சமம். அதை read-only ஆக mount செய்வது ஆபத்தைக் குறைக்கும், ஆனால் முழுமையாக நீக்காது. உங்கள் threat model-க்கு இது முக்கியமென்றால், Traefik-க்குத் தேவையான container list endpoints-ஐ மட்டும் வெளிப்படுத்தும் ஒரு socket proxy-ஐ இடையில் பயன்படுத்தவும்.

Caddy ஒரு community plugin மூலம் label அடிப்படையிலான discovery-ஐச் செய்ய முடியும். ஆனால், Caddy plugins-ஐ binary-க்குள் compile செய்ய வேண்டும். எனவே, நீங்கள் ஒரு custom binary அல்லது xcaddy கொண்ட custom image-ஐ உருவாக்க வேண்டும்; அதன் பிறகு அந்த build மற்றும் அதன் updates-க்கு நீங்களே பொறுப்பு. மூன்று அல்லது நான்கு services-க்கு, Caddyfile-ஐத் திருத்துவதே குறைவான வேலை.

Websockets மற்றும் streaming: எவை பாதிக்கப்படுகின்றன, ஏன்?

Nginx-க்கு கூடுதல் கட்டமைப்பு தேவைப்படுகிறது. ஒரு WebSocket இணைப்பு Upgrade: websocket கொண்ட HTTP கோரிக்கையாகத் தொடங்குகிறது. நீங்கள் குறிப்பிடாவிட்டால், hop-by-hop headers-ஐ Nginx upstream-க்கு அனுப்பாது.

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

பின்பு, location தொகுதிக்குள், கீழே உள்ள மூன்று வரிகளும் கண்டிப்பாக இருக்க வேண்டும்:

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

இவற்றைத் தவிர்த்தால், browser console-ல் WebSocket connection to 'wss://app.example.com/ws' failed பிழை தோன்றும், அதே சமயம் உங்கள் backend log-ல் சாதாரண GET கோரிக்கை மட்டுமே பதிவாகும். map இருப்பதற்குக் காரணம், hardcoded Connection: upgrade-ஐ அனைத்து கோரிக்கைகளிலும் அனுப்பினால், close என்று இருக்க வேண்டிய சாதாரண கோரிக்கைகளும் பாதிக்கப்படும் என்பதால் தான்.

Nginx-ன் மேலும் இரண்டு இயல்புநிலை அமைப்புகள் சிக்கலை உருவாக்குகின்றன. proxy_read_timeout என்பது 60 வினாடிகள் ஆகும்; இது upgrade-க்கு பிந்தைய tunnel-க்கும் பொருந்தும். எனவே, ஒரு நிமிடம் போக்குவரத்து இல்லாத WebSocket இணைப்பை proxy துண்டித்துவிடும். மேலும், அந்த location-க்கு proxy_buffering off;-ஐ அமைக்கும் வரை, server-sent events தாமதமாகவோ அல்லது தொகுப்பாகவோ வந்து சேரும். ஏனெனில், உங்கள் பக்கம் காத்திருக்கும்போது Nginx பதிலை அதன் buffer-ல் வைத்திருக்கும்.

Caddy எந்தவொரு கூடுதல் கட்டளையும் இன்றி, இணைப்பை upgrade செய்து இருவழி tunnel-ஆக மாற்றுகிறது. பதில் text/event-stream ஆக இருக்கும்போது அல்லது அதன் நீளம் தெரியாதபோது, அது உடனடியாகத் தரவை அனுப்பிவிடும் (flush), எனவே streaming எந்தத் தடங்கலும் இன்றி இயங்கும். Traefik, upgrade-களை அனுமதிப்பதோடு, நீங்கள் அதன் buffering middleware-ஐச் சேர்க்காத வரை பதில்களை buffer செய்யாது. உங்கள் சேவைகளில் chat, web terminal, log tails அல்லது live dashboards இருந்தால், நீங்கள் எழுத வேண்டிய மற்றும் பிழைத்திருத்தம் செய்ய வேண்டிய கட்டமைப்பில் இது ஒரு பெரிய மாற்றத்தை ஏற்படுத்தும்.

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 தனது கூடுதல் வரிகளுக்கான மதிப்பை நிரூபிக்கிறது.

• 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-ஐ வரையறுத்து, traefik.http.routers.app.tls.options=mtls@file மூலம் router-ஐ அதற்குச் சுட்டிக்காட்ட வேண்டும். labels-ல் அனைத்தையும் கையாளும் முறை, இது போன்ற தேவைகள் வரும்போது விதிவிலக்கைப் பெறுகிறது.
• பெரிய அளவிலான பதிவேற்றங்கள் (Large uploads). Nginx இயல்பாகவே request body-ஐ 1 MB-ஆகக் கட்டுப்படுத்துகிறது. பெரிய கோப்பைப் பதிவேற்றினால் 413 Request Entity Too Large பிழை வரும், error log-ல் client intended to send too large body என்று காட்டும். client_max_body_size-ஐ அதிகரிக்கவும். Caddy மற்றும் Traefik இயல்பாகவே body limit-ஐக் கொண்டிருக்கவில்லை, எனவே request உங்கள் application-ஐச் சென்றடையும், உங்கள் application-ன் சொந்த வரம்பே முடிவெடுக்கும்.
• Response caching. Nginx-ல் proxy_cache உள்ளது, இது முதிர்ச்சியடைந்த வசதியாகும். Caddy-க்கு ஒரு plugin-ஐ compile செய்ய வேண்டும். Traefik-ன் open source build-ல் HTTP cache வசதி இல்லை, இது proxy-கள் அனைத்தும் cache செய்யும் என்று கருதும் பயனர்களுக்கு ஆச்சரியமாக இருக்கலாம்.
• Raw TCP அல்லது UDP, database port அல்லது game server-க்காக. Nginx-ல் stream module உள்ளது. Traefik-ல் அவற்றுக்கெனத் தனித்தனி TCP மற்றும் UDP routers உள்ளன. Caddy-க்கு மற்றொரு plugin தேவை, எனவே அதற்குத் தனிப்பயனாக்கப்பட்ட build தேவைப்படும்.
• Proxy-க்கு பின்னால் ஏற்கனவே உள்ள ஒரு web server. service ஒரு classic PHP application என்றால், Ubuntu 24.04-ல் LAMP stack ஏற்கனவே Apache-ஐ உள்ளடக்கியிருக்கும். ஒரு proxy-ஐ முன்னால் வைக்கும்போது, headers-ஐ அமைப்பதற்கும் URL-ஐ மாற்றுவதற்கும் இரண்டு இடங்கள் உருவாகும். எதில் TLS termination செய்வது என்பதை முடிவு செய்துவிட்டு, மற்றொன்றை loopback-ல் plain HTTP-ஆக வைத்திருக்கவும்.

இந்தத் தேர்வைத் தொடர்ந்து வரும் firewall சிக்கல்

Reverse proxy-ன் முக்கிய நோக்கமே 80 மற்றும் 443 ஆகிய ports-ஐ மட்டும் திறந்த நிலையில் வைத்திருப்பதுதான். ஆனால், Docker இதை அமைதியாக மாற்றுகிறது. -p 8080:80 மூலம் ஒரு port-ஐ வெளியிடும்போது, அது nat table-ல் ஒரு DNAT விதியை எழுதுகிறது. இந்த விதி ufw நிர்வகிக்கும் INPUT விதிகளுக்கு முன்பே செயல்படுத்தப்படுகிறது. எனவே, ufw deny 8080 அந்த இணைப்பைத் தடுக்காது; நீங்கள் கவனமாக அமைத்த proxy-க்கு அருகிலேயே உங்கள் application பொது இணையத்தில் (public internet) வெளிப்படையாக இருக்கும். வெளியிடப்பட்ட ports-ஐ 127.0.0.1:8080:80 மூலம் loopback-க்கு மட்டும் கட்டுப்படுத்துங்கள். அல்லது ports:-ஐ முழுமையாகத் தவிர்த்துவிட்டு, மேலே உள்ள Traefik உதாரணத்தில் உள்ளது போல, Docker network வழியாக proxy அந்த container-ஐ அணுகுமாறு செய்யுங்கள். இதற்கான நுட்பம் மற்றும் தீர்வு Docker published ports ஏன் ufw-ஐத் தவிர்க்கின்றன என்பதில் உள்ளது.

VPS-க்கு வெளியே உள்ள ஒரு கணினியிலிருந்து இதைச் சோதிக்கவும், ஏனெனில் அந்த server-லேயே செய்யப்படும் சோதனை எப்போதும் வெற்றிகரமாகவே அமையும்:

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

Connection refused அல்லது ஒரு timeout கிடைப்பதே நீங்கள் எதிர்பார்க்கும் முடிவு. ஒரு HTTP response கிடைத்தால், உங்கள் proxy வழியாகச் செல்லாமலேயே அந்த application-ஐ அணுக முடிகிறது என்று அர்த்தம்; நீங்கள் மேலே செய்த அனைத்து அமைப்புகளும் வெறும் அலங்காரமே.

எந்த proxy-ஐ நீங்கள் தேர்ந்தெடுக்க வேண்டும்?

பெரும்பாலும் static தளங்கள் மற்றும் ஒன்று அல்லது இரண்டு application-கள் இருந்தால்: Caddy. தானியங்கி HTTPS வசதி, நீங்கள் மீண்டும் மீண்டும் செய்ய வேண்டிய மிகப்பெரிய வேலையை நீக்குகிறது. இதன் configuration ஒரே திரையில் வாசிக்கும் அளவிற்குச் சுருக்கமாக இருக்கும். ஒரு static தளத்திற்கு, அதே site block-க்குள் ஒரு root வரியும் ஒரு file_server வரியும் மட்டுமே தேவைப்படும். ஏதேனும் சிக்கலான பிழை ஏற்படும்போது, இணையத்தில் இதற்கான தீர்வுகள் குறைவாக இருப்பது இதன் ஒரு குறைபாடாகும்.

தொடர்ந்து புதிய சேவைகளைச் சேர்க்கும் docker-compose homelab வைத்திருந்தால்: Traefik. மூன்றாவது service-க்கு மேல் செல்லும்போது, ஒரு மையக் கோப்பை (central file) திருத்துவதை விட labels பயன்படுத்துவது எளிது. ஒரு service-ஐ நீக்கினால், அதன் route-ம் தானாகவே நீங்கிவிடும். முதல்முறை அமைப்பதற்கு ஒரு மதிய நேரத்தை ஒதுக்குங்கள், ஏனெனில் entrypoints, routers, services மற்றும் middlewares ஆகிய அனைத்தும் புதிய கலைச்சொற்களாக இருக்கும். label-ல் ஒரு எழுத்துப் பிழை இருந்தால், அது பெரும்பாலும் Traefik-ல் 404 பிழையாகவே காட்டும், service தொடங்கவில்லை என்று காட்டாது. எனவே, application பழுதடைந்துவிட்டதாகக் கருதும் முன், parse error-ஐக் கண்டறிய docker logs traefik-ஐப் பார்க்கவும்.

ஏற்கனவே உள்ள Nginx configuration அல்லது மேலே உள்ள பட்டியலில் ஏதேனும் குறிப்பிட்ட தேவை இருந்தால்: Nginx. இதில் response caching மற்றும் client certificates-க்கான தீர்வுகள் ஏற்கனவே உள்ளன. மேலும், மூன்றாம் தரப்பு வழிகாட்டிகள் அனைத்தும் Nginx-ஐ அடிப்படையாகக் கொண்டே எழுதப்பட்டுள்ளன. இதன் குறைபாடு என்னவென்றால், certificates மற்றும் websocket ஆதரவை நீங்களே கட்டமைக்க வேண்டும்; அவை தானாகக் கிடைக்காது.

நீங்கள் எதைத் தேர்ந்தெடுத்தாலும் ஒரு விதி பொதுவானது. பொதுவான interface-ல் (public interface) ஒரே ஒரு process மட்டுமே listen செய்ய வேண்டும். மற்ற அனைத்தும் loopback அல்லது ஒரு private Docker network-ல் மட்டுமே இயங்க வேண்டும்.

FAQ

ஒரே VPS-ல் சில Docker applications-க்கு எந்த reverse proxy சிறந்தது?

நீங்கள் அவ்வப்போது சேர்க்கும் மூன்று அல்லது நான்கு சேவைகளுக்கு, Traefik சிறந்த தேர்வாகும். ஏனெனில் ஒவ்வொரு application-ம் தனது சொந்த routing labels-ஐக் கொண்டிருக்கும், மேலும் ஒரு மையக் கோப்பை (central file) திருத்த வேண்டிய அவசியமில்லை. சேவைகள் நிலையானதாக இருந்து, HTTPS நிர்வாகத்தை மட்டும் எளிதாக்க விரும்பினால், Caddy-ஐக் கற்றுக்கொள்வது எளிது, அதில் பிழைகள் ஏற்படுவதும் குறைவு. Nginx உங்களுக்கு ஏற்கனவே தெரிந்திருந்தால் அல்லது response caching, plain TCP listener போன்ற பிற கருவிகளில் இல்லாத வசதிகள் தேவைப்பட்டால், Nginx-ஐத் தேர்ந்தெடுக்கவும்.

Caddy-க்கு உண்மையிலேயே certificate configuration தேவையில்லையா?

சாதாரண சூழல்களில், தேவையில்லை. ஒரு பொதுவான hostname-ஐ site address-ஆகக் குறிப்பிட்டாலே போதுமானது. Caddy தானாகவே ACME மூலம் certificate-ஐப் பெற்று, port 80-லிருந்து redirect செய்து, காலாவதியாகும் முன் புதுப்பித்துக்கொள்ளும். இரண்டு விஷயங்கள் சரியாக இருக்க வேண்டும்: HTTP-01 challenge-க்காக port 80 இணையத்திலிருந்து அணுகக்கூடியதாக இருக்க வேண்டும். மேலும், அந்த hostname-ன் DNS A அல்லது AAAA record ஏற்கனவே உங்கள் VPS-ஐச் சுட்டிக்காட்ட வேண்டும், ஏனெனில் certificate authority அந்தப் பெயரைத் தீர்த்து (resolve) மீண்டும் இணைப்பை ஏற்படுத்தும்.

ஒரே VPS-ல் Nginx மற்றும் Traefik இரண்டையும் இயக்க முடியுமா?

ஒரே ports-ல் இயக்க முடியாது. இரண்டாவதாகத் தொடங்கும் எதுவாக இருந்தாலும், அது bind ஆகத் தவறிவிடும். Nginx bind() to 0.0.0.0:443 failed (98: Address already in use) என்ற பிழையைக் காட்டும், Traefik-ம் அதே போன்ற bind பிழையைக் காட்டி வெளியேறும். ஏதேனும் ஒரு proxy-ஐ மட்டும் 80 மற்றும் 443 ports-ல் இயக்கி, மற்ற அனைத்தையும் அதன் பின்னால் வைக்கவும். நீங்கள் migration செய்கிறீர்கள் என்றால், hostnames-ஐ ஒவ்வொன்றாக மாற்றவும்: கடைசி தளம் மாறும் வரை, front proxy மூலம் பழைய proxy-க்கு loopback port வழியாக traffic-ஐ அனுப்பவும்.

Nginx-ன் பின்னால் இருக்கும் எனது websockets ஏன் 60 வினாடிகளுக்குப் பிறகு துண்டிக்கப்படுகின்றன?

proxy_read_timeout இயல்பாகவே 60 வினாடிகளாக அமைக்கப்பட்டுள்ளது. upgrade முடிந்ததும் இந்த வரம்பு tunnel-க்கு பொருந்தும். எனவே, ஒரு நிமிடம் traffic இல்லாத இணைப்பை உங்கள் application-ஐ விட proxy-யே துண்டித்துவிடும். அந்த location-ல் proxy_read_timeout 3600s; மூலம் நேரத்தை அதிகரிக்கவும், அல்லது உங்கள் application மூலம் ஒவ்வொரு 30 வினாடிக்கும் ஒரு ping frame அனுப்பவும். Caddy மற்றும் Traefik ஒரு நிமிட காலக்கெடுவில் idle இணைப்புகளைத் துண்டிப்பதில்லை. இதனால்தான் அதே application Nginx-ன் பின்னால் நிலையற்றதாகவும், மற்றவற்றின் பின்னால் நிலையானதாகவும் தோன்றுகிறது.