ద్వారా Matt Connor 2026-08-06 · అప్‌డేట్ చేయబడింది 2026-08-13

HTTP అంటే ఏమిటి? Server admin కోసం పూర్తి గైడ్

Q: HTTP మరియు HTTPS మధ్య తేడా ఏమిటి?

HTTPS అనేది TLS (transport layer security) session లో పంపబడే HTTP. Methods మరియు status codes ఒకేలా ఉంటాయి. మారేది ఏమిటంటే, client మరియు TLS ను terminate చేసే భాగం మధ్య bytes encrypt అవుతాయి. 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 proxy చేస్తున్న upstream నుంచి ఉపయోగించగల response ను పొందలేకపోయిందని అర్థం. Visitor పంపిన request సరిగానే ఉంది, కానీ nginx వెనుక ఉన్న భాగంలో సమస్య ఉంది. /var/log/nginx/error.log ను చదవండి. connect() failed (111: Connection refused) while connecting to upstream అంటే proxy_pass లోని address మరియు port వద్ద ఏదీ listening లో లేదని అర్థం. కాబట్టి application నడుస్తోందో, మీరు ఆశించిన address మరియు port కు bind అయిందో తనిఖీ చేయండి. no live upstreams while connecting to upstream అంటే repeated failures తర్వాత upstream block లోని ప్రతి server ను down గా గుర్తించారని అర్థం. దీనిని 504 Gateway Timeout తో పోల్చండి. 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; ను set చేయండి. తరువాత receiving nginx పై set_real_ip_from ను proxy address range కు set చేసి, real_ip_header X-Forwarded-For; ను configure చేయండి. మీరు నియంత్రించే ranges ను మాత్రమే జాబితా చేయండి. ఎందుకంటే ఆ header ను ఏ client అయినా పంపగల text మాత్రమే. మొత్తం internet నుంచి వచ్చిన విలువను నమ్మితే, visitor log లో నమోదు చేసే address ను మరియు rate limit వర్తించే address ను ఎంచుకోగలడు.

Q: HTTP/2 లేదా HTTP/3 ను enable చేయాలా?

ఇప్పటికే TLS ఉన్న site లో HTTP/2 ను enable చేయడం ఉపయోగకరం. దీనికి ఒక directive చాలు. అలాగే అనేక చిన్న files ఉన్న page ను నెమ్మదించే ప్రతి-connection request limit తొలగుతుంది. HTTP/3 ద్వారా లభించే ప్రయోజనం తక్కువగా ఉండవచ్చు, అది ఖచ్చితంగా ఉండదు. దీనికి open UDP port 443 మరియు QUIC support కలిగిన proxy build అవసరం. Browsers ముందుగా వచ్చిన response లో Alt-Svc header ను చూసిన తర్వాత మాత్రమే HTTP/3 కు మారతాయని గుర్తుంచుకోండి. కాబట్టి ఆ header లేకపోతే, మీ listen line ఏమి చెబుతున్నా ఎలాంటి మార్పూ జరగదు. 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 ను read చేయలేకపోతున్నాడని అర్థం. చాలాసార్లు సమస్య file mode లో ఉండదు; parent directory పై others కు execute permission లేకపోవడమే కారణం. directory index of ... is forbidden అంటే request index file లేని directory కి resolve అయిందని అర్థం. ఈ సందర్భంలో autoindex off లో ఉంది. Matching location block లోని explicit deny rule కూడా 403 ను return చేస్తుంది. కాబట్టి error log లో ఏమీ కనిపించకపోతే ఆ block ను చదవండి.

HTTPలో methods, status codes, ముఖ్యమైన headers, nginx logs ఏమి చూపిస్తాయో తెలుసుకోండి. HTTP/3 మరియు TLS ఎక్కడ సరిపోతాయో కూడా సులభంగా అర్థం చేసుకోండి.

HTTP అంటే ఏమిటి?

