Pieni työkalupakki uudelleenohjausten ja HTTP-otsakkeiden vianetsintään tuotannossa

HTTP:n vianetsinnän ongelma tuotannossa

Useimmat HTTP-ongelmat ovat selaimessa näkymättömiä. Uudelleenohjausketju epäonnistuu hiljaa, välimuistiotsakkeessa on yhden merkin virhe, CORS-käytäntö estää pyynnön ilman selitystä. Selaimen kehittäjätyökalut näyttävät keskustelun tuloksen, mutta ne piilottavat usein raa’an vaihdon, joka aiheutti ongelman.

Tällä on eniten merkitystä tuotannossa, jossa et voi lisätä lokitusta tai käynnistää palveluita uudelleen nähdäksesi, mikä muuttui. Tarvitset työkaluja, jotka näyttävät todellisen HTTP-keskustelun: pyyntöotsakkeet, vastausotsakkeet, tilakoodit, uudelleenohjausten kohteet ja ajoituksen. Tässä ovat viisi työkalua, jotka tekevät sen luotettavasti, sekä niitä täydentävät selaintekniikat.

curl: perusta

curl on ensimmäinen työkalu, johon kannattaa tarttua, koska se näyttää täsmälleen, mitä palvelin lähetti, ilman selaimen tulkintaa välissä.

Näin näet vastausotsakkeet ilman runkoa:

curl -I https://example.com

Näin seuraat uudelleenohjauksia ja näet jokaisen vaiheen:

curl -L -v https://example.com

-v-lippu (verbose) näyttää koko pyynnön ja vastauksen, mukaan lukien kaikki otsakkeet. -L-lippu seuraa uudelleenohjauksia automaattisesti. Yhdessä ne näyttävät koko uudelleenohjausketjun, jossa useimmat tuotanto-ongelmat sijaitsevat.

Näin näet vain uudelleenohjausten sijainnit:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

Tästä on hyötyä, kun sinun on varmistettava uudelleenohjausketju ilman täydellisten otsakkeiden kohinaa. -w-lippu muotoilee tulosteen näyttämään vain tilakoodin ja ketjun seuraavan URL:n.

curl antaa sinun lähettää myös mukautettuja otsakkeita, mikä on olennaista CDN-käyttäytymisen, todennuksen tai API-päätepisteiden testaamisessa:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: curl paremmilla oletuksilla

httpie on Python-työkalu, joka tekee saman kuin curl, mutta sen syntaksi on helpompi muistaa ja tuloste helpompi lukea. Se ei ole korvaaja — curl on tehokkaampi ja laajemmin asennettu — mutta nopeisiin tarkistuksiin httpie on nopeampi.

Näin näet otsakkeet:

http HEAD https://example.com

Näin seuraat uudelleenohjauksia:

http --follow --all https://example.com

--all-lippu näyttää jokaisen vastauksen uudelleenohjausketjussa, ei vain viimeistä. Tämä vastaa komentoa curl -L -v, mutta tuloste on värikoodattu ja helpompi silmäillä.

Näin lähetät JSONia:

http POST https://api.example.com name=value

httpie olettaa oletuksena JSONin, mikä säästää kirjoittamista API-rajapintoja testatessa. Se myös muotoilee vastauksen luettavaksi, mikä helpottaa virheellisesti muodostettujen otsakkeiden tai odottamattomien arvojen havaitsemista.

Browser DevTools: Network-välilehti

Selaimen Network-välilehti on oikea aloituspaikka, jos ongelma tapahtuu vain selaimessa. Se näyttää saman tiedon kuin curl, mutta lisäksi selaimen tulkinnan: estikö se pyynnön, miten se käsitteli välimuistia ja lähettikö se evästeitä.

Näet täydelliset pyyntö- ja vastausotsakkeet napsauttamalla mitä tahansa pyyntöä Network-välilehdellä ja katsomalla sitten Headers-osiota. "Raw"-näkymä näyttää otsakkeet täsmälleen sellaisina kuin ne lähetettiin, ilman muotoilua.

Näet uudelleenohjausketjut etsimällä pyyntöjä, joiden tilakoodi on 3xx. Selain ryhmittelee ne lopullisen pyynnön alle, mutta voit laajentaa ne nähdäksesi jokaisen vaiheen. Tästä löydät uudelleenohjaussilmukat, puuttuvat Location-otsakkeet tai uudelleenohjaukset, jotka osoittavat väärään verkkotunnukseen.

