Пінг

Пінг є безкоштовним інструментом, який перевіряє доступність сайту, сервера або порту та показує час відповіді, код стану чи помилку.

Що саме перевіряє пінг?

Пінг визначає, чи відповідає віддалена система з тієї мережі, де виконується перевірка. Конкретний спосіб залежить від вибраного протоколу.

• HTTP(s) перевіряє вебадресу через HTTP або HTTPS. Цей варіант підходить для сайтів, API та вебсервісів, оскільки може повертати код стану HTTP-відповіді.
• Пінг (ICMP) перевіряє, чи відповідає хост на ехо-запити протоколу керуючих повідомлень Інтернету. Саме це зазвичай мають на увазі під мережевим "пінгом".
• Хост / Порт перевіряє, чи доступний указаний мережевий порт на хості. Типові приклади: поштовий сервер SMTP, сервер POP або кінцева точка бази даних.

Ці перевірки відповідають на дещо різні запитання. Відповідь ICMP свідчить, що хост приймає та обробляє мережевий трафік цього типу, але не доводить, що його сайт або поштовий сервіс працює. HTTP-відповідь містить код стану, який може вказувати на несправність. Успішна перевірка порту означає, що порт доступний, але не гарантує успішного входу в застосунок або виконання запиту до бази даних.

Як користуватися інструментом Пінг?

Вибери потрібний Протокол пінгу, введи відповідну адресу та запусти перевірку. Формат введення має відповідати вибраному протоколу.

1. Вибери HTTP(s) і введи повну URL-адресу, наприклад https://www.example.com/status, якщо перевіряєш сайт, кінцеву точку API або вебсервіс.
2. Вибери Пінг (ICMP) і введи Хост, наприклад server.example.com або IP-адресу, щоб перевірити, чи відповідає сервер на ICMP-трафік.
3. Вибери Хост / Порт, введи Хост, а потім числове значення в полі Порт. Наприклад, сервіс надсилання пошти через SMTP зазвичай використовує порт 587, а HTTPS, порт 443.

Не додавай шлях URL під час перевірки, яка приймає лише хост. Натомість для перевірки HTTP може знадобитися повний шлях, якщо проблема стосується окремого маршруту API або сторінки, а не всього домену. Номери транспортних портів є 16-бітними значеннями в діапазоні від 0 до 65 535. Порт 0 зарезервований і зазвичай не використовується як порт сервісу. Пробіли, коми та позначення на кшталт "порт 443" не є частиною номера порту.

Перевірка виконується на сервері. Введені в Пінг дані передаються на цей сервер через HTTPS і не зберігаються. Не додавай до URL паролі, ключі API чи інші секретні дані, оскільки URL може розкрити їх віддаленому сервісу та іншим складникам звичайної вебінфраструктури.

Як читати результат пінгу?

Спочатку перевір доступність, а потім використовуй час відповіді, код стану HTTP або відомості про помилку, щоб точніше визначити проблему.

Наприклад, умовний результат HTTP-перевірки може містити статус Онлайн, час відповіді 180 мс і код стану 200. Код 200 означає, що запит виконано успішно. Відповідь 404 означає, що вихідний сервер не знайшов актуального представлення цільового ресурсу або не бажає повідомляти про його існування. Відповідь 5xx (помилка сервера) належить до класу помилок сервера, а точна причина залежить від конкретного коду стану.

Результат Офлайн не завжди означає, що весь комп'ютер або сервер перебуває поза мережею. Брандмауер може блокувати ICMP, тоді як HTTPS і далі працює. Так само один порт може бути закритий, хоча інші сервіси залишаються доступними. Вибирай перевірку відповідно до сервісу, до якого намагаються підключитися користувачі.

Які типові проблеми виявляє пінг?

Якщо сайт не завантажується, почни з HTTP(s) і введи точну URL-адресу проблемної сторінки. Якщо домен відповідає, але окрема сторінка повертає 404, перевір маршрут, правила переписування адрес або розгортання. Якщо браузер показує попередження про сертифікат HTTPS, скористайся інструментом Перевірка SSL, щоб переглянути відомості про сертифікат, а не покладайся лише на пінг. Перегляд HTTP заголовків також може показати переспрямування та заголовки відповіді.

Якщо електронні листи не надходять, вибери Хост / Порт, введи ім'я хоста поштового сервера та порт, налаштований у застосунку для надсилання або отримання пошти. Доступність порту SMTP не доводить, що сервер прийме конкретне повідомлення. Помилки автентифікації, фільтрація спаму, поштові записи DNS і правила одержувача виходять за межі базової перевірки порту.

Після перенесення сайту на новий хост перевір його ім'я хоста через ICMP або HTTP, залежно від ситуації. Перевір запис DNS і врахуй, що кешовані відповіді можуть зберігатися певний час. Whois пошук може допомогти підтвердити реєстраційні відомості домену, але не показує, яку саме DNS-відповідь наразі зберігає кожен резолвер.

Чому через кеш DNS правильний результат може здаватися помилковим?

Через кешування DNS сервер інструмента й твій пристрій можуть деякий час перетворювати те саме ім'я хоста на різні адреси. Рекурсивні резолвери зберігають DNS-відповіді відповідно до часу їхнього життя, який часто називають TTL. Деякі застосунки та операційні системи також використовують локальні кеші.

Таку затримку часто називають "поширенням", хоча записи DNS не розповсюджуються всюди в межах одного узгодженого процесу. Термін зберігання кожного кешу завершується за власним розкладом. Тому нещодавно змінений запис може вже працювати через одне підключення, тоді як інше ще використовуватиме попередню адресу.

Оскільки перевірка виконується на сервері інструмента, результат відображає мережевий маршрут і дані DNS, доступні цьому серверу на момент запиту. Він не може довести, що кожен інтернет-провайдер, оператор мобільного зв'язку чи корпоративний резолвер бачить ту саму адресу призначення. Якщо важлива поведінка в конкретному місці, порівняй результат із локальною перевіркою та надішли запити до відповідних записів DNS.

Поширені запитання

Що буде з доменами, які містять літери з діакритикою або символи не з латиниці?

IDNA перетворює допустимі Unicode-мітки домену на ASCII-мітки A-label. Punycode є алгоритмом кодування, який використовується у відповідних A-label. Браузери часто автоматично перетворюють читабельне написання, але поля для хоста й діагностичні системи можуть вимагати форму A-label. Уважно перевіряй написання, оскільки візуально схожі символи Unicode можуть позначати різні домени.

Чи залишатиметься низький час відповіді таким завжди?

Ні. Час відповіді залежить від маршрутизації, завантаженості мережі та сервера, а також фізичної відстані. Виконай кілька перевірок у зіставний час і досліджуй стійкі зміни, а не вважай одну повільну відповідь доказом несправності.

Перш ніж змінювати налаштування DNS, брандмауера або сервера, переконайся, що перевірено точне ім'я хоста, шлях URL і порт, які використовує проблемний сервіс. Збережи час отримання результату та порівняй його з локальними журналами, щоб зіставити дані з обох боків з'єднання.