SSD Nodes Learn 🎉 VPS $4.99/माह से
गाइड Matt Connorलेखक: Matt Connor · अपडेट किया गया: 2026-08-07

HTTP क्या है: सर्वर एडमिन के लिए पूरी जानकारी

HTTP प्रोटोकॉल के काम करने का तरीका, status codes, headers और nginx logs के बारे में जानें। इस गाइड में HTTP/3 और TLS के महत्व को विस्तार से समझाया गया है।

HTTP क्या है?

HTTP (hypertext transfer protocol) उन नियमों का समूह है जिनका उपयोग क्लाइंट और वेब सर्वर किसी चीज़ का अनुरोध करने और उसे वापस भेजने के लिए करते हैं। क्लाइंट एक अनुरोध भेजता है: एक method जैसे कि GET, एक path जैसे कि /pricing, एक protocol version, headers की एक सूची, और कभी-कभी एक body। सर्वर 200 जैसे status code के साथ उत्तर देता है, जिसके बाद उसके अपने headers और आमतौर पर एक body होती है। आपके सर्वर पर हर page view और हर API (application programming interface) कॉल इसी एक एक्सचेंज का दोहराव है।

HTTP अपनी कोई state नहीं रखता है। सर्वर को याद नहीं रहता कि आपने एक सेकंड पहले क्या पूछा था, इसलिए जो कुछ भी मेमोरी की तरह व्यवहार करता है, उदाहरण के लिए login session, वह हर एक अनुरोध पर एक header में ले जाया जाता है। यह एक गुण आगे दी गई अधिकांश बातों की व्याख्या करता है: caching पूरी तरह से header पर आधारित है, और एक load balancer आपके अगले अनुरोध को बिना कुछ तोड़े किसी अलग backend पर भेज सकता है।

नीचे दी गई हर चीज़ सर्वर साइड से उस मॉडल का स्वरूप है, जो आपके access log और nginx config में दिखाई देता है।

एक raw request और response, एनोटेट किया गया

यहाँ एक पूर्ण HTTP/1.1 request दी गई है। एक खाली लाइन 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 body के बिना GET के headers मांगता है।
  • /pricing वह path है। Hostname request line का हिस्सा नहीं होता है, इसीलिए अगला header मौजूद होता है।
  • HTTP/1.1 वह protocol version है जिस पर client बात कर रहा है।
  • Host: example.com उस site का नाम बताता है जिसे client चाहता है। HTTP/1.1 के लिए यह आवश्यक है, इसलिए nginx बिना इसके आने वाले request का उत्तर 400 Bad Request के साथ देता है।
  • बाकी प्राथमिकताएं हैं। 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 status code है और उसके साथ उसका reason phrase है। Code ही मायने रखता है। Phrase केवल सजावट है और clients इसे अनदेखा कर देते हैं।
  • Content-Type client को बताता है कि आने वाले bytes के साथ क्या करना है।
  • Content-Length bytes में body का आकार है, ताकि client को पता चल सके कि body कहाँ समाप्त होती है। जब आकार पहले से ज्ञात न हो, तो server इसके बजाय Transfer-Encoding: chunked भेजता है और शून्य लंबाई वाले chunk के साथ अंत को चिह्नित करता है।
  • Cache-Control browser और बीच में मौजूद किसी भी cache को बताता है कि वे इस response को कितने समय तक रख सकते हैं।
  • Headers के बाद की खाली लाइन उन्हें body से अलग करती है, दोनों दिशाओं में।

Header के नाम case insensitive होते हैं, और हर लाइन एक carriage return और उसके बाद line feed के साथ समाप्त होती है, न कि केवल एक newline के साथ। आप इन्हें हाथ से टाइप नहीं करेंगे, लेकिन packet capture में आप इनका सामना करेंगे।

एक वास्तविक pair को monitor करने के लिए, अपनी किसी site पर इसे चलाएं:

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