Näet ajoituksen katsomalla minkä tahansa pyynnön Timing-välilehteä. Se näyttää, kuinka kauan selain käytti DNS-hakuun, TCP-yhteyteen, TLS-kättelyyn ja palvelimen odottamiseen. Jos uudelleenohjaus on hidas, ajoitusvälilehti kertoo, johtuuko ongelma verkon viiveestä vai palvelimen käsittelystä.

Yksi rajoitus: selain piilottaa joitakin otsakkeita turvallisuussyistä. Set-Cookie-otsakkeet näkyvät, mutta varsinaiset evästearvot peitetään. Authorization-otsakkeet piilotetaan joskus kokonaan. Jos sinun on nähtävä ne, käytä curlia.

mitmproxy: väliin asettuva välityspalvelin

mitmproxy on Python-työkalu, joka asettuu selaimesi ja palvelimen väliin ja näyttää jokaisen pyynnön ja vastauksen reaaliajassa. Se on monimutkaisempi kuin curl, mutta se on ainoa työkalu, joka näyttää, mitä selain todella lähettää, mukaan lukien otsakkeet, jotka selain lisää automaattisesti.

Käynnistä se näin:

mitmproxy

Määritä sitten selaimesi käyttämään localhost:8080 HTTP-välityspalvelimena. mitmproxy näyttää jokaisen pyynnön päätenäkymässä. Voit tarkastaa otsakkeita, muokata pyyntöjä ennen niiden lähettämistä tai toistaa pyyntöjä eri parametreilla.

Tästä on hyötyä sellaisten ongelmien vianetsinnässä, jotka tapahtuvat vain selaimessa: CORS preflight -pyynnöt, evästeiden käsittely tai pyynnöt, jotka epäonnistuvat tiettyjen otsakkeiden ollessa läsnä. Se on hyödyllinen myös testattaessa, miten sivustosi käyttäytyy yrityksen välityspalvelimen tai VPN:n takana, koska mitmproxy voi simuloida tällaisia ympäristöjä.

Haittapuolena on käyttöönoton monimutkaisuus. Sinun on asennettava juurivarmenne, jotta mitmproxy voi siepata HTTPS-liikennettä, ja sinun on määritettävä selain käyttämään välityspalvelinta. Nopeisiin tarkistuksiin curl on nopeampi. Syvälliseen vianetsintään mitmproxy on käyttöönottoon kuluvan ajan arvoinen.

webpagetest: tuotannon näkökulma

WebPageTest on ilmainen palvelu, joka lataa sivusi oikeilla selaimilla eri sijainneista ja näyttää koko HTTP-keskustelun. Se on hitaampi kuin curl, mutta se näyttää, mitä todelliset käyttäjät kokevat, mukaan lukien CDN-käyttäytymisen, DNS-selvityksen ja TLS-neuvottelun.

"Request Headers"- ja "Response Headers" -näkymät näyttävät täsmälleen, mitä selain lähetti ja vastaanotti. "Waterfall"-näkymä näyttää jokaisen pyynnön ajoituksen, mukaan lukien uudelleenohjaukset. Täältä löydät ongelmat, jotka tapahtuvat vain tietyillä alueilla tai tietyissä verkoissa.

WebPageTest näyttää myös päädokumentin uudelleenohjausketjun, jossa useimmat uudelleenohjausongelmat sijaitsevat. Jos sivustosi ohjaa osoitteesta http:// osoitteeseen https://, sitten osoitteesta www. muotoon ilman www.-etuliitettä ja sitten polusta / polkuun /en/, WebPageTest näyttää kaikki kolme vaihetta ja kuinka kauan kukin niistä kesti.

Työkaluihin, jotka auttavat validoimaan ja optimoimaan näitä HTTP-perusteita, Wux Webtools tarjoaa useita apuohjelmia, jotka toimivat kokonaan selaimessasi, mukaan lukien otsakeanalysaattorit ja uudelleenohjausten tarkistimet, jotka kunnioittavat yksityisyyttäsi käsittelemällä kaiken asiakaspuolella.

Kun otsakkeet valehtelevat