HTTP (hypertext transfer protocol) అనేది క్లయింట్ మరియు web server ఏదైనా వనరును అభ్యర్థించి, దాని ప్రతిస్పందనను తిరిగి పంపేందుకు ఉపయోగించే నియమాల సమాహారం. క్లయింట్ ఒక request పంపుతుంది. అందులో GET వంటి method, /pricing వంటి path, protocol version, headers జాబితా, కొన్నిసార్లు body ఉంటాయి. Server 200 వంటి status code తో ప్రతిస్పందిస్తుంది. దాని తరువాత server headers మరియు సాధారణంగా body పంపుతుంది. మీ server లో కనిపించే ప్రతి page view మరియు ప్రతి API (application programming interface) call ఇదే exchange పునరావృతం కావడం.

HTTP తనంతట తాను state ను నిల్వ చేయదు. ఒక సెకను ముందు మీరు ఏది అభ్యర్థించారో server గుర్తుంచుకోదు. అందువల్ల login session వంటి memory లాగా పనిచేసే సమాచారం ప్రతి request లోని header ద్వారా పంపాలి. తరువాతి విషయాలలో ఎక్కువ భాగాన్ని ఈ లక్షణమే వివరిస్తుంది. Caching పూర్తిగా headers ఆధారంగా పనిచేస్తుంది. అలాగే load balancer మీ తరువాతి request ను వేరే backend కు పంపినా ఎలాంటి సమస్య ఉండదు.

క్రిందివన్నీ server వైపు ఈ మోడల్ ఎలా కనిపిస్తుందో వివరిస్తాయి. అవి మీ access log మరియు nginx config లో కనిపిస్తాయి.

ముడి 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 ఒక GET యొక్క headers ను మాత్రమే అడుగుతుంది; body ను అడగదు.
/pricing అనేది path. Hostname request line లో భాగం కాదు. అందుకే తదుపరి header అవసరం.
HTTP/1.1 అనేది client ఉపయోగిస్తున్న protocol version.
Host: example.com client కోరుతున్న site ను సూచిస్తుంది. HTTP/1.1 లో ఇది తప్పనిసరి. అందువల్ల ఇది లేకుండా వచ్చిన request కు nginx 400 Bad Request తో సమాధానం ఇస్తుంది.
మిగతావి preferences. Client decompress చేయగలదని Accept-Encoding: gzip సూచిస్తుంది. కాబట్టి 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 దాన్ని పట్టించుకోవు.
తర్వాత వచ్చే bytes ను ఎలా పరిగణించాలో Content-Type client కు చెబుతుంది.
Content-Length అనేది bytes లో body పరిమాణం. అందువల్ల body ఎక్కడ ముగుస్తుందో client కు తెలుస్తుంది. పరిమాణం ముందుగానే తెలియనప్పుడు server బదులుగా Transfer-Encoding: chunked ను పంపుతుంది. ముగింపును zero length chunk తో సూచిస్తుంది.
ఈ response ను browser మరియు మధ్యలోని cache ఎంతకాలం నిల్వ ఉంచవచ్చో Cache-Control సూచిస్తుంది.
రెండు దిశల్లోనూ headers తర్వాతి ఖాళీ లైన్, headers ను body నుంచి వేరు చేస్తుంది.

Header పేర్లలో పెద్ద, చిన్న అక్షరాల తేడా ఉండదు. ప్రతి line bare newline తో కాకుండా carriage return తరువాత line feed తో ముగుస్తుంది. వీటిని మీరు చేతితో టైప్ చేయరు. కానీ packet capture లో ఇవి కనిపిస్తాయి.

