SSD Nodes Learn 🎉 VPS kutoka $5.50/mwezi
Mwongozo Matt ConnorNa Matt Connor · Imeboreshwa 2026-08-13

HTTP ni nini na inavyofanya kazi kwenye seva

Jifunze misingi ya HTTP kwa wasimamizi wa seva. Pata ufafanuzi wa mbinu, misimbo ya hali, vichwa muhimu, na jinsi HTTP/3 na TLS zinavyoathiri kumbukumbu za nginx na utendaji.

HTTP ni nini?

HTTP (hypertext transfer protocol) ni seti ya kanuni ambazo mteja na seva ya wavuti huzitumia kuomba kitu na kukituma kikirudi. Mteja hutuma ombi: mbinu kama GET, njia kama /pricing, toleo la itifaki, orodha ya vichwa (headers), na wakati mwingine mwili wa ujumbe (body). Seva hujibu kwa msimbo wa hali (status code) kama 200, ikifuatiwa na vichwa vyake yenyewe na kwa kawaida mwili wa ujumbe. Kila mtazamo wa ukurasa na kila mwito wa API (application programming interface) kwenye seva yako ni ubadilishanaji huo mmoja, unaorudiwa.

HTTP haina hali (state) yake yenyewe. Seva haikumbuki ulichoomba sekunde iliyopita, kwa hivyo chochote kinachofanya kazi kama kumbukumbu, kwa mfano kipindi cha kuingia (login session), hubebwa kwenye kichwa katika kila ombi moja. Sifa hiyo moja inaelezea mengi ya yale yanayofuata: caching huendeshwa kikamilifu na vichwa, na load balancer inaweza kutuma ombi lako linalofuata kwa backend tofauti bila kuvunja chochote.

Kila kitu hapa chini ni jinsi mtindo huo unavyoonekana kutoka upande wa seva, katika access log yako na katika usanidi wa nginx.

Ombi na jibu ghafi, vilivyofafanuliwa

Hili hapa ni ombi kamili la HTTP/1.1. Mstari mtupu huashiria mwisho wa vichwa vya habari (headers), na chochote kilicho baada ya mstari huo ni mwili wa ujumbe (body). GET kwa kawaida huwa haina mwili.