-D - response headers को आपके terminal पर लिखता है और -o /dev/null body को discard कर देता है। curl -I के बजाय इसे प्राथमिकता दें, क्योंकि -I एक HEAD request भेजता है। एक application server जो HEAD को GET से अलग तरह से handle करता है (और कई ऐसा करते हैं), वह आपको ऐसे headers दिखाएगा जो कोई browser कभी प्राप्त नहीं करता। curl -v दोनों पक्षों को print करता है, जिसमें 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 खोला। Proxy के पीछे होने पर यह proxy का पता होता है, न कि visitor का।
  • पहला - एक निश्चित placeholder है। दूसरा $remote_user है, जो केवल तभी भरा जाता है जब HTTP basic authentication का उपयोग हो रहा हो।
  • "GET /pricing HTTP/1.1" का अर्थ $request है, request line को ठीक वैसे ही कॉपी किया गया है जैसे वह प्राप्त हुई थी।
  • 200 वह status है जो आपके सर्वर ने return किया, न कि वह status जो visitor ने देखा।
  • 5310 का अर्थ $body_bytes_sent है, केवल body का आकार। Response headers की गणना नहीं की जाती है, इसलिए यह संख्या वास्तव में भेजे गए bytes से हमेशा छोटी होती है।
  • अंतिम दो quoted fields Referer और User-Agent हैं। दोनों client से आते हैं, इसलिए दोनों में कुछ भी हो सकता है।

चूंकि $request को ज्यों का त्यों कॉपी किया जाता है, इसलिए कचरा (junk) भी ज्यों का त्यों दिखाई देता है। जो client आपके plaintext port 80 पर TLS (transport layer security) के माध्यम से बात करता है, वह एक 400 पंक्ति छोड़ता है जिसका request field "\x16\x03\x01\x02\x00\x01" जैसे escaped bytes से शुरू होता है। \x16 TLS handshake record का प्रकार है, इसलिए वे bytes एक ClientHello की शुरुआत हैं, न कि कोई request line। आपका सर्वर सही ढंग से व्यवहार कर रहा है। कोई चीज़ HTTPS को HTTP port की ओर point कर रही है।

अपने log format में $server_protocol को भी जोड़ें। यह HTTP/1.1, HTTP/2.0 या HTTP/3.0 को print करता है, और यह साबित करने का सबसे तेज़ तरीका है कि protocol परिवर्तन वास्तव में प्रभावी हो गया है।

जब आपकी अपनी साइट status codes लौटाती है, तो उनका क्या अर्थ होता है

पहला अंक class को दर्शाता है, और आपको सबसे पहले class को ही देखना चाहिए।

2xx का अर्थ है कि यह सफल रहा। सामान्य read के लिए 200 OK का उपयोग होता है। किसी चीज़ को create करने वाले POST के बाद 201 Created मिलता है। बिना किसी response body के सफलता के लिए 204 No Content का उपयोग होता है, जो आमतौर पर DELETE का उत्तर होता है।

3xx का अर्थ है कि कहीं और देखें। 301 स्थायी होता है और browsers इसे मजबूती से cache करते हैं, कभी-कभी तब तक जब तक user अपनी profile clear न कर दे, इसलिए गलत hostname पर point करने वाले 301 को ठीक करना मुश्किल होता है। जब आप redirect की testing कर रहे हों, तब 302 का उपयोग करें। 304 Not Modified एक सफलता है, त्रुटि नहीं: client ने If-None-Match भेजा जिसमें एक ऐसा ETag (entity tag) था जिसे आप अभी भी पहचानते हैं, इसलिए आपने केवल headers लौटाए और body नहीं भेजी। यदि logs में बहुत सारे 304 दिख रहे हैं, तो इसका मतलब है कि caching सही ढंग से काम कर रही है।

