द्वारे Matt Connor 2026-08-06 · अपडेटेड 2026-08-13

HTTP म्हणजे काय? Server admin साठी मार्गदर्शक

Q: HTTP आणि HTTPS मधील फरक काय आहे?

HTTPS म्हणजे TLS (transport layer security) सत्रामध्ये पाठवलेले HTTP. Methods आणि status codes समान असतात. फरक एवढाच की client आणि TLS termination करणाऱ्या घटकामधील bytes encrypted असतात आणि default port 80 वरून 443 होतो. पहिला HTTP byte पाठवण्यापूर्वी TLS handshake पूर्ण होते. त्यामुळे certificate failure मुळे status code तयार होत नाही. म्हणून browser certificate warning मध्ये 403 सारखा अंक न दाखवता NET::ERR_CERT_COMMON_NAME_INVALID सारखे error name दिसते.

Q: माझी site 502 Bad Gateway का दाखवते?

nginx कडून मिळणारा 502 याचा अर्थ nginx ज्या upstream कडे proxy करते, त्याच्याकडून usable response मिळाला नाही. त्यामुळे visitor ची request योग्य होती, परंतु nginx च्या मागील बाजूस काहीतरी अयशस्वी झाले. /var/log/nginx/error.log वाचा. connect() failed (111: Connection refused) while connecting to upstream याचा अर्थ proxy_pass मधील address आणि port वर काहीही listening करत नाही. त्यामुळे application सुरू आहे आणि अपेक्षित ठिकाणी bind झाली आहे का ते तपासा. no live upstreams while connecting to upstream याचा अर्थ repeated failures नंतर upstream block मधील प्रत्येक server down म्हणून चिन्हांकित झाला आहे. याची तुलना 504 Gateway Timeout शी करा. याचा अर्थ upstream ने connection स्वीकारले, परंतु proxy_read_timeout मध्ये दिलेल्या वेळेत response देण्यात अयशस्वी झाले.

Q: प्रत्येक visitor साठी माझ्या access log मध्ये समान IP address का दिसतो?

कारण $remote_addr TCP connection उघडणाऱ्या घटकाचा address नोंदवते. reverse proxy किंवा content delivery network च्या मागे हा address proxy चा असतो. Visitor चा address त्याऐवजी X-Forwarded-For header मध्ये येतो. Proxy वर proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; सेट करा. त्यानंतर receiving nginx वर set_real_ip_from मध्ये proxy ची address range सेट करा आणि real_ip_header X-Forwarded-For;. तुम्ही नियंत्रित करत असलेल्या rangesच सूचीबद्ध करा. हा header कोणताही client पाठवू शकतो. त्यामुळे संपूर्ण internet कडून त्यावर विश्वास ठेवल्यास visitor log आणि rate limit साठी वापरला जाणारा address स्वतः निवडू शकतो.

Q: मला HTTP/2 किंवा HTTP/3 सुरू करणे आवश्यक आहे का?

HTTP/2 सुरू करणे उपयुक्त आहे. आधीच TLS असलेल्या site वर त्यासाठी एक directive पुरते आणि अनेक लहान files असलेल्या page ला धीमे करणारी प्रत्येक connection वरील request limit दूर होते. HTTP/3 चा फायदा कमी आणि कमी निश्चित आहे. त्यासाठी open UDP port 443 तसेच QUIC support असलेली proxy build आवश्यक असते. Browsers आधीच्या response मध्ये Alt-Svc header दिसल्यानंतरच HTTP/3 कडे switch करतात, हे लक्षात ठेवा. त्यामुळे तुमच्या listen line मध्ये काहीही असले तरी त्या header शिवाय काहीही बदलत नाही. तुमचे visitors प्रत्यक्षात कोणता protocol negotiate करतात हे मोजण्यापूर्वी log format मध्ये $server_protocol जोडा.

Q: File अस्तित्वात असताना 403 Forbidden चा अर्थ काय असतो?

Static site वर 403 म्हणजे सामान्यतः HTTP rule नसून filesystem permission ची समस्या असते. /var/log/nginx/error.log मधील open() ... failed (13: Permission denied) याचा अर्थ nginx worker user file वाचू शकत नाही. बहुतेक वेळा file mode चुकीचा असल्यामुळे नव्हे, तर parent directory मध्ये others साठी execute permission नसल्यामुळे असे होते. directory index of ... is forbidden याचा अर्थ request अशा directory कडे resolve झाली जिथे index file नाही आणि autoindex बंद आहे. Matching location block मधील explicit deny rule देखील 403 परतवते. त्यामुळे error log मध्ये काहीही दिसत नसताना तो block वाचा.

