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

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

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

HTTPS நிர்வாகம் தானாகவே நடக்க வேண்டும் மற்றும் உங்கள் சேவைகள் சாதாரண 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 செய்வதையும், சான்றிதழைத் தானாகவே புதுப்பிப்பதையும் அதுவே கவனித்துக்கொள்ளும். இதற்கு இரண்டாவது கருவியோ அல்லது சரிபார்க்கும் timer-ஓ தேவையில்லை. சான்றிதழ்கள் caddy பயனரின் data directory-ல் சேமிக்கப்படும். package install செய்யும்போது இது /var/lib/caddy/.local/share/caddy-ல் இருக்கும், எனவே அந்தப் பாதையை உங்கள் backups-ல் சேர்க்கவும் அல்லது rebuild செய்த பிறகு புதிய சான்றிதழைப் பெறவும். பொதுவெளியில் இல்லாத (non-public) hostname-க்கு, tls internal Caddy-ன் சொந்த local certificate authority மூலம் கையொப்பமிடும். இது 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 புதுப்பித்தல் பாதை சரியாக வேலை செய்கிறதா என்பதை நிரூபிக்கும். இதற்கான விரிவான வழிமுறைகள் Ubuntu 24.04-ல் Nginx உடன் Certbot என்பதில் உள்ளன. நீங்கள் குறிப்பிட விரும்பும் subdomains-ஐ விட அதிகமானவை இருந்தால், DNS-01 challenge மூலம் wildcard certificate பெறவும் இதே கருவியைப் பயன்படுத்தலாம்.

Traefik-ல் சொந்தமாக ACME client உள்ளது. நீங்கள் static configuration-ல் ஒரு certificate resolver-ஐ configure செய்தால் போதும், ஒவ்வொரு 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-ஐ அணுக முடிய வேண்டும், ஏனெனில் சான்றிதழ் அதிகாரம் (Certificate Authority) மீண்டும் உங்களை இணைக்க முயற்சிக்கும். port 443-ஐ மட்டும் திறந்து வைத்தால், சான்றிதழ் பெறுதல் தோல்வியடையும்; அது DNS பிழை போன்ற செய்தியைக் காட்டும்.

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

பணி: 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

ஒவ்வொரு reload-க்கு முன்பும் nginx -t மூலம் syntax is ok மற்றும் test is successful ஆகியவற்றை அச்சிட்டுச் சரிபார்ப்பது அவசியம். இரண்டாவது app-க்கு, hostname மற்றும் port-ஐ மாற்றிய அதே block-ஐப் பயன்படுத்த வேண்டும். proxy_set_header வரிகள் அலங்காரத்திற்காக அல்ல: proxy_pass ஒரு முகவரியைக் குறிப்பிடும்போது, Nginx இயல்பாகவே Host: 127.0.0.1:8080-ஐ upstream-க்கு அனுப்பும். இதனால், Host header-ஐ வைத்து absolute URL-களை உருவாக்கும் ஒரு app, உங்கள் பயனர்களை localhost-க்கு திருப்பிவிடும். அந்த நான்கு headers-ன் பயன் என்ன, proxy_pass-ல் உள்ள trailing slash ஏன் உங்கள் app பெறும் path-ஐ மாற்றுகிறது என்பது Nginx server block குறித்த இந்த விளக்கத்தில் விரிவாக உள்ளது.

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 அனுப்பும் headers-ஐ இது புறக்கணிப்பதால், ஒரு request தனது பிறப்பிடம் குறித்து backend-ஐ ஏமாற்ற முடியாது. Certificates, port 80 redirect மற்றும் renewal ஆகிய அனைத்தும் அந்த இரண்டு site முகவரிகளிலிருந்தே தானாகச் செயல்படும். கோப்பில் வேறு எதையும் இதற்காகக் குறிப்பிடத் தேவையில்லை.

Traefik