4xx का अर्थ है कि request गलत थी। 400 Bad Request का अर्थ है गलत format में input। 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 से बड़ा है, जो डिफ़ॉल्ट रूप से 1 megabyte होता है, और error log में इसकी पुष्टि client intended to send too large body के साथ होती है।

static file पर 403 लगभग हमेशा HTTP rule के बजाय filesystem की समस्या होती है। कोई भी config बदलने से पहले /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 पर ले गया जहाँ कोई 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 पर कोई service listening नहीं है। 504 Gateway Timeout का अर्थ है कि upstream ने connection स्वीकार किया लेकिन proxy_read_timeout (डिफ़ॉल्ट रूप से 60 seconds) के भीतर कोई जवाब नहीं दिया, जिसे log में upstream timed out (110: Connection timed out) while reading response header from upstream के रूप में दर्ज किया जाता है। 503 Service Unavailable एक जानबूझकर किया गया इनकार है। ध्यान दें कि nginx का अपना rate limiter 503 लौटाता है, क्योंकि limit_req_status डिफ़ॉल्ट रूप से 503 होता है। यदि आप अपने log में 429 Too Many Requests ढूंढ रहे हैं और उसके बजाय 503 मिल रहा है, तो इसका कारण यही है। सटीक code प्राप्त करने के लिए limit_req_status 429; सेट करें।

सर्वर चलाते समय महत्वपूर्ण हेडर

Host साइट का चयन करता है। एक IP address सैकड़ों hostnames को सर्व कर सकता है, और nginx यह तय करने के लिए कि कौन सा server block जवाब देगा, Host की तुलना server_name से करता है। यदि कुछ भी मैच नहीं होता है, तो nginx default server का उपयोग करता है, जो उस address और port पर सुनने वाला पहला block होता है, जब तक कि किसी अन्य को default_server के रूप में चिह्नित न किया गया हो। एक नए virtual host से गलत साइट मिलना लगभग हमेशा इसी कारण होता है: नाम मैच नहीं हुआ, इसलिए request default पर चली गई। DNS को छुए बिना इसका परीक्षण करें:

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

User-Agent क्लाइंट द्वारा लिखा गया एक स्व-विवरण है, और यह free text है। logs पढ़ते समय इसे एक संकेत के रूप में उपयोग करें। इसे कभी भी नियंत्रण के रूप में उपयोग न करें, क्योंकि जो क्लाइंट इसके बारे में झूठ बोलना चाहता है वह आसानी से ऐसा कर सकता है, इसलिए User-Agent द्वारा scraper को ब्लॉक करने से केवल विनम्र scraper ही फिल्टर होते हैं।

Content-Type यह तय करता है कि bytes की व्याख्या कैसे की जाए: API request के लिए application/json, और पेज के लिए text/html; charset=utf-8। nginx फाइल एक्सटेंशन को /etc/nginx/mime.types के साथ types में मैप करता है, और पैकेज्ड nginx.conf, default_type application/octet-stream; को सेट करता है, इसलिए जिस फाइल का एक्सटेंशन nginx नहीं जानता, उसे रेंडर करने के बजाय डाउनलोड के रूप में पेश किया जाता है। इसका स्पष्ट लक्षण एक ऐसा पेज है जो बिना स्टाइलिंग के लोड होता है जबकि 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 आती हैं।

Cache-Control वह तरीका है जिससे आप अपने सर्वर और पाठक के बीच हर cache को नियंत्रित करते हैं। public, max-age=31536000, immutable उन assets के लिए उपयुक्त है जिनके filename में content hash होता है, क्योंकि सामग्री बदलने पर नाम भी बदल जाता है। no-store किसी भी user-specific चीज़ के लिए होता है, क्योंकि एक shared cache जो logged-in पेज को रखता है, वह उसे अगले व्यक्ति को दे देगा जो उसी URL के लिए अनुरोध करेगा। private बीच की सेटिंग है: ब्राउज़र इसे रख सकता है, लेकिन shared cache ऐसा नहीं कर सकता।