నిజమైన request మరియు response జతను చూడటానికి, మీ స్వంత site పై ఈ command అమలు చేయండి:

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 — మరియు చాలావరకు అలా చేస్తాయి — ఏ 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 ను ప్రారంభించిన చిరునామా. Proxy వెనుక ఉంటే ఇది visitor చిరునామా కాదు, proxy చిరునామా.
మొదటి - ఒక స్థిర placeholder. రెండవది $remote_user. HTTP basic authentication ఉపయోగించినప్పుడు మాత్రమే ఇందులో విలువ ఉంటుంది.
"GET /pricing HTTP/1.1" అనేది $request. ఇది వచ్చిన విధంగానే request line ను ఖచ్చితంగా కాపీ చేస్తుంది.
200 అనేది మీ server తిరిగి పంపిన status. Visitor చూసిన status కాదు.
5310 అనేది $body_bytes_sent. ఇందులో body మాత్రమే ఉంటుంది. Response headers లెక్కలోకి రావు. అందువల్ల పంపిన మొత్తం bytes కంటే ఈ సంఖ్య ఎల్లప్పుడూ తక్కువగా ఉంటుంది.
చివరి రెండు quotation marks లోని fields Referer మరియు User-Agent. రెండూ client నుంచి వస్తాయి. కాబట్టి రెండింటిలోనూ ఏ విలువైనా ఉండవచ్చు.

$request ను యథాతథంగా కాపీ చేస్తుంది కాబట్టి, అర్థంలేని డేటా కూడా అలాగే కనిపిస్తుంది. Plaintext port 80 కు TLS (transport layer security) ఉపయోగించి మాట్లాడే client, request field లో "\x16\x03\x01\x02\x00\x01" వంటి escaped bytes తో కూడిన 400 పంక్తిని వదిలివేస్తుంది. \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 మార్పు నిజంగా అమల్లోకి వచ్చిందని నిర్ధారించడానికి ఇది వేగవంతమైన మార్గం.

మీ స్వంత site ఈ status codes ను పంపినప్పుడు వాటి సాధారణ అర్థం

మొదటి అంకె ఆ తరగతిని సూచిస్తుంది. ముందుగా చదవాల్సింది కూడా అదే తరగతి.

2xx అంటే అభ్యర్థన విజయవంతమైంది. సాధారణ read కోసం 200 OK. ఏదైనా సృష్టించిన POST తర్వాత 201 Created. తిరిగి పంపడానికి content ఏదీ లేని విజయవంతమైన ఫలితానికి 204 No Content. సాధారణంగా DELETE కు ఇదే సమాధానం.

3xx అంటే మరెక్కడ చూడాలి. 301 శాశ్వత redirect. Browsers దీన్ని గట్టిగా cache చేస్తాయి. కొన్నిసార్లు user తన profile ను clear చేసే వరకు cacheలో ఉంటుంది. అందువల్ల తప్పు hostname కు చూపించే 301 ను సరిచేయడం కష్టమవుతుంది. Redirect ను ఇంకా పరీక్షిస్తున్నప్పుడు 302 ఉపయోగించండి. 304 Not Modified విజయవంతమైన ఫలితం, error కాదు: client మీరు ఇంకా గుర్తిస్తున్న ETag (entity tag) ను కలిగిన If-None-Match పంపింది. అందువల్ల మీరు headers ను మాత్రమే, body లేకుండా, తిరిగి పంపారు. Logs లో 304s ఎక్కువగా కనిపిస్తే caching పనిచేస్తోందని అర్థం.

4xx అంటే request తప్పుగా ఉంది. 400 Bad Request అంటే input సరిగ్గా రూపొందించబడలేదు. 401 Unauthorized అంటే authentication జరగలేదని అర్థం. ఇందులో 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 కనిపిస్తే కారణం దాదాపు ఎల్లప్పుడూ HTTP rule కాకుండా filesystem లో ఉంటుంది. 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 off లో ఉంది.