எந்தவொரு routing-ஐயும் செய்வதற்கு முன் 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-ம் தனது சொந்த routing-ஐ, labels மூலம், அதன் சொந்த compose கோப்பிலேயே வைத்திருக்கும்:

    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-களை routing செய்வது என்ற பகுதியில் உள்ளது.

ஒவ்வொரு கூடுதல் 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 ஒரு கோரிக்கையை நிறைவேற்றுவதற்கு முன்பு 17 வரிகள் கொண்ட static configuration-ஐக் கோருகிறது, அதன் பிறகு ஒவ்வொரு app-க்கும் 5 labels தேவைப்படுகிறது.

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

இந்த வரி எண்ணிக்கை Nginx-க்கு சாதகமாகத் தோன்றலாம். அந்த ஒவ்வொரு தொகுதிக்கும் ஒரு symlink, ஒரு nginx -t, ஒரு reload மற்றும் ஒரு certbot run தேவைப்படுகிறது, அதே சமயம் Caddy மாற்றத்திற்கு ஒரு reload மட்டுமே தேவை, Traefik மாற்றத்திற்கு எந்தக் கட்டளையும் தேவைப்படுவதில்லை. இவை மூன்றுமே live connections-ஐத் துண்டிக்காமல் 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 அணுகலுக்குச் சமம். அதை read-only ஆக mount செய்வது ஆபத்தைக் குறைக்கும், ஆனால் முழுமையாக நீக்காது. உங்கள் threat model-க்கு இது முக்கியமென்றால், Traefik-க்குத் தேவையான container list endpoints-ஐ மட்டும் வெளிப்படுத்தும் ஒரு socket proxy-ஐ இடையில் வைக்கவும்.

Caddy ஒரு community plugin மூலம் label அடிப்படையிலான discovery-ஐச் செய்ய முடியும். ஆனால், Caddy plugins-ஐ உள்ளேயே 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 இருப்பதற்குக் காரணம், 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-ல் அவற்றுக்கெனத் தனித்தனி entrypoints-ல் TCP மற்றும் UDP routers உள்ளன. Caddy-க்கு மற்றொரு plugin தேவை, எனவே அதற்குத் தனிப்பயன் build தேவைப்படும்.
• ஏற்கனவே proxy-க்கு பின்னால் இருக்கும் web server. service ஒரு classic PHP application என்றால், a LAMP stack on Ubuntu 24.04 ஏற்கனவே Apache-ஐ உள்ளடக்கியிருக்கும். ஒரு proxy-ஐ அதற்கு முன்னால் வைக்கும்போது, headers-ஐ அமைப்பதற்கும் URL-ஐ மாற்றுவதற்கும் இரண்டு இடங்கள் உருவாகும். எதில் TLS termination செய்வது என்பதை முடிவு செய்துவிட்டு, மற்றொன்றை loopback-ல் பிணைக்கப்பட்ட plain HTTP-ல் வைத்திருக்கவும்.

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

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

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

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

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

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

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

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

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

நீங்கள் எதைத் தேர்ந்தெடுத்தாலும் ஒரு விதி பொதுவானது. பொதுவான 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 தேவையில்லையா?

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

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

ஒரே ports-ல் இயக்க முடியாது. முதலில் தொடங்கும் service-ஐத் தவிர மற்றொன்று bind ஆகத் தவறிவிடும். Nginx bind() to 0.0.0.0:443 failed (98: Address already in use) என்ற பிழையைக் காட்டும், Traefik-ம் அதே போன்ற bind error-ஐக் காட்டி வெளியேறும். ஏதேனும் ஒரு 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 upgraded இணைப்புகளை ஒரு நிமிடத்தில் துண்டிப்பதில்லை; இதனால்தான் அதே application Nginx-ன் பின்னால் நிலையற்றதாகவும், மற்றவற்றின் பின்னால் நிலையானதாகவும் காணப்படுகிறது.