HTTP ni nini? Mwongozo kwa wasimamizi wa seva

HTTP ni nini?

HTTP (hypertext transfer protocol) ni seti ya kanuni ambazo mteja na seva ya wavuti hutumia 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 (body). Seva hujibu kwa msimbo wa hali (status code) kama 200, ikifuatiwa na vichwa vyake na kwa kawaida mwili. 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 kikao 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 kuharibu chochote.

Kila kitu hapa chini ni jinsi mfano huo unavyoonekana kutoka upande wa seva, katika logi yako ya ufikiaji (access log) na katika usanidi wako 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 kinachofuata mstari huo ni mwili (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 mwenyeji (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, hivyo nginx hujibu ombi lisilo na jina hili kwa 400 Bad Request.
• Mengine yote ni mapendeleo. Accept-Encoding: gzip husema mteja anaweza kutoa mgandamizo (decompress), hivyo seva inaruhusiwa kubana (compress) 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 wa muhimu. Maelezo ni mapambo tu na wateja huyapuuza.
• Content-Type humwambia mteja jinsi ya kushughulikia baiti zinazofuata.
• Content-Length ni ukubwa wa mwili kwa baiti, ili mteja ajue mwili unaishia wapi. Wakati ukubwa haujulikani mapema, seva hutuma Transfer-Encoding: chunked badala yake na kuashiria mwisho kwa chunk ya urefu wa sifuri.
• Cache-Control humwambia kivinjari na akiba (cache) yoyote iliyopo katikati muda ambao wanaweza kuhifadhi jibu hili.
• Mstari mtupu baada ya vichwa vya habari hutenganisha vichwa hivyo na mwili, 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. Hutachapa haya kwa mkono, lakini utakutana nayo katika uchambuzi 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 hakitapokea. curl -v huchapisha pande zote mbili, huku mistari ya ombi ikiwa imewekewa alama ya > na mistari ya jibu ikiwa na alama ya <.

Muonekano wa mstari wa ombi katika access log ya nginx yako

nginx inakuja na muundo wa logi wa combined, na hii ndiyo ufafanuzi wake:

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

Mstari mmoja uliotolewa na muundo huo:

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 ni $remote_addr, anwani iliyoanzisha muunganisho wa TCP (transmission control protocol). Nyuma ya proxy, hii ni proxy yenyewe, siyo mtumiaji.
• - ya kwanza ni kishika nafasi kisichobadilika. Ya pili ni $remote_user, ambayo hujazwa tu wakati HTTP basic authentication inapotumika.
• "GET /pricing HTTP/1.1" ni $request, mstari wa ombi uliokopiwa kama ulivyowasili.
• 200 ni hali (status) iliyorejeshwa na seva yako, siyo hali iliyoonekana na mtumiaji.
• 5310 ni $body_bytes_sent, mwili wa ujumbe pekee. Vichwa vya habari vya majibu (response headers) havihesabiwi, kwa hivyo namba hii huwa ndogo kuliko baiti zilizotumwa kweli.
• Sehemu mbili za mwisho zilizopo kwenye alama za kunukuu ni Referer na User-Agent. Zote zinatoka kwa mteja, kwa hivyo zote zinaweza kuwa na chochote.

Kwa sababu $request inakopiwa neno kwa neno, takataka (junk) huonekana neno kwa neno. Mteja anayezungumza TLS (transport layer security) kwenye port 80 ya plaintext huacha mstari wa 400 ambao sehemu yake ya ombi huanza na baiti zilizokwepeshwa (escaped bytes) kama "\x16\x03\x01\x02\x00\x01". \x16 ni aina ya rekodi ya TLS handshake, kwa hivyo baiti hizo ni mwanzo wa ClientHello na siyo mstari wa ombi hata kidogo. Seva yako inafanya kazi kwa usahihi. Kuna kitu kinaelekeza HTTPS kwenye port ya HTTP.

Ongeza $server_protocol kwenye muundo wako wa logi pia. Inachapisha HTTP/1.1, HTTP/2.0 au HTTP/3.0, na ndiyo njia ya haraka zaidi ya kuthibitisha kuwa mabadiliko ya itifaki yameanza kufanya kazi.

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. 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, siyo hitilafu: mteja alituma If-None-Match iliyobeba ETag (entity tag) unayoitambua bado, kwa hivyo ulijibu kwa vichwa vya habari (headers) bila mwili (body). Log iliyojaa 304 inamaanisha caching inafanya kazi.

4xx inamaanisha ombi lilikuwa si sahihi. 400 Bad Request ni ingizo lililoundwa vibaya. 401 Unauthorized inamaanisha haujathibitishwa (unauthenticated), na lazima ibebe header ya WWW-Authenticate inayotaja mfumo. 403 Forbidden inamaanisha ombi lilieleweka lakini likakataliwa hata hivyo. 404 Not Found ni njia (path) isiyokuwepo. 405 Method Not Allowed ni njia sahihi yenye mbinu (method) isiyo sahihi, ambayo ndiyo jibu la POST kwenye eneo la faili tuli (static file). 413 ni mwili (body) mkubwa kuliko client_max_body_size ya nginx, ambayo kwa kawaida ni megabyte 1, na log ya hitilafu 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 saraka kuu (parent directory) inakosa ruhusa ya execute kwa wengine. directory index of "/srv/site/" is forbidden inamaanisha njia ilielekeza kwenye saraka isiyo na faili ya index wakati autoindex imezimwa.

5xx inamaanisha upande wako umeharibika. 500 ni hitilafu isiyoshughulikiwa kwenye programu yako. 502 Bad Gateway inamaanisha nginx haikuweza kupata jibu linaloweza kutumika kutoka kwa upstream, na log ya hitilafu 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, ambayo 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 kizuizi cha kiwango (rate limiter) cha nginx 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, hiyo ndiyo sababu. Weka limit_req_status 429; ili kupata code sahihi.

Headers 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 ya default, ambayo ni block ya kwanza inayosikiliza kwenye anwani na port hiyo isipokuwa nyingine imewekwa alama kama default_server. Kupata tovuti isiyo sahihi kutoka kwa virtual host mpya karibu kila mara husababishwa na hili: jina halikulingana, kwa hivyo ombi liliangukia kwenye default. Ijaribu bila kugusa DNS:

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

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

Content-Type huamua jinsi bytes zinavyotafsiriwa: 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 download badala ya kuonyeshwa. Dalili inayoonekana ni ukurasa unaopakia bila styling wakati console ya kivinjari inachapisha Refused to apply style from ... because its MIME type ('text/plain') is not a supported stylesheet MIME type. MIME hapa ni multipurpose internet mail extensions, mfumo wa majina ambapo kamba hizo za aina hutoka.

Cache-Control ndiyo njia unayotumia kudhibiti kila cache kati ya seva yako na msomaji. public, max-age=31536000, immutable inafaa kwa assets 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 wa mtu aliyeingia kwenye akaunti itaupa mtu mwingine anayeomba URL hiyo hiyo. private ni mpangilio wa kati: kivinjari kinaweza kuihifadhi, cache ya pamoja haiwezi.

X-Forwarded-For ipo kwa sababu proxy huficha mgeni. Ombi likishapita 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 masafa unayoyadhibiti. 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 na 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 matini, na hushughulikia ombi moja kwa wakati mmoja kwa kila muunganisho. Connection: keep-alive inaruhusu 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 huzuia kila kitu kilichopo kwenye foleni nyuma yake. Hilo ndilo 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 matini 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 utumaji upya utakapofika. Tatizo la head-of-line blocking halikutoweka. Lilishuka kutoka HTTP hadi kwenye transport. Server push ilikuwa sehemu ya HTTP/2 na kwa sasa haitumiki kivitendo, kwa sababu Chrome iliondoa usaidizi wake mnamo 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 zaidi. 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 utawalazimisha wateja kurudi kwenye HTTP/2.

Nini kinabadilika kwako, kwa hakika. Vivinjari havianzi kamwe kwa 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 kugundua (discovery mechanism). 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 wageni wako wanaopata huamuliwa hapo, na hatua kutoka kwa proxy kwenda kwenye container yako kwa kawaida huwa ni HTTP/1.1 ya kawaida bila kujali kile kivinjari kilichokubaliana.

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 nyingi ya builds za usambazaji hazijumuishi. Ukaguzi wa kutegemewa ni log yako mwenyewe: ongeza $server_protocol kwenye format na usome kile vivinjari halisi vinavyokubaliana. Kabla ya hayo yote, thibitisha kuwa UDP 443 iko wazi kweli, 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 (wrapper)

HTTPS si itifaki tofauti. Ni maombi yaleyale na status codes zilezile zinazopitishwa ndani ya session ya TLS. Port 80 hubeba data hizo bila usimbaji, na port 443 huzibeba zikiwa zimesimbwa. TLS handshake hukamilika kwanza, kisha ombi la HTTP husafiri ndani ya njia iliyosimbwa. Mpangilio huu ndio sababu tatizo la cheti halina status code: failure hutokea kabla ya byte hata 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 (field) 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. Hizi 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 default kilitolewa kwa jina ambacho hakikihusu.

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 ya umma haiwezi kuithibitisha, kama vile jina la ndani au IP address kwenye mtandao wako, 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 hutii amri hiyo 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 kikamilifu, kisha iongeze.

FAQ

Kuna tofauti gani kati ya HTTP na HTTPS?

HTTPS ni HTTP inayotumwa ndani ya kikao cha TLS (transport layer security). Mbinu na status codes ni sawa. Kinachobadilika ni kwamba data husimbwa kwa njia fiche (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 nginx inamaanisha nginx haikuweza kupata jibu linalofaa kutoka kwa upstream inayoiwakilisha, kwa hivyo ombi la mtumiaji lilikuwa sawa lakini kuna kitu 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 (bound) mahali unapotarajia. no live upstreams while connecting to upstream inamaanisha kila seva katika upstream block imewekwa alama ya kutofanya kazi baada ya kufeli mara kwa mara. Linganisha na 504 Gateway Timeout, ambayo inamaanisha upstream ilikubali muunganisho lakini ikashindwa kujibu ndani ya proxy_read_timeout.

Kwa nini logi yangu ya access 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 masafa ya anwani ya proxy na real_ip_header X-Forwarded-For;. Orodhesha tu masafa unayoyadhibiti, kwa sababu header hiyo ni maandishi ambayo mteja yeyote anaweza kutuma; hivyo, kuiamini kutoka kwa mtandao mzima 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 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 UDP port 443 pamoja na ujenzi wa proxy wenye support ya 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 logi yako na upime kile wageni wanachokubaliana nacho kabla ya kutumia muda wako hapo.

403 Forbidden inamaanisha nini wakati faili ipo?

Kwenye tovuti tuli (static site), 403 mara nyingi ni ruhusa ya 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 worker hawezi kusoma faili hiyo, mara nyingi kwa sababu folda mama (parent directory) haina ruhusa ya execute kwa wengine, badala ya hali ya faili yenyewe kuwa mbaya. directory index of ... is forbidden inamaanisha ombi liliishia 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 logi ya hitilafu haisemi chochote.