Vaikeimmat HTTP-ongelmat ovat niitä, joissa palvelin lähettää keskenään ristiriitaisia otsakkeita. Cache-Control-otsake sanoo no-cache, mutta Expires-otsake sanoo resurssin olevan voimassa vuoden. Location-otsake osoittaa suhteelliseen URL-osoitteeseen, mutta Content-Location-otsake osoittaa muualle. Selaimen on arvattava, mihin luottaa, ja eri selaimet arvaavat eri tavoin.

Kun näin tapahtuu, sinun on nähtävä raa’at otsakkeet siinä järjestyksessä, jossa palvelin lähetti ne. curl -v tekee tämän. Samoin tekee mitmproxy. Selaimen DevTools järjestää otsakkeet joskus uudelleen luettavuuden vuoksi, mikä piilottaa ongelman.

Toinen yleinen ongelma: otsakkeet, jotka lisää CDN tai kuormantasaaja, ei sovelluksesi. Jos selvität välimuistiongelmaa, sinun on tiedettävä, tuliko Cache-Control-otsake sovelluksestasi vai CDN:stä. curl näyttää lopputuloksen, mutta se ei kerro, mistä kukin otsake tuli. Tätä varten sinun on ohitettava CDN (osumalla suoraan alkuperäpalvelimeen) ja verrattava otsakkeita.

Uudelleenohjaussilmukan ongelma

Uudelleenohjaussilmukat ovat yleisin HTTP-ongelma tuotannossa. Ne tapahtuvat, kun kaksi palvelinta on eri mieltä siitä, minne URL:n pitäisi osoittaa: CDN ohjaa alkuperäpalvelimeen, alkuperäpalvelin ohjaa takaisin CDN:ään. Tai kuormantasaaja ohjaa HTTP:n HTTPS:ään, mutta sovellus ohjaa HTTPS:n takaisin HTTP:hen, koska se ei näe X-Forwarded-Proto-otsaketta.

Tämän vianetsintään sinun on nähtävä koko uudelleenohjausketju, mukaan lukien Location-otsake jokaisessa vaiheessa. curl -L -v tekee tämän, mutta se pysähtyy 50 uudelleenohjauksen jälkeen estääkseen loputtomat silmukat. Jos osut tähän rajaan, sinulla on uudelleenohjaussilmukka.

Korjaus on yleensä määritysmuutos: kerro sovellukselle, että se luottaa X-Forwarded-Proto-otsakkeeseen, tai kerro CDN:lle, ettei se enää uudelleenohjaa pyyntöjä, jotka ovat jo HTTPS:ää. Et kuitenkaan voi korjata sitä ennen kuin näet silmukan, eikä selain näytä sinulle muutamaa uudelleenohjausta enempää ennen kuin se luovuttaa.

Mitä tarkistaa ensin

Kun jokin rikkoutuu tuotannossa, tarkista nämä järjestyksessä:

1. Tilakoodi: Onko se sitä, mitä odotit? 301 on pysyvä, 302 on väliaikainen, 307 säilyttää HTTP-menetelmän. Jos näet väärän koodin, ongelma on uudelleenohjausmäärityksessäsi.

1. Location-otsake: Osoittaako se oikeaan paikkaan? Onko se absoluuttinen URL vai suhteellinen? Suhteelliset URL:t ratkaistaan nykyisen URL:n perusteella, mikä voi tuottaa odottamattomia tuloksia, jos perus-URL ei ole se, minkä luulet sen olevan.

1. Välimuistiotsakkeet: Tallentaako selain uudelleenohjauksen välimuistiin? 301-uudelleenohjaus tallennetaan oletuksena välimuistiin, mikä tarkoittaa, että väärin määritetty uudelleenohjaus voi rikkoa sivustosi tunneiksi vielä senkin jälkeen, kun olet korjannut sen. Tarkista Cache-Control- ja Expires-otsakkeet nähdäksesi, kuinka kauan selain muistaa uudelleenohjauksen.

1. CORS-otsakkeet: Jos pyyntö on eri alkuperään, lähettääkö palvelin oikean Access-Control-Allow-Origin-otsakkeen? Jos ei, selain estää pyynnön, ja näet konsolissa CORS-virheen. Palvelimen vastausotsakkeet ovat ainoa paikka korjata tämä — et voi kiertää sitä selaimessa.