X-Forwarded-For इसलिए मौजूद है क्योंकि proxy आगंतुक को छिपा देता है। एक बार जब कोई request reverse proxy से गुजरती है, तो $remote_addr proxy का address होता है, इसलिए आपके logs, आपकी geolocation और आपकी rate limiting सभी को केवल एक ही क्लाइंट दिखाई देता है। proxy को मूल address को आगे बढ़ाना होता है:

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

प्राप्त करने वाले सर्वर को तब यह बताने की आवश्यकता होती है कि किस पर विश्वास करना है, और यह भी कि वास्तव में किस पर विश्वास करना है:

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

केवल उन ranges को सूचीबद्ध करें जिन्हें आप नियंत्रित करते हैं। set_real_ip_from 0.0.0.0/0; एक plain text है जिसे कोई भी क्लाइंट भेज सकता है, इसलिए X-Forwarded-For एक आगंतुक को वह address चुनने देता है जिसे आप log करते हैं और जिसे आपका rate limiter गिनता है।

X-Forwarded-Proto एक विशिष्ट और बहुत सामान्य विफलता को रोकता है। आपका proxy TLS को समाप्त करता है और request को plain HTTP पर application को भेजता है। application एक plain request देखता है, तय करता है कि आगंतुक को HTTPS पर होना चाहिए, और 301 https://example.com/ का जवाब देता है। ब्राउज़र इसका पालन करता है, proxy फिर से TLS को समाप्त करता है और फिर से plain HTTP भेजता है, और यह लूप तब तक दोहराता है जब तक ब्राउज़र ERR_TOO_MANY_REDIRECTS के साथ हार नहीं मान लेता। X-Forwarded-Proto: https भेजने से application को पता चलता है कि आगंतुक पहले से ही HTTPS पर है, इसलिए यह redirect करना बंद कर देता है।

HTTP/1.1 बनाम HTTP/2 बनाम HTTP/3: आपके लिए क्या बदलता है

HTTP/1.1 टेक्स्ट-आधारित है और यह प्रति कनेक्शन एक बार में एक ही अनुरोध (request) को संभालता है। Connection: keep-alive अगले अनुरोध को उसी TCP कनेक्शन का पुन: उपयोग करने की अनुमति देता है, जिससे सेटअप लागत बचती है, लेकिन प्रतिक्रियाएं (responses) उसी क्रम में वापस आती हैं जिस क्रम में उनका अनुरोध किया गया था। एक धीमी प्रतिक्रिया उसके पीछे कतारबद्ध हर चीज को रोक देती है। इसे head-of-line blocking कहते हैं, और ब्राउज़र एक ही होस्टनेम पर एक साथ कई कनेक्शन खोलकर इससे बचते हैं।

HTTP/2 उन्हीं मेथड्स और स्टेटस कोड्स का उपयोग करता है, लेकिन यह फ्रेमिंग को बाइनरी में बदल देता है। कई अनुरोध एक ही कनेक्शन को स्वतंत्र स्ट्रीम के रूप में साझा करते हैं, और बार-बार आने वाले हेडर टेक्स्ट को कंप्रेस किया जाता है, जो महत्वपूर्ण है क्योंकि आधुनिक अनुरोधों में बहुत अधिक हेडर डेटा होता है। कनेक्शन अभी भी TCP है, इसलिए एक खोया हुआ पैकेट उस कनेक्शन की हर स्ट्रीम को तब तक रोक देता है जब तक कि रिट्रांसमिशन न आ जाए। Head-of-line blocking समाप्त नहीं हुई। यह HTTP से नीचे ट्रांसपोर्ट लेयर पर चली गई। Server push HTTP/2 का हिस्सा था और व्यवहार में अब यह समाप्त हो चुका है, क्योंकि Chrome ने 2022 में इसके लिए समर्थन हटा दिया था।