5xx అంటే మీ వైపు లోపం ఏర్పడింది. 500 అంటే application లో handle చేయని error. 502 Bad Gateway అంటే upstream నుంచి ఉపయోగించగల response ను nginx పొందలేకపోయింది. Error log కారణాన్ని చూపిస్తుంది: connect() failed (111: Connection refused) while connecting to upstream అంటే proxy_pass లోని address పై ఏదీ listening చేయడం లేదని అర్థం. 504 Gateway Timeout అంటే upstream connection ను స్వీకరించిన తర్వాత proxy_read_timeout వ్యవధిలో ఏమీ పంపలేదు. దీని default 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 యొక్క default విలువ 503. మీ log లో 429 Too Many Requests కోసం వెతికినప్పుడు దాని బదులు 503 కనిపిస్తే కారణం ఇదే. ఖచ్చితమైన code కోసం limit_req_status 429; ను సెట్ చేయండి.

సర్వర్‌ను నడిపేటప్పుడు ముఖ్యమైన headers

Host సైట్‌ను ఎంచుకుంటుంది. ఒక IP address వందలాది hostnames కు సేవలు అందించగలదు. ఏ server block సమాధానం ఇవ్వాలో నిర్ణయించడానికి nginx Host ను server_name తో సరిపోల్చుతుంది. ఏదీ సరిపోలకపోతే nginx default server ను ఉపయోగిస్తుంది. మరో block ను default_server గా గుర్తించనంత వరకు, ఆ address మరియు port పై listening చేస్తున్న మొదటి 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 చేస్తే, నియమాలను పాటించే clients మాత్రమే filter అవుతాయి.

Content-Type bytes ను ఎలా అర్థం చేసుకోవాలో నిర్ణయిస్తుంది: API request కోసం application/json, page కోసం text/html; charset=utf-8. nginx file extensions ను types కు /etc/nginx/mime.types ద్వారా map చేస్తుంది. Packaged nginx.conf లో default_type application/octet-stream; అమర్చబడి ఉంటుంది. అందువల్ల nginx కు తెలియని extension ఉన్న file rendered కాకుండా 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 header మీ server మరియు reader మధ్య ఉన్న ప్రతి cache ను ఎలా నియంత్రించాలో నిర్దేశిస్తుంది. Filename లో content hash ఉన్న assets కు public, max-age=31536000, immutable సరిపోతుంది. Content మారినప్పుడు filename కూడా మారుతుంది. User-specific సమాచారం ఉన్న దేనికైనా no-store ఉపయోగించాలి. Logged-in page ను ఉంచుకున్న shared cache, అదే URL కోసం అడిగే తదుపరి వ్యక్తికి ఆ page ను పంపవచ్చు. private మధ్యస్థ setting. Browser దాన్ని ఉంచుకోవచ్చు, కానీ shared cache ఉంచుకోకూడదు.

X-Forwarded-For proxy visitor యొక్క address ను దాచే కారణంగా అవసరం అవుతుంది. Request reverse proxy ద్వారా వెళ్లిన తర్వాత, $remote_addr లో proxy address మాత్రమే ఉంటుంది. అందువల్ల మీ logs, geolocation మరియు rate limiting అన్నీ ఒకే client ను చూస్తాయి. 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;

తర్వాత receiving server ఆ address ను నమ్మాలని, అలాగే ఎవరిని నమ్మాలో ఖచ్చితంగా తెలియజేయాలి:

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

మీ నియంత్రణలో ఉన్న ranges ను మాత్రమే జాబితా చేయండి. X-Forwarded-For అనేది ఏ client అయినా పంపగల plain text. కాబట్టి set_real_ip_from 0.0.0.0/0; ఉపయోగిస్తే visitor మీరు log చేసే address ను, మీ rate limiter లెక్కించే address ను ఎంచుకోగలడు.

