రివర్స్ ప్రాక్సీ: ఒకే అడ్రస్పై అనేక అప్లికేషన్లు
డొమైన్లు మరియు పాత్ల ద్వారా ఒక పబ్లిక్ VDS అడ్రస్ను అనేక అప్లికేషన్ల మధ్య ఎలా పంచుకోవాలి, హెడర్లను సరిగ్గా పంపాలి, మరియు WebSocket ను ఎలా పాడు చేయకూడదు.
23 ఆగస్టు, 2026న నవీకరించబడింది
ఒక మెషీన్కు ఒకే ఒక పబ్లిక్ IPv4 అడ్రస్ ఉంటుంది, కానీ సాధారణంగా అది అనేక అప్లికేషన్లను నడుపుతుంది. రివర్స్ ప్రాక్సీ పోర్టులు 80 మరియు 443పై వచ్చే అన్ని రిక్వెస్ట్లను స్వీకరించి, డొమైన్ పేరు లేదా పాత్ ఆధారంగా వాటిని అంతర్గత సర్వీసులకు రూట్ చేస్తుంది. అదే ఒకే సర్టిఫికెట్ను మరియు షేర్డ్ లాగ్లను కూడా నిర్వహిస్తుంది.
లేఅవుట్
ప్రతి అప్లికేషన్ తన స్వంత లోకల్ పోర్ట్పై, అది కూడా 127.0.0.1పై మాత్రమే వినిపిస్తుంది:
- ఫ్రంటెండ్ సైట్ —
127.0.0.1:3000; - API —
127.0.0.1:8000; - మానిటరింగ్ డాష్బోర్డ్ —
127.0.0.1:9090.
బయటికి Nginx మాత్రమే ఎక్స్పోజ్ అవుతుంది. ఏదైనా అప్లికేషన్ నేరుగా ఎక్స్పోజ్ కాలేదని నిర్ధారించుకోవడానికి:
ss -tulpn | grep LISTEN
0.0.0.0:3000 లాంటి లైన్లు అంటే ఆ సర్వీస్ ప్రాక్సీని బైపాస్ చేసి, ఎన్క్రిప్షన్ లేకుండా ఇంటర్నెట్ నుండి చేరుకోగలదని అర్థం.
డొమైన్ ద్వారా
server {
listen 80;
server_name app.example.ru;
location / {
proxy_pass http://127.0.0.1:3000;
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;
}
}
server {
listen 80;
server_name api.example.ru;
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
X-Forwarded-For లేకపోతే, అప్లికేషన్ ప్రతి రిక్వెస్ట్ను 127.0.0.1 నుండి వచ్చినట్టే చూస్తుంది, దాంతో IP ఆధారిత నిబంధనలు ఏవీ పనిచేయవు.
పాత్ ద్వారా
location /api/ {
proxy_pass http://127.0.0.1:8000/;
}
ఇక్కడ proxy_passలోని చివరి స్లాష్ ముఖ్యం: అది ఉంటే /api ప్రిఫిక్స్ తీసివేయబడి అప్లికేషన్కు /users అందుతుంది; అది లేకపోతే /api/users అందుతుంది. ప్రాక్సీపై వచ్చే “రహస్యమైన 404లు”లో సగం సరిగ్గా ఇదే కారణం.
WebSocket మరియు సుదీర్ఘ రెస్పాన్స్లు
location /ws/ {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s;
}
Upgrade/Connection జోడీ లేకపోతే, హ్యాండ్షేక్ తర్వాత వెంటనే కనెక్షన్ పోతుంది; పెంచిన టైమౌట్ లేకపోతే, ఒక నిమిషం నిశ్శబ్దం తర్వాత అది పోతుంది.
సాధారణ తప్పులు
| లక్షణం | కారణం |
|---|---|
502 Bad Gateway | అప్లికేషన్ నడుస్తూ లేదు లేదా వేరే పోర్ట్పై వినిపిస్తోంది |
504 Gateway Time-out | అప్లికేషన్ రెస్పాన్స్ ఇవ్వడానికి proxy_read_timeout కంటే ఎక్కువ సమయం తీసుకుంటోంది |
| అనంతమైన రీడైరెక్ట్ | అప్లికేషన్కు HTTPS గురించి తెలియదు — X-Forwarded-Proto పంపండి |
| ఫైల్ అప్లోడ్లు విరిగిపోతున్నాయి | client_max_body_size చాలా చిన్నది; డిఫాల్ట్ 1 MB |
| అప్లికేషన్ లాగ్లలో అదే IP | X-Forwarded-For పంపబడటం లేదు |
తర్వాత: బహుళ సైట్లు, సర్టిఫికెట్, ఆటోమేటిక్ HTTPSతో Caddy.
ప్రాక్సీపై ఉన్న ఒకే సర్టిఫికెట్ దాని వెనుక ఉన్న అన్ని అప్లికేషన్లను కవర్ చేస్తుంది.
127.0.0.1ద్వారా జరిగే అంతర్గత కనెక్షన్లకు ఎన్క్రిప్షన్ అవసరం లేదు — అవి మెషీన్ను ఎప్పటికీ విడిచిపెట్టవు.