HTTP/3 फिर से उन्हीं सिमेंटिक्स को बनाए रखता है और TCP को QUIC से बदल देता है, जो UDP (user datagram protocol) पर बना एक ट्रांसपोर्ट है। QUIC स्ट्रीम पूरी तरह से स्वतंत्र होती हैं, इसलिए एक खोया हुआ पैकेट केवल उसी स्ट्रीम को रोकता है जिससे वह संबंधित था। TLS 1.3 को QUIC हैंडशेक में ही शामिल किया गया है, न कि ऊपर से लेयर किया गया है, इसलिए एक नए कनेक्शन के लिए कम राउंड ट्रिप की आवश्यकता होती है। इसके दो व्यावहारिक परिणाम होते हैं: रास्ते में आने वाले हर फायरवॉल पर UDP port 443 खुला होना चाहिए, और कोई भी नेटवर्क जो UDP को थ्रॉटल या ब्लॉक करता है, वह क्लाइंट्स को वापस HTTP/2 पर धकेल देगा।

आपके लिए ठोस रूप से क्या बदलता है। ब्राउज़र कभी भी सीधे HTTP/3 से शुरू नहीं होते। वे HTTP/2 या HTTP/1.1 पर कनेक्ट होते हैं, प्रतिक्रिया पर Alt-Svc: h3=":443"; ma=86400 हेडर देखते हैं, और उस होस्ट के बाद के कनेक्शन के लिए HTTP/3 का उपयोग करते हैं। इसलिए यह हेडर केवल सजावट नहीं है। यह डिस्कवरी मैकेनिज्म है। nginx में, HTTP/2 वर्जन 1.25.1 में अपना एक अलग डायरेक्टिव बन गया (server ब्लॉक के अंदर http2 on;, जो पुराने listen ... http2 पैरामीटर की जगह लेता है), और QUIC मेनलाइन 1.25.0 में आया, जहाँ एक HTTP/3 साइट को सामान्य listen 443 ssl; के साथ listen 443 quic reuseport; की आवश्यकता होती है।

प्रॉक्सी की परिपक्वता (maturity) अलग-अलग होती है, और इसे उस वर्जन के साथ जांचना उचित है जिसे आप वास्तव में चला रहे हैं। अगस्त 2026 तक, Caddy बिना किसी कॉन्फ़िगरेशन के डिफ़ॉल्ट रूप से HTTP/3 सर्व करता है। nginx को ऊपर वर्णित Alt-Svc हेडर के साथ स्पष्ट quic लिसनर की आवश्यकता होती है। Traefik इसे एक स्पष्ट http3 विकल्प के माध्यम से प्रति एंट्री पॉइंट सक्षम करता है। यदि आप कई Docker ऐप्स के सामने Traefik पर TLS टर्मिनेट करते हैं, तो आपके विज़िटर को मिलने वाला प्रोटोकॉल वर्जन वहीं तय होता है, और प्रॉक्सी से आपके कंटेनर तक का हॉप आमतौर पर सादा HTTP/1.1 ही रहता है, चाहे ब्राउज़र ने कुछ भी नेगोशिएट किया हो।

अनुमान लगाने के बजाय सत्यापित करें। curl --http3 -sS -o /dev/null -D - https://example.com/ केवल तभी काम करता है जब curl -V अपनी सुविधाओं में HTTP3 को सूचीबद्ध करता है, और अधिकांश डिस्ट्रीब्यूशन बिल्ड में यह शामिल नहीं होता है। भरोसेमंद जांच आपका अपना लॉग है: फॉर्मेट में $server_protocol जोड़ें और पढ़ें कि वास्तविक ब्राउज़र क्या नेगोशिएट कर रहे हैं। इससे पहले, पुष्टि करें कि UDP 443 वास्तव में खुला है, क्योंकि जो फायरवॉल केवल TCP 443 की अनुमति देता है, वह HTTP/3 को चुपचाप विफल होने देगा जबकि साइट HTTP/2 पर काम करती रहेगी। आपके Linux सर्वर पर कौन से पोर्ट खुले और लिसनिंग मोड में हैं, यह जानना सबसे पहली जांच है।