GET /pricing HTTP/1.1
Host: example.com
User-Agent: curl/8.5.0
Accept: */*
Accept-Encoding: gzip
  • GET ni mbinu (method), inayoeleza unachotaka kifanyike. GET husoma, POST hutuma data, PUT hubadilisha, DELETE huondoa, HEAD huomba vichwa vya habari vya GET bila mwili wake.
  • /pricing ni njia (path). Jina la seva (hostname) si sehemu ya mstari wa ombi, ndiyo maana kichwa cha habari kinachofuata kipo.
  • HTTP/1.1 ni toleo la itifaki (protocol version) ambalo mteja anatumia.
  • Host: example.com hutaja tovuti ambayo mteja anaitaka. HTTP/1.1 inahitaji hili, kwa hivyo nginx hujibu ombi lisilo na jina hilo kwa 400 Bad Request.
  • Mengine yote ni mapendeleo. Accept-Encoding: gzip huashiria kuwa mteja anaweza kufungua faili zilizobanwa (decompress), hivyo seva inaruhusiwa kubana mwili wa ujumbe.

Jibu lina umbo sawa na mstari wa hali (status line) juu.

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 ni msimbo wa hali (status code) pamoja na maelezo yake. Msimbo ndio muhimu. Maelezo ni mapambo tu na wateja huyapuuza.
  • Content-Type humwambia mteja jinsi ya kushughulikia baiti zinazofuata.
  • Content-Length ni ukubwa wa mwili wa ujumbe katika baiti, ili mteja ajue mwili unapoishia. Wakati ukubwa haujulikani mapema, seva hutuma Transfer-Encoding: chunked badala yake na kuashiria mwisho kwa chunk yenye urefu wa sifuri.
  • Cache-Control humwambia kivinjari na cache yoyote iliyopo katikati muda ambao wanaweza kuhifadhi jibu hili.
  • Mstari mtupu baada ya vichwa vya habari hutenganisha vichwa hivyo na mwili wa ujumbe, katika pande zote mbili.

Majina ya vichwa vya habari hayajali herufi kubwa au ndogo (case insensitive), na kila mstari huishia na carriage return ikifuatiwa na line feed badala ya newline ya kawaida. Hutayaandika haya kwa mkono, lakini utakutana nayo katika ukamataji wa pakiti (packet capture).

Ili kutazama jozi halisi, endesha amri hii dhidi ya tovuti unayomiliki:

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

-D - huandika vichwa vya habari vya jibu kwenye terminal yako na -o /dev/null hutupa mwili wa ujumbe. Pendelea njia hii kuliko curl -I, kwa sababu -I hutuma ombi la HEAD. Seva ya programu inayoshughulikia HEAD kwa njia tofauti na GET, na nyingi hufanya hivyo, itakuonyesha vichwa vya habari ambavyo kivinjari chochote hakipokei. curl -v huchapisha pande zote mbili, huku mistari ya ombi ikiwa imewekwa alama > na mistari ya jibu ikiwa imewekwa alama <.

What the request line looks like in your nginx access log

nginx ships a combined log format, and this is its definition:

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

One line produced by it:

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 is $remote_addr, the address that opened the TCP (transmission control protocol) connection. Behind a proxy this is the proxy, not the visitor.
  • The first - is a fixed placeholder. The second is $remote_user, which is filled only when HTTP basic authentication is in use.
  • "GET /pricing HTTP/1.1" is $request, the request line copied exactly as it arrived.
  • 200 is the status your server returned, not the status the visitor perceived.
  • 5310 is $body_bytes_sent, the body alone. Response headers are not counted, so this number is always smaller than the bytes actually sent.
  • The last two quoted fields are Referer and User-Agent. Both come from the client, so both can hold anything.

Because $request is copied verbatim, junk appears verbatim. A client that speaks TLS (transport layer security) to your plaintext port 80 leaves a 400 line whose request field starts with escaped bytes like "\x16\x03\x01\x02\x00\x01". \x16 is the TLS handshake record type, so those bytes are the start of a ClientHello and not a request line at all. Your server is behaving correctly. Something is pointing HTTPS at an HTTP port.

Add $server_protocol to your log format as well. It prints HTTP/1.1, HTTP/2.0 or HTTP/3.0, and it is the fastest way to prove that a protocol change actually took effect.

Maana ya status codes za kawaida wakati tovuti yako inazirejesha

Namba ya kwanza inaashiria daraja, na daraja ndilo unalopaswa kulisoma kwanza.

2xx inamaanisha imefanikiwa. 200 OK kwa usomaji wa kawaida. 201 Created baada ya POST iliyounda kitu fulani. 204 No Content kwa mafanikio bila kitu cha kurejesha, ambayo ndiyo jibu la kawaida kwa DELETE.

3xx inamaanisha angalia kwingine. 301 ni ya kudumu na vivinjari huihifadhi kwenye cache kwa nguvu, wakati mwingine hadi mtumiaji afute wasifu wake, kwa hivyo 301 inayoelekeza kwenye hostname isiyo sahihi ni ngumu kurekebisha. Tumia 302 wakati bado unafanya majaribio ya redirect. 304 Not Modified ni mafanikio, si kosa: mteja alituma If-None-Match iliyobeba ETag (entity tag) unayoitambua bado, kwa hivyo ulijibu kwa headers bila body. Log iliyojaa 304s inamaanisha caching inafanya kazi.

4xx inamaanisha ombi lilikuwa na makosa. 400 Bad Request ni input iliyoundwa vibaya. 401 Unauthorized inamaanisha haujathibitishwa (unauthenticated), na lazima ibebe header ya WWW-Authenticate inayotaja mfumo husika. 403 Forbidden inamaanisha ombi lilieleweka lakini likakataliwa. 404 Not Found ni njia (path) isiyokuwepo. 405 Method Not Allowed ni njia sahihi yenye method isiyo sahihi, ambayo ndiyo kitu ambacho POST kwenye eneo la faili tuli (static file) hurejesha. 413 ni body kubwa kuliko client_max_body_size ya nginx, ambayo kwa kawaida ni 1 megabyte, na log ya makosa inathibitisha hilo kwa client intended to send too large body.

403 kwenye faili tuli karibu kila mara inahusu mfumo wa faili (filesystem) badala ya sheria ya HTTP. Soma /var/log/nginx/error.log kabla ya kubadilisha usanidi wowote. open() "/srv/site/index.html" failed (13: Permission denied) inamaanisha mtumiaji wa nginx worker hawezi kusoma faili hiyo, mara nyingi kwa sababu folda kuu (parent directory) inakosa ruhusa ya execute kwa wengine. directory index of "/srv/site/" is forbidden inamaanisha njia ilielekeza kwenye folda isiyo na faili ya index wakati autoindex imezimwa.

5xx inamaanisha upande wako umeharibika. 500 ni kosa lisiloshughulikiwa kwenye programu yako. 502 Bad Gateway inamaanisha nginx haikuweza kupata jibu linalotumika kutoka kwa upstream, na log ya makosa inataja sababu: connect() failed (111: Connection refused) while connecting to upstream inamaanisha hakuna kinachosikiliza kwenye anwani iliyo katika proxy_pass. 504 Gateway Timeout inamaanisha upstream ilikubali muunganisho kisha ikakaa kimya ndani ya proxy_read_timeout, sekunde 60 kwa kawaida, jambo ambalo log inarekodi kama upstream timed out (110: Connection timed out) while reading response header from upstream. 503 Service Unavailable ni kukataa kwa makusudi. Kumbuka kuwa rate limiter ya nginx yenyewe hurejesha 503, kwa sababu limit_req_status kwa kawaida ni 503. Ikiwa unatafuta 429 Too Many Requests kwenye log yako na kupata 503 badala yake, ndiyo sababu. Weka limit_req_status 429; ili kupata code sahihi.

Header muhimu unapoendesha seva

Host huchagua tovuti. Anwani moja ya IP inaweza kuhudumia mamia ya majina ya host, na nginx hulinganisha Host dhidi ya server_name ili kuamua ni block ipi ya server itakayojibu. Ikiwa hakuna kinacholingana, nginx hutumia seva chaguo-msingi, ambayo ni block ya kwanza inayosikiliza kwenye anwani na port hiyo isipokuwa nyingine iwe imewekewa alama ya default_server. Kupata tovuti isiyo sahihi kutoka kwa virtual host mpya karibu kila mara hutokana na hili: jina halikulingana, kwa hivyo ombi liliangukia kwenye chaguo-msingi. Ijaribu bila kugusa DNS:

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

User-Agent ni maelezo binafsi yaliyoandikwa na mteja, na ni maandishi huru. Itumie kama dokezo unaposoma log. Usiitumie kamwe kama njia ya kudhibiti, kwa sababu mteja anayetaka kusema uongo kuhusu hilo hufanya hivyo kwa urahisi, kwa hivyo kuzuia scraper kwa kutumia User-Agent huchuja zile zenye adabu pekee.

Content-Type huamua jinsi baiti zinavyofafanuliwa: application/json kwa ombi la API, text/html; charset=utf-8 kwa ukurasa. nginx hulinganisha viendelezi vya faili na aina kwa kutumia /etc/nginx/mime.types, na nginx.conf iliyowekwa kwenye kifurushi huweka default_type application/octet-stream;, kwa hivyo faili yenye kiendelezi ambacho nginx haikijui hutolewa kama upakuaji badala ya kuonyeshwa. Dalili inayoonekana ni ukurasa unaopakia bila mtindo (styling) huku console ya kivinjari ikichapisha Refused to apply style from ... because its MIME type ('text/plain') is not a supported stylesheet MIME type. MIME hapa inamaanisha multipurpose internet mail extensions, mpango wa utoaji majina ambao kamba hizo za aina hutoka.

Cache-Control ndiyo njia unayodhibiti kila cache kati ya seva yako na msomaji. public, max-age=31536000, immutable inafaa kwa rasilimali ambazo jina la faili lina content hash, kwa sababu jina hubadilika wakati maudhui yanapobadilika. no-store inafaa kwa kitu chochote mahususi kwa mtumiaji, kwa sababu cache ya pamoja inayohifadhi ukurasa uliolingiwa (logged in) itaupa mtu mwingine anayeomba URL hiyo hiyo. private ni mpangilio wa kati: kivinjari kinaweza kukihifadhi, cache ya pamoja haiwezi.

X-Forwarded-For ipo kwa sababu proxy huficha mgeni. Ombi linapopita kwenye reverse proxy, $remote_addr huwa ni anwani ya proxy, kwa hivyo log zako, geolocation yako na rate limiting yako yote huona mteja mmoja. Proxy lazima ipitishe anwani asilia:

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

Seva inayopokea lazima iambiwe iiamini, na iambiwe hasa nani wa kumuamini:

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

Orodhesha tu safu unazozidhibiti. X-Forwarded-For ni maandishi wazi ambayo mteja yeyote anaweza kutuma, kwa hivyo set_real_ip_from 0.0.0.0/0; humruhusu mgeni kuchagua anwani unayoiweka kwenye log na anwani ambayo rate limiter yako huihesabu.

X-Forwarded-Proto huzuia hitilafu mahususi na ya kawaida sana. Proxy yako hukomesha TLS na kusambaza ombi kwa programu kupitia HTTP ya kawaida. Programu huona ombi la kawaida, huamua kuwa mgeni anapaswa kuwa kwenye HTTPS, na kujibu 301 https://example.com/. Kivinjari hufuata, proxy hukomesha TLS tena na kusambaza HTTP ya kawaida tena, na mzunguko hurudia hadi kivinjari kinapokata tamaa kwa ERR_TOO_MANY_REDIRECTS. Kutuma X-Forwarded-Proto: https huiambia programu kuwa mgeni tayari yuko kwenye HTTPS, kwa hivyo huacha kuelekeza upya.

HTTP/1.1 dhidi ya HTTP/2 dhidi ya HTTP/3: nini kinabadilika kwako

HTTP/1.1 ni maandishi, na hushughulikia ombi moja kwa wakati mmoja kwa kila muunganisho. Connection: keep-alive huruhusu ombi linalofuata kutumia tena muunganisho uleule wa TCP, jambo linalookoa gharama ya kuanzisha muunganisho, lakini majibu bado hurudi kwa mpangilio uleule wa maombi. Jibu moja la polepole huziba kila kitu kilichopangwa nyuma yake. Hilo ni tatizo la head-of-line blocking, na vivinjari hulikwepa kwa kufungua miunganisho kadhaa kwa hostname moja kwa wakati mmoja.

HTTP/2 hudumisha mbinu zilezile na status codes zilezile, na hubadilisha mfumo wa framing kuwa binary. Maombi mengi hushiriki muunganisho mmoja kama streams huru, na maandishi ya header yanayojirudia hubanwa (compressed), jambo ambalo ni muhimu kwa sababu ombi la kisasa hubeba mengi. Muunganisho bado ni TCP, kwa hivyo pakiti moja iliyopotea husimamisha kila stream kwenye muunganisho huo hadi retransmission ifike. Tatizo la head-of-line blocking halikutoweka. Lilishuka kutoka HTTP hadi kwenye transport. Server push ilikuwa sehemu ya HTTP/2 na kwa vitendo imetoweka, kwa sababu Chrome iliondoa usaidizi wake mwaka 2022.

HTTP/3 hudumisha semantics zilezile tena na kuchukua nafasi ya TCP kwa QUIC, transport iliyojengwa juu ya UDP (user datagram protocol). Streams za QUIC ni huru kabisa, kwa hivyo pakiti iliyopotea husimamisha tu stream iliyokuwa na pakiti hiyo. TLS 1.3 imejengwa ndani ya handshake ya QUIC badala ya kuwekwa juu yake, kwa hivyo muunganisho mpya unahitaji round trips chache. Matokeo mawili ya kivitendo hufuata: port ya UDP 443 lazima iwe wazi katika kila firewall kwenye njia, na mtandao wowote unaopunguza kasi au kuzuia UDP utawarudisha wateja kwenye HTTP/2.

Nini kinabadilika kwako, kwa hakika. Vivinjari havianzi kamwe kwenye HTTP/3. Huunganisha kupitia HTTP/2 au HTTP/1.1, huona header ya Alt-Svc: h3=":443"; ma=86400 kwenye jibu, na hutumia HTTP/3 kwa miunganisho ya baadaye kwa host huyo. Kwa hivyo header hiyo si mapambo ya hiari. Ni utaratibu wa ugunduzi. Katika nginx, HTTP/2 ilikuwa directive yake yenyewe katika toleo la 1.25.1 (http2 on; ndani ya block ya server, ikichukua nafasi ya parameter ya zamani ya listen ... http2), na QUIC ilifika katika mainline 1.25.0, ambapo tovuti ya HTTP/3 inahitaji listen 443 quic reuseport; pamoja na listen 443 ssl; ya kawaida.

Proxies hutofautiana katika ukomavu hapa, na ni vyema kuangalia hili dhidi ya toleo unalotumia. Kufikia Agosti 2026, Caddy hutoa HTTP/3 kwa chaguo-msingi bila usanidi wowote. nginx inahitaji listener ya wazi ya quic pamoja na header ya Alt-Svc iliyoelezwa hapo juu. Traefik huiwezesha kwa kila entry point kupitia chaguo la wazi la http3. Ikiwa unamalizia TLS kwenye Traefik mbele ya programu kadhaa za Docker, toleo la itifaki ambalo wageni wako hupata huamuliwa hapo, na hatua kutoka kwa proxy kwenda kwenye container yako kwa kawaida huwa ni HTTP/1.1 ya kawaida bila kujali kile ambacho kivinjari kilikubaliana.

Thibitisha badala ya kudhani. curl --http3 -sS -o /dev/null -D - https://example.com/ hufanya kazi tu ikiwa curl -V inaorodhesha HTTP3 miongoni mwa vipengele vyake, na builds nyingi za usambazaji hazijumuishi. Ukaguzi wa kutegemewa ni log yako mwenyewe: ongeza $server_protocol kwenye format na usome kile ambacho vivinjari halisi vinakubaliana. Kabla ya hayo yote, thibitisha kuwa UDP 443 iko wazi, kwa sababu firewall inayoruhusu TCP 443 pekee itafanya HTTP/3 kushindwa kimya kimya wakati tovuti ikiendelea kufanya kazi kupitia HTTP/2. Kujua ni ports zipi ziko wazi na zinasikiliza kwenye seva yako ya Linux ndilo jambo la kwanza la kuangalia.

HTTPS: HTTP ni itifaki, TLS ni kanga

HTTPS si itifaki tofauti. Ni maombi yaleyale na status codes zilezile zinazopitishwa ndani ya session ya TLS. Port 80 huzibeba bila usimbaji na port 443 huzibeba zikiwa zimesimbwa. TLS handshake hukamilika kwanza, kisha ombi la HTTP husafiri ndani ya njia iliyosimbwa. Mpangilio huo ndio sababu tatizo la cheti halina status code: hitilafu hutokea kabla ya byte moja ya HTTP kutumwa, kwa hivyo hakuna jibu la kupewa namba.

Maelezo moja ya mpangilio ni muhimu kwenye seva inayohudumia tovuti kadhaa. Cheti huchaguliwa kwa kutumia SNI (server name indication), uwanja katika TLS handshake unaobeba hostname bila usimbaji kabla ya header yoyote ya HTTP kuwepo. Kwa hivyo, seva huchagua cheti kutoka SNI kwanza, kisha huchagua virtual host kutoka header ya Host pili. Hizo ni lookup mbili tofauti ambazo kwa kawaida hukubaliana. Zisipokubaliana, kivinjari huonyesha kutolingana kwa jina kama NET::ERR_CERT_COMMON_NAME_INVALID na hakitumi ombi lolote, kwa sababu cheti cha seva yako ya msingi kilitolewa kwa jina lisilohusika.

Kwa tovuti ya umma, pata cheti halisi na uiruhusu ijirenew yenyewe. Certbot na Let's Encrypt kwenye nginx huandika njia za cheti kwenye server block yako na kukuwekea timer ya renewal. Kwa hostname ambayo mamlaka yoyote ya umma haiwezi kuithibitisha, kama jina la ndani au IP address kwenye mtandao wako binafsi, cheti cha self-signed kwenye Ubuntu ndiyo chaguo la kweli, mradi ukubali kuwa kila mteja lazima aambiwe kukiamini.

TLS ikishafanya kazi, tuma kila kitu kutoka port 80 kwenda port 443:

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

Ongeza Strict-Transport-Security pale tu unapokuwa na uhakika. Header ya add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always; huwaambia vivinjari kukataa HTTP ya kawaida kwa hostname hiyo kwa miaka miwili, na wao hutii kutoka kwenye cache yao, jambo linalomaanisha kuwa kuondoa header hiyo baadaye hakutafuta athari hiyo. Anza na max-age ya saa chache, thibitisha kila subdomain iko kwenye HTTPS kweli, kisha iongeze.

FAQ

Kuna tofauti gani kati ya HTTP na HTTPS?

HTTPS ni HTTP inayotumwa ndani ya session ya TLS (transport layer security). Mbinu na status codes ni sawa kabisa. Kinachobadilika ni kwamba data husimbwa (encrypted) kati ya mteja na kifaa kinachomalizia TLS, na port ya kawaida hubadilika kutoka 80 kwenda 443. Kwa sababu TLS handshake hukamilika kabla ya byte ya kwanza ya HTTP kutumwa, hitilafu ya cheti haitoi status code yoyote; ndiyo maana onyo la cheti kwenye kivinjari huonyesha jina la hitilafu kama NET::ERR_CERT_COMMON_NAME_INVALID badala ya namba kama 403.

Kwa nini tovuti yangu inarudisha 502 Bad Gateway?

502 kutoka kwa nginx inamaanisha kuwa nginx haikuweza kupata jibu linalofaa kutoka kwa upstream inayoiwakilisha, kwa hivyo ombi la mgeni lilikuwa sawa lakini kitu kilicho nyuma ya nginx hakikuwa sawa. Soma /var/log/nginx/error.log. connect() failed (111: Connection refused) while connecting to upstream inamaanisha hakuna kinachosikiliza kwenye anwani na port iliyo katika proxy_pass, kwa hivyo hakikisha programu inafanya kazi na imefungwa kwenye sehemu unayotarajia. no live upstreams while connecting to upstream inamaanisha kila seva katika upstream block imewekwa chini baada ya kushindwa mara kwa mara. Linganisha na 504 Gateway Timeout, ambayo inamaanisha upstream ilikubali muunganisho lakini ikashindwa kujibu ndani ya proxy_read_timeout.

Kwa nini access log yangu inaonyesha IP address ileile kwa kila mgeni?

Kwa sababu $remote_addr hurekodi anwani iliyofungua muunganisho wa TCP, na nyuma ya reverse proxy au content delivery network, anwani hiyo ni ya proxy. Anwani ya mgeni hufika kupitia header ya X-Forwarded-For badala yake. Weka proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; kwenye proxy, kisha kwenye nginx inayopokea, weka set_real_ip_from kwa anwani ya proxy na real_ip_header X-Forwarded-For;. Orodhesha tu anwani unazozimiliki, kwa sababu header hiyo ni maandishi ambayo mteja yeyote anaweza kutuma; hivyo, kuiamini kutoka kwa Internet nzima humruhusu mgeni kuchagua anwani unayorekodi na anwani unayoiwekea rate limit.

Je, ninahitaji kuwasha HTTP/2 au HTTP/3?

HTTP/2 inafaa kuwashwa, kwa sababu ni maelekezo moja tu kwenye tovuti ambayo tayari ina TLS, na huondoa kikomo cha maombi kwa kila muunganisho ambacho hufanya ukurasa wenye faili nyingi ndogo kuwa wa polepole. HTTP/3 ni faida ndogo na isiyo na uhakika, na inakugharimu kufungua port ya UDP 443 pamoja na proxy iliyojengwa kwa msaada wa QUIC. Kumbuka kuwa vivinjari hubadilika kwenda HTTP/3 tu baada ya kuona header ya Alt-Svc kwenye jibu la awali, kwa hivyo bila header hiyo hakuna kinachobadilika bila kujali mstari wako wa listen unasema nini. Ongeza $server_protocol kwenye muundo wa log yako na upime kile wageni wanachokubaliana kabla ya kutumia muda wako hapo.

403 Forbidden inamaanisha nini wakati faili ipo?

Kwenye tovuti ya static, 403 kwa kawaida ni suala la ruhusa za mfumo wa faili (filesystem permission) badala ya sheria ya HTTP. open() ... failed (13: Permission denied) katika /var/log/nginx/error.log inamaanisha mtumiaji wa nginx hawezi kusoma faili hiyo, mara nyingi kwa sababu folda kuu (parent directory) haina ruhusa ya execute kwa wengine, badala ya mode ya faili yenyewe kuwa mbaya. directory index of ... is forbidden inamaanisha ombi lilienda kwenye folda isiyo na faili ya index wakati autoindex imezimwa. Sheria ya wazi ya deny katika block inayolingana ya location pia hurudisha 403, kwa hivyo soma block hiyo wakati error log haisemi chochote.

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