1. Ajoitus: Kuinka kauan pyyntö kesti? Jos se on hidas, onko kyse verkon viiveestä vai palvelimen käsittelystä? Selaimen DevTools ja WebPageTest näyttävät molemmat ajoituserittelyt, jotka kertovat, mihin aika kului.

Syvällisemmän katsauksen siihen, miten selainten käyttäytyminen on muuttunut yksityisyyden ja otsakkeiden ympärillä, löydät artikkelista mikä muuttui evästeissä vuonna 2026 ja mitä sille kannattaa tehdä, joka käsittelee viimeaikaisten selainpäivitysten otsake- ja suostumusvaikutuksia.

Tärkeimmät huomiot

• curl -L -v näyttää koko uudelleenohjausketjun ja kaikki otsakkeet ilman selaimen tulkintaa
• Selaimen Network-välilehti näyttää, mitä selain teki vastauksella, mukaan lukien välimuisti- ja CORS-päätökset
• mitmproxy näyttää, mitä selain lähetti, mukaan lukien otsakkeet, jotka selain lisää automaattisesti
• WebPageTest näyttää, mitä todelliset käyttäjät kokevat, mukaan lukien CDN-käyttäytymisen ja alueelliset erot
• Uudelleenohjaussilmukat ja ristiriitaiset otsakkeet ovat yleisimpiä tuotanto-ongelmia, eivätkä ne näy ilman raa’an HTTP:n tarkastelua

FAQ

Q: Miksi curl näyttää eri otsakkeita kuin selain?

A: Koska selain lisää otsakkeita automaattisesti (User-Agent, Accept, Cookie) ja noudattaa omia sääntöjään välimuistin ja CORSin suhteen. curl lähettää vain sen, mitä käsket sen lähettää. Jos haluat nähdä, mitä selain todella lähettää, käytä mitmproxya tai selaimen DevToolsia.

Q: Miten selvitän uudelleenohjauksen, joka tapahtuu vain joillekin käyttäjille?

A: Tarkista, riippuuko uudelleenohjaus käyttäjän lähettämistä otsakkeista: User-Agent, Accept-Language, Cookie tai IP-osoite (X-Forwarded-Forin kautta). Käytä curlia lähettämään samat otsakkeet kuin käyttäjä lähetti, tai käytä WebPageTestiä ladataksesi sivun käyttäjän sijainnista.

Q: Mitä eroa on 301- ja 302-uudelleenohjauksilla?

A: 301 on pysyvä ja käskee selainta tallentamaan uudelleenohjauksen välimuistiin (joskus ikuisesti). 302 on väliaikainen ja käskee selainta olemaan tallentamatta sitä välimuistiin. Jos et ole varma, kumpaa käyttää, käytä 302:ta — voit aina muuttaa sen myöhemmin 301:ksi.

Q: Miksi uudelleenohjaukseni toimii curlissa mutta ei selaimessa?

A: Todennäköisesti siksi, että selain käyttää välimuistiin tallennettua vanhaa uudelleenohjausta, tai koska selain estää uudelleenohjauksen CORSin tai mixed content -sääntöjen vuoksi. Tarkista selaimen DevTools-konsolista virheet ja Cache-Control-otsakkeista, käyttääkö selain välimuistissa olevaa vastausta.

Q: Miten näen otsakkeet, jotka CDN lisää?

A: Käytä curlia CDN-URL:ään, ja käytä sitten curlia uudelleen suoraan alkuperäpalvelimeen (ohittaen CDN:n). Vertaa otsakkeita. Ne, jotka näkyvät vain ensimmäisessä vastauksessa, tulivat CDN:stä.

<!-- tool-cta:start -->

💡 Kokeile tätä: Kun selvität uudelleenohjausongelmia, Redirect Checker jäljittää koko ketjun ja näyttää tilakoodit ja otsakkeet jokaisessa hypyssä.

<!-- tool-cta:end -->

Lähteet

• curl documentation — Virallinen viite curl-komentorivivalinnoista ja käyttäytymisestä
• HTTPie documentation — Opas httpie-syntaksiin ja ominaisuuksiin
• MDN Web Docs: HTTP redirections — Kattava selitys HTTP-uudelleenohjausten tilakoodeista ja käyttäytymisestä
• WebPageTest documentation — Miten tulkita WebPageTest-tuloksia ja otsakkeita