HTTPS: HTTP एक प्रोटोकॉल है, TLS उसका आवरण है

HTTPS कोई अलग प्रोटोकॉल नहीं है। यह वही HTTP रिक्वेस्ट और स्टेटस कोड हैं जो एक TLS सेशन के भीतर भेजे जाते हैं। Port 80 पर ये बिना किसी एन्क्रिप्शन के भेजे जाते हैं और port 443 पर एन्क्रिप्टेड रूप में। TLS हैंडशेक पहले पूरा होता है, उसके बाद ही HTTP रिक्वेस्ट एन्क्रिप्टेड चैनल के अंदर जाती है। इसी क्रम के कारण सर्टिफिकेट संबंधी समस्या का कोई स्टेटस कोड नहीं होता: विफलता एक भी HTTP बाइट भेजे जाने से पहले ही हो जाती है, इसलिए कोई रिस्पॉन्स कोड नहीं होता।

एक सर्वर पर कई साइट्स होस्ट करते समय क्रम का एक विवरण महत्वपूर्ण है। सर्टिफिकेट का चयन SNI (server name indication) का उपयोग करके किया जाता है, जो TLS हैंडशेक का एक फील्ड है। यह किसी भी HTTP हेडर के मौजूद होने से पहले होस्टनेम को स्पष्ट रूप से ले जाता है। इसलिए सर्वर पहले SNI से सर्टिफिकेट चुनता है, और फिर दूसरे चरण में Host हेडर से वर्चुअल होस्ट चुनता है। ये दो अलग-अलग लुकअप हैं जो सामान्यतः एक-दूसरे से मेल खाते हैं। जब वे मेल नहीं खाते, तो ब्राउज़र NET::ERR_CERT_COMMON_NAME_INVALID जैसा नेम मिसमैच दिखाता है और कोई रिक्वेस्ट नहीं भेजता, क्योंकि आपके डिफ़ॉल्ट सर्वर का सर्टिफिकेट ऐसे नाम के लिए पेश किया गया था जिसे वह कवर नहीं करता।

एक पब्लिक साइट के लिए, एक वास्तविक सर्टिफिकेट प्राप्त करें और उसे अपने आप रिन्यू होने दें। Certbot with Let's Encrypt on nginx सर्टिफिकेट पाथ को आपके सर्वर ब्लॉक में लिख देता है और आपके लिए रिन्यूअल टाइमर इंस्टॉल कर देता है। ऐसे होस्टनेम के लिए जिसे कोई पब्लिक अथॉरिटी वैलिडेट नहीं कर सकती, जैसे कि कोई इंटरनल नाम या आपके अपने नेटवर्क पर कोई bare IP एड्रेस, a self-signed certificate on Ubuntu एक ईमानदार विकल्प है, बशर्ते आप यह स्वीकार करें कि हर क्लाइंट को उस पर भरोसा करने के लिए कहना होगा।

एक बार TLS काम करने लगे, तो port 80 के सभी ट्रैफिक को 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; हेडर ब्राउज़रों को उस होस्टनेम के लिए दो साल तक plain HTTP को अस्वीकार करने के लिए कहता है, और वे इसे अपने कैश से मानते हैं। इसका मतलब है कि बाद में हेडर को हटाने से यह सेटिंग वापस नहीं बदलती। शुरुआत में max-age को कुछ घंटों के लिए रखें, पुष्टि करें कि हर सबडोमेन वास्तव में HTTPS पर है, और फिर इसे बढ़ाएं।

FAQ

HTTP और HTTPS में क्या अंतर है?