Server चालवणाऱ्यांसाठी HTTP समजून घ्या: methods, status codes, महत्त्वाचे headers, nginx logs, तसेच HTTP/3 आणि TLS यांचे स्थान स्पष्टपणे जाणून घ्या.

HTTP म्हणजे काय?

HTTP (hypertext transfer protocol) हा client आणि web server यांनी एखाद्या गोष्टीची मागणी करण्यासाठी आणि ती परत पाठवण्यासाठी वापरलेल्या नियमांचा संच आहे. client एक request पाठवतो. त्यात GET सारखी method, /pricing सारखा path, protocol version, headers ची यादी आणि कधीकधी body असतो. server status code, जसे की 200, पाठवून उत्तर देतो. त्यानंतर server चे स्वतःचे headers आणि सामान्यतः body असतो. तुमच्या server वरील प्रत्येक page view आणि प्रत्येक API (application programming interface) call म्हणजे हीच देवाणघेवाण पुन्हा पुन्हा होणे.

HTTP स्वतःची कोणतीही state ठेवत नाही. तुम्ही एका सेकंदापूर्वी काय मागितले होते हे server ला लक्षात राहत नाही. त्यामुळे memory सारखे वर्तन आवश्यक असलेली कोणतीही गोष्ट, उदाहरणार्थ login session, प्रत्येक request मधील header मध्ये पाठवली जाते. या एका गुणधर्मामुळे पुढील बराचसा व्यवहार स्पष्ट होतो: caching पूर्णपणे header वर आधारित असते आणि load balancer तुमची पुढील request वेगळ्या backend कडे पाठवू शकतो, तरीही कोणतीही समस्या निर्माण होत नाही.

खालील सर्व माहिती server च्या बाजूने हे मॉडेल कसे दिसते ते स्पष्ट करते. ती तुमच्या access log आणि nginx config मध्ये दिसते.

कच्ची विनंती आणि प्रतिसादाचे स्पष्टीकरण

ही संपूर्ण HTTP/1.1 विनंती आहे. रिकामी ओळ headers संपवते. त्या ओळीनंतरची कोणतीही माहिती body असते. GET ला सामान्यतः body नसतो.