X-Forwarded-Proto ఒక నిర్దిష్టమైన, సాధారణమైన వైఫల్యాన్ని నివారిస్తుంది. మీ proxy TLS ను terminate చేసి request ను plain HTTP ద్వారా application కు పంపుతుంది. Application కు plain request కనిపిస్తుంది. Visitor HTTPS ఉపయోగించాలి అని అది నిర్ణయించి 301 https://example.com/ తో సమాధానం ఇస్తుంది. Browser దాన్ని అనుసరిస్తుంది. Proxy మళ్లీ TLS ను terminate చేసి plain HTTP ను మళ్లీ పంపుతుంది. ఈ ప్రక్రియ browser ERR_TOO_MANY_REDIRECTS తో ఆగిపోయే వరకు పునరావృతమవుతుంది. X-Forwarded-Proto: https పంపితే visitor ఇప్పటికే HTTPS పై ఉన్నాడని application కు తెలుస్తుంది. అందువల్ల అది redirect చేయడం ఆపుతుంది.

మీ కోసం HTTP/1.1 vs HTTP/2 vs HTTP/3లో మారేవి

HTTP/1.1 text ఆధారితమైనది. ప్రతి connection కు ఒకేసారి ఒక request ను మాత్రమే నిర్వహిస్తుంది. Connection: keep-alive వల్ల తదుపరి request అదే TCP connection ను మళ్లీ ఉపయోగించగలదు. దీనివల్ల setup ఖర్చు తగ్గుతుంది. అయితే responses, requests వచ్చిన క్రమంలోనే తిరిగి వస్తాయి. ఒక slow response దాని వెనుక queueలో ఉన్న అన్నింటినీ నిలిపివేస్తుంది. దీనినే head-of-line blocking అంటారు. దీన్ని నివారించడానికి browsers ఒకే hostname కు ఒకేసారి అనేక connections తెరుస్తాయి.

HTTP/2లో methods మరియు status codes అలాగే ఉంటాయి. Framing మాత్రం binaryగా మారుతుంది. అనేక requests ఒకే connection ను independent streamsగా పంచుకుంటాయి. పునరావృతమయ్యే header text compress అవుతుంది. ఆధునిక requestలో header text ఎక్కువగా ఉండటం వల్ల ఇది ఉపయోగకరం. Connection ఇంకా TCPపైనే ఉంటుంది. అందువల్ల ఒక packet పోయినప్పుడు, retransmission వచ్చే వరకు ఆ connectionలోని ప్రతి stream నిలిచిపోతుంది. Head-of-line blocking తొలగిపోలేదు. అది HTTP స్థాయి నుంచి transport స్థాయికి మారింది. Server push HTTP/2లో భాగంగా ఉండేది. కానీ Chrome 2022లో దానికి support తొలగించినందున, ఆచరణలో అది లేదు.

HTTP/3లో semantics మళ్లీ అలాగే ఉంటాయి. TCP స్థానంలో UDP (user datagram protocol)పై నిర్మించిన transport అయిన QUIC వస్తుంది. QUIC streams కింది స్థాయి వరకు కూడా independentగా ఉంటాయి. అందువల్ల packet పోయినప్పుడు, అది చెందిన stream మాత్రమే నిలిచిపోతుంది. TLS 1.3, QUIC handshakeలో భాగంగా built-inగా ఉంటుంది. దానిపై వేరుగా layer చేయాల్సిన అవసరం లేదు. అందువల్ల కొత్త connectionకు round trips తక్కువగా అవసరమవుతాయి. దీనివల్ల రెండు ఆచరణాత్మక పరిణామాలు ఉంటాయి: మార్గంలోని ప్రతి firewallలో UDP port 443 openగా ఉండాలి. UDPను throttle చేసే లేదా 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 కేవలం optional decoration కాదు. అది discovery mechanism. nginxలో version 1.25.1 నుంచి HTTP/2 ప్రత్యేక directiveగా మారింది (పాత listen ... http2 parameter స్థానంలో, server blockలో http2 on;గా). Mainline 1.25.0లో QUIC వచ్చింది. అక్కడ HTTP/3 siteకు సాధారణ listen 443 ssl;తో పాటు listen 443 quic reuseport; కూడా అవసరం.