HTTPS, TLS (transport layer security) session के भीतर भेजा गया HTTP है। इसके methods और status codes समान होते हैं। अंतर यह है कि client और TLS terminate करने वाले के बीच bytes encrypted होते हैं, और default port 80 से बदलकर 443 हो जाता है। चूंकि TLS handshake पहला HTTP byte भेजे जाने से पहले पूरा हो जाता है, इसलिए certificate failure कभी भी status code उत्पन्न नहीं करता है। यही कारण है कि browser certificate warning में 403 जैसी संख्या के बजाय NET::ERR_CERT_COMMON_NAME_INVALID जैसा error नाम दिखाई देता है।

मेरी साइट 502 Bad Gateway क्यों दिखा रही है?

nginx से 502 का मतलब है कि nginx उस upstream से उपयोगी response प्राप्त नहीं कर सका जिसे वह proxy करता है, इसलिए visitor का request सही था लेकिन nginx के पीछे कुछ गड़बड़ है। /var/log/nginx/error.log पढ़ें। connect() failed (111: Connection refused) while connecting to upstream का मतलब है कि proxy_pass में दिए गए address और port पर कोई service listening नहीं है, इसलिए जाँचें कि application चल रही है और अपेक्षित स्थान पर bound है। no live upstreams while connecting to upstream का मतलब है कि बार-बार विफलताओं के बाद upstream block के प्रत्येक server को down चिह्नित कर दिया गया है। इसकी तुलना 504 Gateway Timeout से करें, जिसका अर्थ है कि upstream ने connection स्वीकार तो किया लेकिन proxy_read_timeout के भीतर उत्तर देने में विफल रहा।

मेरे access log में हर visitor के लिए एक ही IP address क्यों दिखाई देता है?

क्योंकि $remote_addr उस address को record करता है जिसने TCP connection खोला है, और 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 ऐसा text है जिसे कोई भी client भेज सकता है। इसलिए पूरे internet से उस पर भरोसा करने का मतलब है कि एक visitor वह address चुन सकता है जिसे आप log करते हैं और जिसे आप rate limit करते हैं।

क्या मुझे HTTP/2 या HTTP/3 चालू करने की आवश्यकता है?

HTTP/2 चालू करना फायदेमंद है, क्योंकि यह उस साइट पर केवल एक directive है जिसमें पहले से ही TLS है। यह प्रति connection request की सीमा को हटा देता है, जो कई छोटी फाइलों वाले पेज को धीमा बनाती है। HTTP/3 का लाभ कम और अनिश्चित है, और इसके लिए आपको UDP port 443 खुला रखना होगा और QUIC support के साथ proxy build करना होगा। याद रखें कि browsers केवल तभी HTTP/3 पर स्विच करते हैं जब वे पहले के response पर Alt-Svc header देखते हैं। इसलिए उस header के बिना, आपकी listen line कुछ भी कहे, कोई बदलाव नहीं होगा। अपने log format में $server_protocol जोड़ें और उस पर समय खर्च करने से पहले मापें कि visitors वास्तव में क्या negotiate कर रहे हैं।

फाइल मौजूद होने पर भी 403 Forbidden का क्या अर्थ है?

static site पर 403 आमतौर पर HTTP rule के बजाय filesystem permission की समस्या होती है। /var/log/nginx/error.log में open() ... failed (13: Permission denied) का मतलब है कि nginx worker user फाइल को पढ़ नहीं सकता है। ऐसा अक्सर इसलिए होता है क्योंकि parent directory में others के लिए execute permission नहीं होती है, न कि इसलिए कि फाइल mode गलत है। directory index of ... is forbidden का मतलब है कि request एक ऐसी directory पर गया जिसमें कोई index फाइल नहीं है जबकि autoindex बंद है। matching location block में एक स्पष्ट deny rule भी 403 लौटाता है, इसलिए जब error log में कुछ न दिखे तो उस block को पढ़ें।

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