Проверка на HTTP/HTTPS отговор: Статус код, Верига от пренасочвания, Заглавки на отговора
Въведете URL, за да видите HTTP статус кода, всяка redirect стъпка, крайните response headers и времето за отговор на сървъра. Подходящо за deploy проверки, CDN debugging и redirect одити.
Какво показва тази проверка на HTTP отговор
Страницата тества URL адреса от наш сървър и връща метаданните на отговора, които са важни, когато сайтът е достъпен, но се държи неправилно.
HTTP статус код
Вижте дали крайният отговор е 200 OK, 3xx redirect, 4xx client error или 5xx server failure.
Верига от пренасочвания
Проследете всяка Location стъпка от първия до крайния URL, за да откриете loops, смесени протоколи или грешни canonical правила.
Заглавки на отговора
Прегледайте cache, security, content type, server, CDN и compression headers без browser developer tools.
Време за отговор
Headers показват как сървър, proxy, CDN или браузър трябва да обработи отговора. Тези полета са най-полезни при deploy и availability проверки. Checker-ът се фокусира върху публични HTTP metadata. Не е пълен браузър, Lighthouse audit или authenticated monitoring agent.
Как да проверите HTTP статус, redirects и headers
Използвайте публичния URL, който реално заявяват потребители или ботове. Checker-ът следва redirects безопасно и се фокусира върху headers, статус и timing.
Въведете пълния URL
Поставете HTTP или HTTPS URL с пътя, който искате да тествате. Ако пропуснете протокола, проверката започва с HTTPS.
Изберете HEAD или GET
HEAD проверява headers бързо. GET е полезен, когато сървър, CDN или приложение връща различен статус за нормални page requests.
Прочетете крайния отговор
Прегледайте крайния статус, всички redirect стъпки, response headers и общото време преди промени в DNS, CDN, proxy или приложението.
Чести модели в резултатите и следващи действия
Статус кодовете са групирани по клас. Класът показва дали заявката е успешна, пренасочена, провалена от client страна или от server страна. Redirects често се управляват от няколко слоя едновременно. Използвайте chain-а, за да видите кой слой променя URL и къде започва loop или грешна цел.
| Проблем | Сигнал | Какво да проверите |
|---|---|---|
| 200 OK / Успех | Успех: Checker-ът се фокусира върху публични HTTP metadata. Не е пълен браузър, Lighthouse audit или authenticated monitoring agent. | Content-Type / Cache-Control / Нова проверка |
| 301 / 308 | Подходящо за canonical премествания, но проверете дестинацията преди search engines да консолидират сигналите. | Потвърдете, че сочи към правилната canonical HTTPS, www или non-www дестинация. |
| 401 / 403 | Проверете authentication, IP allowlists, WAF правила, bot protection и CDN access policies. | Използвайте HEAD първо, защото е бърз и не изтегля response body. Използвайте GET, когато server-ът не поддържа HEAD или когато искате по-близко поведение до нормален browser/API request. |
| 429 / 503 | Прегледайте application logs, origin health, upstream timeouts, load balancer rules и CDN origin settings. | Retry-After / Използвайте ги, за да потвърдите, че traffic-ът стига до очакваната инфраструктура. |
| Верига от пренасочвания | Chain-ът редува http:// и https:// или повтаря същия URL. | Потвърдете, че сочи към правилната canonical HTTPS, www или non-www дестинация. |
HEAD или GET: кой метод да използвате?
HEAD е най-бърз, защото чете headers без да изтегля body. Използвайте GET, ако сървърът блокира HEAD заявки.
| Метод | Какво да проверите | Сигнал | Решение |
|---|---|---|---|
| HEAD | Статус код / Верига от пренасочвания / Заглавки на отговора | 405 / Клиентска грешка / Проверката на отговора не успя. Потвърдете, че URL адресът е достъпен, и опитайте пак. | GET: Използвайте HEAD първо, защото е бърз и не изтегля response body. Използвайте GET, когато server-ът не поддържа HEAD или когато искате по-близко поведение до нормален browser/API request. |
| GET | HEAD проверява headers бързо. GET е полезен, когато сървър, CDN или приложение връща различен статус за нормални page requests. | Сървърна грешка / Заявката изтече. Сървърът може да е недостъпен, претоварен, блокиран от firewall или бавен. | HEAD: HEAD е най-бърз, защото чете headers без да изтегля body. Използвайте GET, ако сървърът блокира HEAD заявки. |
Как да четете заглавките на отговора
Headers показват как сървър, proxy, CDN или браузър трябва да обработи отговора. Тези полета са най-полезни при deploy и availability проверки.
| Header | Какво показва | Какво да проверите |
|---|---|---|
| Location | Следващият URL в redirect response като 301, 302, 307 или 308. | Потвърдете, че сочи към правилната canonical HTTPS, www или non-www дестинация. |
| Cache-Control | Как браузъри и CDN могат да кешират отговора и за колко време. | Проверете stale cache правила след deploy или когато потребители виждат старо съдържание. |
| Content-Type | MIME типът, върнат от сървъра, например text/html или application/json. | Проверете дали APIs, feeds, downloads и pages връщат очаквания content type. |
| Strict-Transport-Security | Дали браузърите трябва да принуждават бъдещи заявки към HTTPS за този домейн. | Използвайте го само след като HTTPS е стабилен на всички нужни subdomains. |
| Server / Via / CF-Cache-Status | Сигнали кой origin, proxy, CDN или cache слой е обработил отговора. | Използвайте ги, за да потвърдите, че traffic-ът стига до очакваната инфраструктура. |
| Retry-After | Клиентска грешка / Сървърна грешка | Заявката изтече. Сървърът може да е недостъпен, претоварен, блокиран от firewall или бавен. |
| Content-Encoding | Заглавки на отговора | Проверете stale cache правила след deploy или когато потребители виждат старо съдържание. |
HTTP статус кодове: какво означава резултатът
Статус кодовете са групирани по клас. Класът показва дали заявката е успешна, пренасочена, провалена от client страна или от server страна.
Заявката стигна до работещ endpoint. Проверете content type, cache policy и security headers.
Проверете дали APIs, feeds, downloads и pages връщат очаквания content type.
Подходящо за canonical премествания, но проверете дестинацията преди search engines да консолидират сигналите.
Използвайте го за временно routing. Сменете на 301 или 308, когато преместването е постоянно.
Проверете authentication, IP allowlists, WAF правила, bot protection и CDN access policies.
Поправете счупени вътрешни links, възстановете route-а или redirect-нете към най-близката заместваща страница.
Проверете authentication, IP allowlists, WAF правила, bot protection и CDN access policies.
Прегледайте application logs, origin health, upstream timeouts, load balancer rules и CDN origin settings.
Checklist за redirect troubleshooting
Redirects често се управляват от няколко слоя едновременно. Използвайте chain-а, за да видите кой слой променя URL и къде започва loop или грешна цел.
| Проблем | Сигнал | Решение |
|---|---|---|
| HTTP и HTTPS loop | Chain-ът редува http:// и https:// или повтаря същия URL. | Оставете едно HTTPS redirect правило и махнете конфликтни origin, CDN или load balancer правила. |
| www и non-www конфликт | URL адресът прескача между www.example.com и example.com. | Изберете един canonical host и го приложете еднакво в DNS, web server и application routing. |
| Несъответствие в крайната наклонена черта | Променя се само крайната наклонена черта, но заявката пак redirect-ва повече от веднъж. | Нормализирайте slash правилата в един слой и не ги дублирайте в app и proxy. |
| Geo, auth или bot redirect | Checker-ът вижда login, country, consent или challenge URL вместо публичната страница. | Прегледайте WAF, bot protection, geolocation и authentication rules за външни заявки. |
Какво не доказва отговор 200 OK
Успех: Checker-ът се фокусира върху публични HTTP metadata. Не е пълен браузър, Lighthouse audit или authenticated monitoring agent.
Успех / HTML
Успех: Checker-ът се фокусира върху публични HTTP metadata. Не е пълен браузър, Lighthouse audit или authenticated monitoring agent.
Content-Type
Проверете дали APIs, feeds, downloads и pages връщат очаквания content type.
Cache-Control
Проверете stale cache правила след deploy или когато потребители виждат старо съдържание.
GET / Заявка от браузъра
Използвайте HEAD първо, защото е бърз и не изтегля response body. Използвайте GET, когато server-ът не поддържа HEAD или когато искате по-близко поведение до нормален browser/API request.
Защо резултатът в браузъра може да се различава
Използвайте HEAD първо, защото е бърз и не изтегля response body. Използвайте GET, когато server-ът не поддържа HEAD или когато искате по-близко поведение до нормален browser/API request.
| Проблем | Заявка от браузъра | Проверете отговора на URL |
|---|---|---|
| Cookies / Клиентска грешка | Използвайте HEAD първо, защото е бърз и не изтегля response body. Използвайте GET, когато server-ът не поддържа HEAD или когато искате по-близко поведение до нормален browser/API request. | Проверете authentication, IP allowlists, WAF правила, bot protection и CDN access policies. |
| Cache-Control | Как браузъри и CDN могат да кешират отговора и за колко време. | Проверете stale cache правила след deploy или когато потребители виждат старо съдържание. |
| Location | Следващият URL в redirect response като 301, 302, 307 или 308. | Потвърдете, че сочи към правилната canonical HTTPS, www или non-www дестинация. |
| WAF / 401 / 403 | Unauthorized или forbidden | Проверете authentication, IP allowlists, WAF правила, bot protection и CDN access policies. |
Какво не може да докаже проверката на HTTP отговор
Checker-ът се фокусира върху публични HTTP metadata. Не е пълен браузър, Lighthouse audit или authenticated monitoring agent.
Без private network цели
Localhost, LAN IP адреси, internal hostnames и reserved ranges са блокирани за сигурност.
Без JavaScript rendering
Резултатът е базиран на server response headers, не на client-side content след изпълнение на scripts.
Без login session
Authenticated pages може да върнат 401, 403 или redirects, защото checker-ът не изпраща вашите cookies.
200 OK / Успех
Успех: Checker-ът се фокусира върху публични HTTP metadata. Не е пълен браузър, Lighthouse audit или authenticated monitoring agent.