ఇక్కడ proxies పరిపక్వతలో వేర్వేరుగా ఉంటాయి. మీరు వాస్తవంగా నడుపుతున్న versionతో ఇది సరిపోతుందో పరిశీలించాలి. August 2026 నాటికి, Caddy ఎటువంటి configuration లేకుండానే HTTP/3ను defaultగా అందిస్తుంది. nginxకు పైన పేర్కొన్న explicit quic listenerతో పాటు Alt-Svc header అవసరం. Traefikలో ప్రతి entry pointకు explicit http3 option ద్వారా దీన్ని enable చేయాలి. మీరు అనేక Docker apps ముందు Traefikతో TLS termination చేస్తే, visitorsకు లభించే protocol version అక్కడే నిర్ణయించబడుతుంది. Browser ఏ protocolను negotiate చేసినా, proxy నుంచి మీ containerకు వెళ్లే hop సాధారణంగా plain HTTP/1.1గానే ఉంటుంది.

ఊహించకుండా verify చేయండి. curl --http3 -sS -o /dev/null -D - https://example.com/ పనిచేయాలంటే, curl -V తన featuresలో HTTP3ను list చేయాలి. అయితే చాలా distribution buildsలో ఇది చేర్చబడదు. నమ్మదగిన తనిఖీ మీ స్వంత log. Formatకు $server_protocolను జోడించి, వాస్తవ browsers ఏ protocolను negotiate చేస్తున్నాయో చూడండి. ఇవన్నీ చేయడానికి ముందు UDP 443 వాస్తవంగా openగా ఉందో నిర్ధారించండి. TCP 443ను మాత్రమే అనుమతించే firewall HTTP/3ను నిశ్శబ్దంగా విఫలమయ్యేలా చేస్తుంది. Site మాత్రం HTTP/2 ద్వారా పనిచేస్తూనే ఉంటుంది. మీ Linux serverలో ఏ ports openగా మరియు listeningలో ఉన్నాయో తెలుసుకోవడం మొదట తనిఖీ చేయాల్సిన విషయం.

HTTPS: HTTP ప్రోటోకాల్, TLS దాని రక్షణ పొర

HTTPS ప్రత్యేకమైన ప్రోటోకాల్ కాదు. ఇది TLS session లోపల పంపబడే అదే requests మరియు అదే status codes. Port 80 వాటిని plain text గా పంపుతుంది. Port 443 వాటిని encrypted గా పంపుతుంది. ముందుగా TLS handshake పూర్తవుతుంది. తరువాత HTTP request encrypted channel లో ప్రయాణిస్తుంది. ఈ క్రమం వల్ల certificate సమస్యకు status code ఉండదు. ఒక్క HTTP byte కూడా పంపకముందే వైఫల్యం జరుగుతుంది. అందువల్ల number చేయడానికి response ఉండదు.

అనేక sites ను host చేస్తున్న server లో ఒక క్రమ వివరానికి ప్రాధాన్యం ఉంది. SNI (server name indication) ఉపయోగించి certificate ఎంచుకోబడుతుంది. ఇది TLS handshake లోని field. ఏ HTTP header ఉండకముందే ఇది hostname ను plain text గా పంపుతుంది. అందువల్ల server మొదట SNI ఆధారంగా certificate ఎంచుకుంటుంది. తరువాత Host header ఆధారంగా virtual host ను ఎంచుకుంటుంది. ఇవి సాధారణంగా ఒకదానితో ఒకటి సరిపోయే రెండు వేర్వేరు lookups. అవి సరిపోకపోతే browser NET::ERR_CERT_COMMON_NAME_INVALID వంటి name mismatch ను చూపిస్తుంది. మీ default server certificate ఆ hostname ను cover చేయనప్పటికీ దానిని అందించినందున browser ఎలాంటి request ను పంపదు.