GET /pricing HTTP/1.1
Host: example.com
User-Agent: curl/8.5.0
Accept: */*
Accept-Encoding: gzip

GET ही method आहे. ती कोणती कृती करायची ते सांगते. GET वाचते, POST डेटा पाठवते, PUT बदलते, DELETE काढून टाकते आणि HEAD एखाद्या GET चे headers body शिवाय मागते.
/pricing हा path आहे. hostname हा request line चा भाग नसतो. म्हणून पुढील header आवश्यक असतो.
HTTP/1.1 ही client वापरत असलेली protocol version आहे.
Host: example.com मध्ये client ला हवी असलेली site दिली जाते. HTTP/1.1 मध्ये हा header अनिवार्य आहे. त्यामुळे तो नसलेली विनंती nginx ला मिळाल्यास nginx 400 Bad Request पाठवतो.
उर्वरित headers preferences दर्शवतात. Accept-Encoding: gzip नुसार client डेटा decompress करू शकतो. त्यामुळे server ला body compress करता येतो.

Response ची रचना याच प्रकारची असते. त्याच्या सुरुवातीला status line असते.

HTTP/1.1 200 OK
Date: Thu, 06 Aug 2026 09:12:44 GMT
Server: nginx
Content-Type: text/html; charset=utf-8
Content-Length: 5310
Cache-Control: public, max-age=300

<!doctype html>...

200 OK हा reason phrase सह status code आहे. महत्त्वाचा भाग code असतो. phrase केवळ सजावटीचा असतो आणि clients तो दुर्लक्षित करतात.
Content-Type नंतर येणाऱ्या bytes कडे client ने कसे पाहावे ते सांगतो.
Content-Length हा bytes मधील body चा आकार आहे. त्यामुळे body कुठे संपतो हे client ला समजते. आकार आधी माहीत नसल्यास server त्याऐवजी Transfer-Encoding: chunked पाठवतो आणि zero length chunk ने body ची समाप्ती दर्शवतो.
Cache-Control browser आणि मधील कोणत्याही cache ने हा response किती काळ ठेवावा ते सांगतो.
दोन्ही दिशांमध्ये headers आणि body यांना वेगळे करणारी रिकामी ओळ headers नंतर येते.

Header names साठी अक्षरांचा case महत्त्वाचा नसतो. प्रत्येक ओळ bare newline ऐवजी carriage return नंतर line feed ने संपते. हे तुम्ही हाताने टाइप करणार नाही. मात्र packet capture मध्ये ते दिसतील.

प्रत्यक्ष request आणि response पाहण्यासाठी, तुमच्या मालकीच्या site विरुद्ध हे चालवा:

curl -sS -o /dev/null -D - https://example.com/

-D - response headers तुमच्या terminal वर लिहिते आणि -o /dev/null body टाकून देते. curl -I पेक्षा ही पद्धत वापरा, कारण -I एक HEAD request पाठवते. HEAD ला GET पेक्षा वेगळ्या प्रकारे हाताळणारा application server, आणि असे अनेक servers आहेत, तुम्हाला कोणत्याही browser ला न मिळणारे headers दाखवेल. curl -v दोन्ही बाजू छापते. त्यात request lines वर > आणि response lines वर < चिन्हांकित केलेले असतात.

nginx access log मधील request line कशी दिसते

nginx मध्ये combined log format दिलेला असतो. त्याची व्याख्या अशी आहे:

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

त्यातून तयार होणारी एक ओळ:

203.0.113.45 - - [06/Aug/2026:09:12:44 +0000] "GET /pricing HTTP/1.1" 200 5310 "https://example.com/" "Mozilla/5.0 (X11; Linux x86_64) Chrome/127.0.0.0 Safari/537.36"

203.0.113.45 म्हणजे $remote_addr. हा TCP (transmission control protocol) connection उघडणारा address असतो. Proxy मागे असल्यास हा visitor चा नसून proxy चा address असतो.
पहिला - हा निश्चित placeholder आहे. दुसरा $remote_user आहे. HTTP basic authentication वापरात असल्यासच त्यात मूल्य भरले जाते.
"GET /pricing HTTP/1.1" म्हणजे $request. Request आली तशीच ही request line येथे नोंदवली जाते.
200 म्हणजे तुमच्या server ने परत केलेला status. Visitor ला दिसलेला status यात अभिप्रेत नाही.
5310 म्हणजे $body_bytes_sent, म्हणजे केवळ body. Response headers मोजले जात नाहीत. त्यामुळे प्रत्यक्ष पाठवलेल्या bytes पेक्षा ही संख्या नेहमी कमी असते.
शेवटची दोन उद्धृत fields म्हणजे Referer आणि User-Agent. दोन्ही client कडून येतात. त्यामुळे दोन्हींमध्ये कोणताही मजकूर असू शकतो.

$request जशीच्या तशी नोंदवली जात असल्याने अनावश्यक मजकूरही जशाच्या तसा दिसतो. एखादा client plaintext port 80 वर TLS (transport layer security) वापरून बोलत असल्यास 400 line तयार होते. तिच्या request field ची सुरुवात "\x16\x03\x01\x02\x00\x01" सारख्या escaped bytes ने होते. \x16 हा TLS handshake record type आहे. त्यामुळे ते bytes ClientHello ची सुरुवात असतात; ती request line नसते. तुमचा server योग्य प्रकारे काम करत आहे. काहीतरी HTTPS ला HTTP port कडे पाठवत आहे.

तुमच्या log format मध्ये $server_protocol देखील जोडा. ते HTTP/1.1, HTTP/2.0 किंवा HTTP/3.0 दाखवते. Protocol change प्रत्यक्ष लागू झाला आहे हे सिद्ध करण्याचा हा सर्वात जलद मार्ग आहे.

तुमची स्वतःची साइट हे status codes परत करते तेव्हा त्यांचा अर्थ

पहिला अंक हा वर्ग दर्शवतो. सर्वप्रथम हाच वर्ग वाचा.

2xx म्हणजे विनंती यशस्वी झाली. सामान्य read साठी 200 OK. काहीतरी तयार करणाऱ्या POST नंतर 201 Created. परत पाठवण्यासाठी काहीही नसलेल्या यशस्वी विनंतीसाठी 204 No Content; DELETE चे नेहमीचे उत्तर हेच असते.

3xx म्हणजे दुसरीकडे पाहा. 301 कायमस्वरूपी असते. Browsers ते दीर्घकाळ cache करतात; कधी कधी user ने profile साफ करेपर्यंत ते cache राहते. त्यामुळे चुकीच्या hostname कडे निर्देश करणारे 301 मागे घेणे त्रासदायक ठरते. Redirect ची अजून चाचणी सुरू असेल तर 302 वापरा. 304 Not Modified हे error नसून success आहे: client ने ETag (entity tag) असलेले If-None-Match पाठवले, जे तुम्ही अजूनही ओळखता. त्यामुळे तुम्ही headers पाठवले, पण body पाठवली नाही. Logs मध्ये 304s मोठ्या प्रमाणात दिसत असतील, तर caching कार्यरत आहे.

4xx म्हणजे request चुकीची होती. 400 Bad Request म्हणजे input malformed आहे. 401 Unauthorized चा खरा अर्थ unauthenticated असा आहे. त्यात scheme चे नाव देणारा WWW-Authenticate header असणे आवश्यक आहे. 403 Forbidden म्हणजे request समजली, तरी ती नाकारली. 404 Not Found म्हणजे अस्तित्वात नसलेला path. 405 Method Not Allowed म्हणजे path योग्य आहे, पण method चुकीची आहे. Static file location कडे केलेल्या POST ला हे उत्तर मिळते. 413 म्हणजे body nginx च्या client_max_body_size पेक्षा मोठी आहे. याचे default मूल्य 1 megabyte आहे. Error log मध्ये client intended to send too large body याची पुष्टी करतो.

Static file वर 403 दिसत असेल, तर कारण जवळजवळ नेहमी filesystem मध्ये असते, HTTP rule मध्ये नाही. Configuration बदलण्यापूर्वी /var/log/nginx/error.log वाचा. open() "/srv/site/index.html" failed (13: Permission denied) म्हणजे nginx worker user ला file वाचता येत नाही. याचे सर्वात सामान्य कारण म्हणजे parent directory वर others साठी execute permission नसणे. directory index of "/srv/site/" is forbidden म्हणजे path अशा directory कडे resolve झाला आहे जिथे index file नाही आणि autoindex बंद आहे.

5xx म्हणजे तुमच्या बाजूने बिघाड झाला. 500 म्हणजे application मधील unhandled error. 502 Bad Gateway म्हणजे nginx ला upstream कडून वापरता येईल असा response मिळाला नाही. Error log कारण स्पष्ट करतो: connect() failed (111: Connection refused) while connecting to upstream म्हणजे proxy_pass मधील address वर काहीही listening नाही. 504 Gateway Timeout म्हणजे upstream ने connection स्वीकारले, पण default 60 seconds असलेल्या proxy_read_timeout मध्ये काहीही उत्तर दिले नाही. Log मध्ये याची नोंद upstream timed out (110: Connection timed out) while reading response header from upstream म्हणून होते. 503 Service Unavailable म्हणजे जाणूनबुजून केलेला refusal. लक्षात ठेवा, nginx चा स्वतःचा rate limiter 503 परत करतो, कारण limit_req_status चे default मूल्य 503 आहे. Log मध्ये 429 Too Many Requests शोधताना त्याऐवजी 503 दिसत असेल, तर त्याचे कारण हेच आहे. अचूक code मिळवण्यासाठी limit_req_status 429; सेट करा.

सर्व्हर चालवताना महत्त्वाचे असलेले headers

Host साइट निवडतो. एका IP पत्त्यावर शेकडो hostnames सेवा देऊ शकतात. कोणता server block उत्तर देईल हे ठरवण्यासाठी nginx Host ची server_name शी जुळवणी करतो. काहीही जुळले नाही, तर nginx default server वापरतो. त्या address आणि port वर listening करणारा पहिला block default server असतो, जोपर्यंत दुसऱ्या block ला default_server म्हणून चिन्हांकित केलेले नसते. नवीन virtual host कडून चुकीची साइट मिळणे जवळजवळ नेहमी याच कारणामुळे होते: नाव जुळले नाही आणि request default server कडे गेली. DNS मध्ये बदल न करता याची चाचणी करा:

curl -sS -o /dev/null -D - -H 'Host: app.example.com' http://127.0.0.1/

User-Agent हे client कडून लिहिलेले स्वतःचे वर्णन असते आणि ते free text असते. Logs वाचताना त्याचा फक्त संकेत म्हणून वापर करा. त्याचा कधीही नियंत्रणासाठी वापर करू नका. Client ला त्याबद्दल खोटे सांगायचे असेल, तर तो तसे सहज करू शकतो. त्यामुळे User-Agent नुसार scraper block केल्यास केवळ सभ्यपणे वागणारे scrapers block होतात.

Content-Type bytes चा अर्थ कसा लावायचा हे ठरवतो: API request साठी application/json आणि page साठी text/html; charset=utf-8. nginx file extensions चे types शी mapping /etc/nginx/mime.types वापरून करतो. Packaged nginx.conf default_type application/octet-stream; सेट करते. त्यामुळे nginx ला माहीत नसलेल्या extension असलेली file render करण्याऐवजी download म्हणून दिली जाते. याचे दिसणारे लक्षण म्हणजे styling शिवाय page load होतो आणि browser console मध्ये Refused to apply style from ... because its MIME type ('text/plain') is not a supported stylesheet MIME type दिसते. येथे MIME म्हणजे multipurpose internet mail extensions. या type strings ज्या naming scheme मधून येतात, ते हेच.

Cache-Control तुमच्या server आणि reader यांच्या दरम्यान असलेल्या प्रत्येक cache चे नियंत्रण करण्यासाठी वापरले जाते. ज्यांच्या filename मध्ये content hash असतो अशा assets साठी public, max-age=31536000, immutable योग्य आहे. User-specific कोणत्याही वस्तूवर no-store वापरा. Logged-in page ठेवणारा shared cache तीच URL मागणाऱ्या पुढील व्यक्तीला ती page देऊ शकतो. private ही मधली setting आहे: browser ती page ठेवू शकतो, पण shared cache ठेवू शकत नाही.

X-Forwarded-For proxy मुळे visitor चा पत्ता लपतो म्हणून वापरले जाते. Request reverse proxy मधून गेल्यानंतर $remote_addr हा proxy चा पत्ता असतो. त्यामुळे तुमचे logs, geolocation आणि rate limiting यांना एकच client दिसतो. Proxy ने मूळ पत्ता पुढे पाठवला पाहिजे:

proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Receiving server ला तो पत्ता विश्वासार्ह मानण्यास सांगावे लागते. तसेच नेमक्या कोणत्या पत्त्यांवर विश्वास ठेवायचा हेही सांगावे लागते:

set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;

तुमच्या नियंत्रणाखाली असलेल्या ranges चीच यादी द्या. X-Forwarded-For हा plain text आहे आणि कोणताही client तो पाठवू शकतो. त्यामुळे set_real_ip_from 0.0.0.0/0; मुळे visitor ला logs मध्ये नोंदवला जाणारा आणि rate limiter मध्ये मोजला जाणारा पत्ता स्वतः निवडता येतो.

X-Forwarded-Proto एक विशिष्ट आणि अतिशय सामान्य failure टाळतो. तुमचा proxy TLS termination करतो आणि request plain HTTP वापरून application कडे पाठवतो. Application ला plain request दिसते. त्यामुळे visitor ने HTTPS वापरावे असे ठरवून ते 301 https://example.com/ पाठवते. Browser त्याचे अनुसरण करतो, proxy पुन्हा TLS termination करतो आणि पुन्हा plain HTTP पाठवतो. Browser ERR_TOO_MANY_REDIRECTS देऊन प्रयत्न थांबवेपर्यंत हे loop सुरू राहते. X-Forwarded-Proto: https पाठवल्यास application ला visitor आधीपासून HTTPS वर असल्याचे समजते आणि ते redirect करणे थांबवते.

HTTP/1.1 vs HTTP/2 vs HTTP/3: तुमच्यासाठी काय बदलते

HTTP/1.1 मजकूराधारित आहे आणि प्रत्येक connection वर एका वेळी एकच request हाताळतो. Connection: keep-alive मुळे पुढील request त्याच TCP connection चा पुनर्वापर करू शकते. त्यामुळे connection setup चा खर्च वाचतो. मात्र responses ज्या क्रमाने requests केल्या गेल्या, त्याच क्रमाने परत येतात. एखादा slow response त्याच्या मागे रांगेत असलेल्या सर्व requests ना अडवतो. याला head-of-line blocking म्हणतात. Browsers त्यावर उपाय म्हणून एकाच hostname साठी एकाच वेळी अनेक connections उघडतात.

HTTP/2 मध्ये तेच methods आणि तेच status codes राहतात. मात्र framing binary पद्धतीने केले जाते. अनेक requests स्वतंत्र streams म्हणून एकाच connection वर share करतात. वारंवार येणारा header मजकूर compress केला जातो. आधुनिक request मध्ये header मजकूर मोठ्या प्रमाणात असल्यामुळे हे महत्त्वाचे आहे. Connection अजूनही TCP असते. त्यामुळे एखादा packet हरवल्यास retransmission येईपर्यंत त्या connection वरील प्रत्येक stream थांबतो. Head-of-line blocking नाहीसे झालेले नाही. ते HTTP स्तरावरून transport स्तरावर गेले आहे. Server push हा HTTP/2 चा भाग होता. परंतु Chrome ने 2022 मध्ये त्याचे support काढून टाकल्यामुळे प्रत्यक्ष वापरात ते आता नाही.

HTTP/3 पुन्हा तेच semantics ठेवते आणि TCP ऐवजी QUIC वापरते. QUIC हा UDP (user datagram protocol) वर आधारित transport आहे. QUIC streams खालच्या सर्व स्तरांपर्यंत स्वतंत्र असतात. त्यामुळे एखादा packet हरवल्यास तो ज्या stream चा भाग होता, तीच stream थांबते. TLS 1.3 हा QUIC handshake मध्येच समाविष्ट आहे; तो स्वतंत्र स्तर म्हणून वरून जोडलेला नाही. त्यामुळे नवीन connection साठी कमी round trips लागतात. याचे दोन व्यावहारिक परिणाम आहेत: मार्गातील प्रत्येक firewall मध्ये UDP port 443 उघडा असणे आवश्यक आहे. तसेच UDP वर throttling करणारे किंवा UDP block करणारे कोणतेही network clients ना HTTP/2 कडे परत पाठवेल.

तुमच्यासाठी प्रत्यक्षात काय बदलते. Browsers HTTP/3 ने कधीही सुरुवात करत नाहीत. ते HTTP/2 किंवा HTTP/1.1 वरून connect होतात, response मधील Alt-Svc: h3=":443"; ma=86400 header पाहतात आणि त्या host साठी पुढील connections मध्ये HTTP/3 वापरतात. त्यामुळे हा header केवळ ऐच्छिक सजावट नाही. तो discovery mechanism आहे. nginx मध्ये version 1.25.1 पासून HTTP/2 साठी स्वतंत्र directive आहे (server block मधील http2 on;, जुन्या listen ... http2 parameter च्या जागी). Mainline 1.25.0 मध्ये QUIC आले. त्यामध्ये HTTP/3 site साठी नेहमीच्या listen 443 ssl; सोबत listen 443 quic reuseport; आवश्यक आहे.

या बाबतीत proxies ची maturity वेगवेगळी आहे. त्यामुळे तुम्ही प्रत्यक्ष चालवत असलेल्या version नुसार हे तपासणे योग्य आहे. August 2026 पर्यंत Caddy कोणत्याही configuration शिवाय default ने HTTP/3 serve करते. nginx साठी वर वर्णन केलेला explicit quic listener आणि Alt-Svc header आवश्यक आहे. Traefik मध्ये प्रत्येक entry point साठी explicit http3 option द्वारे ते enable करता येते. तुम्ही अनेक Docker apps च्या समोर Traefik मध्ये TLS terminate करत असाल, तर visitors ना मिळणारी protocol version तिथे ठरते. Browser ने कोणतीही version negotiate केली असली तरी proxy पासून तुमच्या container पर्यंतचा hop साधारणपणे plain HTTP/1.1 असतो.

गृहीत न धरता पडताळा. curl --http3 -sS -o /dev/null -D - https://example.com/ फक्त curl -V च्या features मध्ये HTTP3 सूचीबद्ध असेल तरच काम करते. बहुतांश distribution builds मध्ये ते समाविष्ट नसते. विश्वसनीय तपासणी म्हणजे तुमचा स्वतःचा log. Format मध्ये $server_protocol जोडा आणि प्रत्यक्ष browsers कोणती protocol negotiate करतात ते वाचा. त्यापूर्वी UDP 443 प्रत्यक्षात उघडा आहे याची खात्री करा. कारण केवळ TCP 443 ला परवानगी देणारा firewall HTTP/3 शांतपणे fail होऊ देईल आणि site HTTP/2 वर कार्यरत राहील. तुमच्या Linux server वर कोणते ports open आणि listening आहेत हे जाणून घेणे ही तपासण्याची पहिली गोष्ट आहे.

HTTPS: HTTP हा प्रोटोकॉल आहे, TLS हे त्याचे आवरण आहे

HTTPS हा स्वतंत्र प्रोटोकॉल नाही. TLS सत्राच्या आत पाठविलेल्या त्याच विनंत्या आणि त्याच status codes म्हणजे HTTPS. Port 80 वर या विनंत्या स्पष्ट स्वरूपात वाहतात, तर port 443 वर त्या encrypted स्वरूपात वाहतात. आधी TLS handshake पूर्ण होतो. त्यानंतर HTTP request encrypted channel मधून जाते. याच क्रमामुळे certificate problem ला status code जोडलेला नसतो. एकही HTTP byte पाठवण्यापूर्वीच failure होते. त्यामुळे क्रमांक देण्यासाठी response उपलब्ध नसतो.

एका server वर अनेक sites host केल्या असतील, तर क्रमातील एक तपशील महत्त्वाचा ठरतो. Certificate निवडण्यासाठी SNI (server name indication) वापरले जाते. हा TLS handshake मधील field आहे. कोणताही HTTP header अस्तित्वात येण्यापूर्वी hostname या field मध्ये स्पष्ट स्वरूपात पाठवला जातो. त्यामुळे server प्रथम SNI वरून certificate निवडतो. त्यानंतर Host header वरून virtual host निवडतो. हे दोन स्वतंत्र lookups आहेत आणि सामान्यतः त्यांचे परिणाम जुळतात. ते जुळले नाहीत, तर browser NET::ERR_CERT_COMMON_NAME_INVALID सारखा name mismatch दाखवतो आणि कोणतीही request पाठवत नाही. याचे कारण असे की तुमच्या default server चे certificate ज्या नावासाठी दिले गेले, ते नाव त्या certificate मध्ये समाविष्ट नसते.

Public site साठी वास्तविक certificate मिळवा आणि त्याचे renewal आपोआप होऊ द्या. nginx वर Let's Encrypt सह Certbot तुमच्या server block मध्ये certificate paths लिहिते आणि renewal timer तुमच्यासाठी install करते. Public authority validate करू शकत नाही अशा hostname साठी, उदाहरणार्थ internal name किंवा तुमच्या स्वतःच्या network वरील bare IP address साठी, Ubuntu वर self-signed certificate हा योग्य पर्याय आहे. मात्र प्रत्येक client ला ते certificate trust करण्यास सांगावे लागेल, हे मान्य असणे आवश्यक आहे.

TLS कार्यरत झाल्यावर port 80 वरील सर्व traffic port 443 कडे पाठवा:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

तुम्हाला खात्री असेल तेव्हाच Strict-Transport-Security जोडा. add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always; header browsers ना त्या hostname साठी दोन वर्षे plain HTTP नाकारण्यास सांगतो. Browsers ही सूचना त्यांच्या स्वतःच्या cache मधून लागू करतात. त्यामुळे नंतर header काढून टाकल्याने हा परिणाम पूर्ववत होत नाही. सुरुवातीला काही तासांचा max-age ठेवा. प्रत्येक subdomain खरोखर HTTPS वर आहे याची खात्री करा. त्यानंतर कालावधी वाढवा.

FAQ

HTTP आणि HTTPS मधील फरक काय आहे?

HTTPS म्हणजे TLS (transport layer security) सत्रामध्ये पाठवलेले HTTP. Methods आणि status codes समान असतात. फरक एवढाच की client आणि TLS termination करणाऱ्या घटकामधील bytes encrypted असतात आणि default port 80 वरून 443 होतो. पहिला HTTP byte पाठवण्यापूर्वी TLS handshake पूर्ण होते. त्यामुळे certificate failure मुळे status code तयार होत नाही. म्हणून browser certificate warning मध्ये 403 सारखा अंक न दाखवता NET::ERR_CERT_COMMON_NAME_INVALID सारखे error name दिसते.

माझी site 502 Bad Gateway का दाखवते?

nginx कडून मिळणारा 502 याचा अर्थ nginx ज्या upstream कडे proxy करते, त्याच्याकडून usable response मिळाला नाही. त्यामुळे visitor ची request योग्य होती, परंतु nginx च्या मागील बाजूस काहीतरी अयशस्वी झाले. /var/log/nginx/error.log वाचा. connect() failed (111: Connection refused) while connecting to upstream याचा अर्थ proxy_pass मधील address आणि port वर काहीही listening करत नाही. त्यामुळे application सुरू आहे आणि अपेक्षित ठिकाणी bind झाली आहे का ते तपासा. no live upstreams while connecting to upstream याचा अर्थ repeated failures नंतर upstream block मधील प्रत्येक server down म्हणून चिन्हांकित झाला आहे. याची तुलना 504 Gateway Timeout शी करा. याचा अर्थ upstream ने connection स्वीकारले, परंतु proxy_read_timeout मध्ये दिलेल्या वेळेत response देण्यात अयशस्वी झाले.

प्रत्येक visitor साठी माझ्या access log मध्ये समान IP address का दिसतो?

कारण $remote_addr TCP connection उघडणाऱ्या घटकाचा address नोंदवते. reverse proxy किंवा content delivery network च्या मागे हा address proxy चा असतो. Visitor चा address त्याऐवजी X-Forwarded-For header मध्ये येतो. Proxy वर proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; सेट करा. त्यानंतर receiving nginx वर set_real_ip_from मध्ये proxy ची address range सेट करा आणि real_ip_header X-Forwarded-For;. तुम्ही नियंत्रित करत असलेल्या rangesच सूचीबद्ध करा. हा header कोणताही client पाठवू शकतो. त्यामुळे संपूर्ण internet कडून त्यावर विश्वास ठेवल्यास visitor log आणि rate limit साठी वापरला जाणारा address स्वतः निवडू शकतो.

मला HTTP/2 किंवा HTTP/3 सुरू करणे आवश्यक आहे का?

HTTP/2 सुरू करणे उपयुक्त आहे. आधीच TLS असलेल्या site वर त्यासाठी एक directive पुरते आणि अनेक लहान files असलेल्या page ला धीमे करणारी प्रत्येक connection वरील request limit दूर होते. HTTP/3 चा फायदा कमी आणि कमी निश्चित आहे. त्यासाठी open UDP port 443 तसेच QUIC support असलेली proxy build आवश्यक असते. Browsers आधीच्या response मध्ये Alt-Svc header दिसल्यानंतरच HTTP/3 कडे switch करतात, हे लक्षात ठेवा. त्यामुळे तुमच्या listen line मध्ये काहीही असले तरी त्या header शिवाय काहीही बदलत नाही. तुमचे visitors प्रत्यक्षात कोणता protocol negotiate करतात हे मोजण्यापूर्वी log format मध्ये $server_protocol जोडा.

File अस्तित्वात असताना 403 Forbidden चा अर्थ काय असतो?

Static site वर 403 म्हणजे सामान्यतः HTTP rule नसून filesystem permission ची समस्या असते. /var/log/nginx/error.log मधील open() ... failed (13: Permission denied) याचा अर्थ nginx worker user file वाचू शकत नाही. बहुतेक वेळा file mode चुकीचा असल्यामुळे नव्हे, तर parent directory मध्ये others साठी execute permission नसल्यामुळे असे होते. directory index of ... is forbidden याचा अर्थ request अशा directory कडे resolve झाली जिथे index file नाही आणि autoindex बंद आहे. Matching location block मधील explicit deny rule देखील 403 परतवते. त्यामुळे error log मध्ये काहीही दिसत नसताना तो block वाचा.

#http #https#web-server#headers#http3