Public site కోసం నిజమైన certificate పొందండి. దాన్ని స్వయంచాలకంగా renew అయ్యేలా చేయండి. 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 దానిని trust చేయాలని మీరు చెప్పాల్సి ఉంటుంది.

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; header ఆ hostname కోసం plain HTTP ను రెండు సంవత్సరాలపాటు నిరాకరించమని browsers కు చెబుతుంది. Browsers ఈ నియమాన్ని తమ స్వంత cache నుంచి అమలు చేస్తాయి. అందువల్ల తరువాత header ను తొలగించినా ఈ నియమం రద్దు కాదు. ముందుగా కొన్ని గంటల max-age తో ప్రారంభించండి. ప్రతి subdomain నిజంగా HTTPS పై ఉందని నిర్ధారించండి. తరువాత వ్యవధిని పెంచండి.

FAQ

HTTP మరియు HTTPS మధ్య తేడా ఏమిటి?

HTTPS అనేది TLS (transport layer security) session లో పంపబడే HTTP. Methods మరియు status codes ఒకేలా ఉంటాయి. మారేది ఏమిటంటే, client మరియు TLS ను terminate చేసే భాగం మధ్య bytes encrypt అవుతాయి. 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 proxy చేస్తున్న upstream నుంచి ఉపయోగించగల response ను పొందలేకపోయిందని అర్థం. Visitor పంపిన request సరిగానే ఉంది, కానీ nginx వెనుక ఉన్న భాగంలో సమస్య ఉంది. /var/log/nginx/error.log ను చదవండి. connect() failed (111: Connection refused) while connecting to upstream అంటే proxy_pass లోని address మరియు port వద్ద ఏదీ listening లో లేదని అర్థం. కాబట్టి application నడుస్తోందో, మీరు ఆశించిన address మరియు port కు bind అయిందో తనిఖీ చేయండి. no live upstreams while connecting to upstream అంటే repeated failures తర్వాత upstream block లోని ప్రతి server ను down గా గుర్తించారని అర్థం. దీనిని 504 Gateway Timeout తో పోల్చండి. 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; ను set చేయండి. తరువాత receiving nginx పై set_real_ip_from ను proxy address range కు set చేసి, real_ip_header X-Forwarded-For; ను configure చేయండి. మీరు నియంత్రించే ranges ను మాత్రమే జాబితా చేయండి. ఎందుకంటే ఆ header ను ఏ client అయినా పంపగల text మాత్రమే. మొత్తం internet నుంచి వచ్చిన విలువను నమ్మితే, visitor log లో నమోదు చేసే address ను మరియు rate limit వర్తించే address ను ఎంచుకోగలడు.

HTTP/2 లేదా HTTP/3 ను enable చేయాలా?

ఇప్పటికే TLS ఉన్న site లో HTTP/2 ను enable చేయడం ఉపయోగకరం. దీనికి ఒక directive చాలు. అలాగే అనేక చిన్న files ఉన్న page ను నెమ్మదించే ప్రతి-connection request limit తొలగుతుంది. HTTP/3 ద్వారా లభించే ప్రయోజనం తక్కువగా ఉండవచ్చు, అది ఖచ్చితంగా ఉండదు. దీనికి open UDP port 443 మరియు QUIC support కలిగిన proxy build అవసరం. Browsers ముందుగా వచ్చిన response లో Alt-Svc header ను చూసిన తర్వాత మాత్రమే HTTP/3 కు మారతాయని గుర్తుంచుకోండి. కాబట్టి ఆ header లేకపోతే, మీ listen line ఏమి చెబుతున్నా ఎలాంటి మార్పూ జరగదు. 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 ను read చేయలేకపోతున్నాడని అర్థం. చాలాసార్లు సమస్య file mode లో ఉండదు; parent directory పై others కు execute permission లేకపోవడమే కారణం. directory index of ... is forbidden అంటే request index file లేని directory కి resolve అయిందని అర్థం. ఈ సందర్భంలో autoindex off లో ఉంది. Matching location block లోని explicit deny rule కూడా 403 ను return చేస్తుంది. కాబట్టి error log లో ఏమీ కనిపించకపోతే ఆ block ను చదవండి.

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