Сервер проверить: Проверка ответа сервера — бесплатная проверка HTTP-заголовков сервера

Проверка кода ответа страницы сервера

Чек-лист проверки доступности сервера | firstvds.ru

Если ваш сайт не открывается или подключиться к серверу не удается, то это не всегда означает, что VDS полностью недоступен. В некоторых случаях это может быть связано с ошибками работы лишь части функционала виртуального сервера, которые по силам исправить самостоятельно.

Чтобы вы могли проверить, действительно ли недоступен сервер, мы подготовили чек-лист.

1. Проверяем, есть ли пинг

Для этого запустите терминал командной строки (Если ваш ПК на Windows, запустить ее можно так: Пуск — Выполнить — cmd — ОК ) и в открывшемся окне наберите:
ping ваш.домен  или  ping ваш_IP-адрес. 

Если по результату выполнения в пункте Lost будет 0 (или 0% Loss) или в русском варианте — потеряно 0, как выделено на скриншоте ниже, то сервер доступен:

2. Исключаем проблему с DNS

Все дальнейшие манипуляции по проверке доступности необходимо проводить не по имени домена, а по IP-адресу вашего VDS. IP-адрес можно посмотреть в письме об открытии услуги или в Личном кабинете — вкладка Виртуальные серверы. Скопируйте IP в адресную строку браузера, как если бы вы открывали сайт. Если по IP есть какой-либо доступ к серверу, но такого же доступа нет по имени домена, то проблема, возможно, в DNS, но главное — сервер доступен.

3. Исключаем проблему не запущенного http-сервера, закрытых портов, протоколов

Если пинг по IP не проходит, но работает хотя бы один из вариантов:

• панель управления (ISPmanager) открывается;
• есть доступ по SSH;
• есть доступ по FTP;

значит потеряны не все возможные доступы на сервер, то есть, в целом, сервер доступен.

4. Исключаем проблему местного интернет-провайдера, отдельного устройства или роутера.

Первый способ. Вы просите знакомого, который находится в другой точке, проверить доступ к серверу, или сами заходите с другого устройства через другого провайдера интернета. Если в этом случае доступ на сервер есть, то проблема, возможно, в вашем подключении к интернету, но главное — сервер доступен.

Второй способ. Если другой точки проверки у вас под рукой нет, то можно воспользоваться сервисом https://ping-admin.ru/free_test/ — бесплатная проверка доступности сайта из различных частей мира. Таким образом можно проверить, пингуется ли IP VDS с разных точек мира. Если с большинства точек пинг есть — сервер доступен.

Примечание: если у вас VDS на ОС Windows Server, велика вероятность, что пинга не будет. Это распространенный случай — таковы стандартые настройки системы. Поэтому для Windows не рекомендуем использовать способ проверки через пинг-сервисы.

5. Исключаем ограничение доступа со стороны хостинг-провайдера, низкий баланс или аварию

Для этого необходимо проверить баланс лицевого счёта, статус VDS в личном кабинете в разделе Товары — Виртуальные серверы и уведомления от нас в разделе Поддержка — Запросы и Поддержка — Уведомления.

6. Исключаем сетевую недоступность

Часто, изменение сетевых настроек или правил фаервола может привести к недоступности сервера по сети. Но он по-прежнему будет доступен для управления.

Для OpenVZ

Если сервер запущен, но не работает сеть, в большинстве случаев зайти на сервер получится только специалистам службы поддержки. Однако, если у вас в панели VMManager есть кнопка SSH (см. скриншот), то при клике на неё откроется консоль сервера. Это будет означать, что виртуальный сервер запущен, но недоступен по сети. 

Для KVM

В отличие от программной виртуализации у администратора VDS есть доступ к «монитору» VDS, в панели VMmanager (в Личном кабинете в разделе Товары — Виртуальные серверы — выбрать сервер и нажать сверху Перейти) в разделе Управление — Виртуальные машины — выбрать машину и нажать сверху VNC:

После этого, если откроется консоль сервера (см. скриншот ниже), попробуйте авторизоваться, точно так же, как если бы вы подключались по SSH.

Если авторизация прошла успешно, значит сервер работает, но недоступен по сети.

Если по всем пунктам доступ к серверу так и не получен, это значит только одно — самостоятельно восстановить его работу вам не удастся. Обратитесь в службу поддержки за помощью.

онлайн-проверка работоспособности, анонимности и скорости proxy-серверов онлайн, экспорт ip-port — hidemy.name

У нас высокая скорость проверки в 64 потока и умные алгоритмы распознавания прокси в списках.
Мы проверяем прокси по множеству параметров, включая пинг, скорость соединения и степень анонимности.
Выдаём потоковые результаты с гибкой настройкой и экспортируем только необходимую вам информацию.

Наш прокси-чекер может бесплатно проверить прокси на работоспособность. Помимо этого, он определяет тип прокси, страну, город, скорость и степень анонимности. Подробнее про степень анонимности и типы прокси вы можете прочитать на странице прокси-листа.

Умный алгоритм умеет распознавать и проверять любой формат прокси. Например, если вы скопировали прокси-лист с какого-то сайта не в классическом формате ip:port, а разделенный tab, пробелом или как-то ещё, чекер сможет отсеять лишнее и успешно запустить проверку.

Вы даже можете вписать в строку проверки ссылку на другой сайт! Наш робот-паук загрузит эту страницу, попытается распознать там прокси, и сразу же начнет их проверку. Адрес страницы должен быть один и начинаться на http:// или https://

Вот что ещё умеет наш прокси-чекер:

• Выгружать проверенные прокси в текстовом формате IP:Port, либо таблицей в .csv формате.
• Увеличивать скорость проверки прокси с помощью многопоточности. Для бесплатной проверки доступно 20 потоков, для обладателей платной подписки до 64 потоков.
• Один прокси проверяется около 30 секунд. В бесплатной версии доступно 20 одновременных поток проверки. В платной версии 64 потока проверки прокси.
• За один раз можно проверить 100 прокси. Если вы планируете регулярно проверять большое количество прокси-серверов, авторизуйтесь своим кодом доступа и проверяйте без лимитов.
• Параметр «таблица результатов» показывает процесс проверки и её результаты в режиме реального времени.
• При проверке большого листа можно снять галочку «нерабочие» и не выводить лишние строки.

Для чекера прокси есть API. Вы можете встроить проверку прокси в свою программу или на сайт. Условия по запросу.

Как вовремя узнать, что ваш сервер не работает? / Хабр

Случается, что сайты перестают работать. Причины могут быть самые разные: в датацентре «упал» канал, сервер вырубился, кто-то что-то намудрил с базой или файлами на сервере, сисадмин неудачно обновил ПО или переносил аккаунты. Или кое-кто забыл оплатить хостинг.

В большинстве случаев такая ситуация нежелательна, а устранить ее надо как можно скорее. Для этого нужно как можно скорее узнать о случившемся. Но как? Для себя и для наших клиентов мы используем сервисы мониторинга сайтов. О них я сегодня и расскажу.

Как это работает

Принцип прост: где-то постоянно работает программа, которая периодически обращается к вашему серверу и проверяет его работу. Если что-то не так, программа оповещает вас по электронной почте или даже по SMS.

В простейшем случае программа проверяет, доступен ли сервер. Но ведь может случиться и так, что сервер доступен, а вместо главной страницы вашего интернет-магазина пользователи видят позорное «хостинг не оплачен» или «аккаунт заблокирован».

Правильные сервисы мониторинга позволяют отследить и такую ситуацию. Они могут проверять страницы сайта на наличие определенных меток. Такой меткой может быть фрагмент верстки или HTML-комментарий.

Совсем продвинутые сервисы позволяют проверять даже валидность ssl-сертификата.

По итогам недели или месяца сервис может прислать отчет. Тут-то вы и проверите заявления вашего хостера про uptime серверов.

Можно ли сделать такую штуку самому?

Конечно, можно и самому «замутить» такой скрипт, это несложно. Но у сервисов есть важное преимущество: во-первых, все вопросы с программированием, тестированием и поддержкой уже решены.

Во-вторых, если ваш скрипт физически будет расположен на одном сервере, то его работоспособность будет зависеть от работоспособности этого сервера. У специализированных сервисов таких серверов десятки.

Сколько это стоит

Базовые функции предоставляются бесплатно. За умеренную плату можно получить SMS-уведомления

Чем пользуемся мы

Basicstate.com

Этот сервис сначала пытается отрезолвить адрес сайта по DNS, затем — установить HTTP-соединение, отправляет HTTP-запрос. Потом анализирует код ответа и пытается получить страницу. Проверка — каждые 15 минут.

Сбои на разных этапах будут засчитаны как ошибки разного типа. Таким образом, можно локализовать проблему. И очень полезно в ситуациях, когда из подсети хостера «все работает», а извне — недоступно.

Сервис позволяет «повесить» на один аккаунт неограниченное количество сайтов.

Интересная фишка — множественные уведомления. Например, сразу при обнаружении проблемы сервис может записать в отчет, если сайт не работает и через 15 минут (бывает, что это просто сервер перезагружался) — уведомит вас по email и SMS, а если и через час все плохо, может и в саппорт хостеру написать.

Host-tracker.com

Большой и довольной продвинутый сервис, кстати, с русскоязычной версией. Уведомления может отправить и по ICQ, и в Gtalk (другие jabber’ы я не пробовал).

Проверка на бесплатном аккаунте — каждые 30 минут. Пишут, что у них 45 точек мониторинга. В начальный платный тариф входит проверка наличия ключевого слова на странице. Это может пригодиться, если вы хотите мониторить какой-то сервис. Пишете скрипт, который при вызове проверит работоспособность и выведет нужное слово на страницу по специальному адресу, сервис будет периодически обращаться по этому адресу и отслеживать ключевое слово.

В заключение

В общем, коллеги, предлагаю добавить подключение к сервису мониторинга сайтов в ваши стандарты обслуживания клиентов.

Проверка ответа сервера, HTTP-заголовки сервера

Список заголовков HTTP

Список кодов состояния HTTP

Код состояния HTTP (англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With (введён Microsoft) и 509 Bandwidth Limit Exceeded (введён в cPanel).

Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода. В настоящее время выделено пять классов кодов состояния.

Веб-сервер Microsoft Internet Information Services в своих файлах журналов кроме стандартных кодов состояния использует подкоды записывая их через точку после основного. При этом в ответах от сервера данный субкод не размещается — он нужен администратору сервера чтобы тот мог более точно определять источники проблем. Со списком подкодов IIS можно ознакомиться в документе «Коды состояния служб IIS» в Базе знаний Microsoft.

1xx: Informational (Информационные)

В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.

100 Continue (Продолжать) — Сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

101 Switching Protocols (Переключение протоколов) — Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.

102 Processing (Идёт обработка) — Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

105 Name Not Resolved (Не удается преобразовать DNS-адрес сервера) — При разрешении доменного имени возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.

2xx: Success (Успешно)

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

200 OK (Хорошо) — Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

201 Created (Создано) — В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.

202 Accepted (Принято) — Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

203 Non-Authoritative Information (Информация не авторитетна) — Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.

204 No Content (Нет содержимого) — Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

205 Reset Content (Сбросить содержимое) — Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

206 Partial Content (Частичное содержимое) — Сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1.

207 Multi-Status (Многостатусный) — Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

226 IM Used (Использовано IM) — Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

3xx: Redirection (Перенаправление)

Коды класса 3xx сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (жарг. редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

По последним стандартам клиент может производить перенаправление автоматически (без запроса пользователя) только если второй ресурс будет запрашиваться методом GET или HEAD. В предыдущих спецификациях говорилось что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления. При всех перенаправлениях если метод был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом чтобы в случае чего пользователь смог сам произвести переход.

Разработчики HTTP отмечают что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу несмотря на то, что к первому запрос был с иным методом. Чтобы избежать недоразумений в версии HTTP/1.1 были введены коды 303 и 307 вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

300 Multiple Choices (Несколько вариантов выбора) — По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

301 Moved Permanently (Перемещено навсегда) — Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

302 Moved Temporarily / Found (Перемещено временно / Найдено) — Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

303 See Other (Смотреть другое) — Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.

304 Not Modified (Не изменялось) — Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.

305 Use Proxy (Использовать прокси) — Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.

306 (Зарезервировано, код использовался только в ранних спецификациях) — Использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).

307 Temporary Redirect (Временное перенаправление) — Запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

4xx: Client Error (Ошибка клиента)

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

400 Bad Request (Плохой запрос) — Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

401 Unauthorized (Неавторизован) — Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.

402 Payment Required (Необходима оплата) — Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403 Forbidden (Запрещено) — Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

404 Not Found (Не найдено) — Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

405 Method Not Allowed (Метод не поддерживается) — Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.

406 Not Acceptable (Неприемлемо) — Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.

407 Proxy Authentication Required (Необходима прокси авторизация) — Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.

408 Request Timeout (Истекло время ожидания) — Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

409 Conflict (Конфликт) — Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.

410 Gone (Удалён) — Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.

411 Length Required (Необходима длина) — Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.

412 Precondition Failed (Условие ложно) — Возвращается, если ни одно из условных полей заголовка запроса не было выполнено. Появился в HTTP/1.1.

413 Request Entity Too Large (Размер запроса слишком велик) — Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

414 Request-URI Too Large (Запрашиваемый URI слишком длинный) — Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.

415 Unsupported Media Type (Неподдерживаемый тип данных) — По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим) — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges. Введено в RFC 2616 (обновление HTTP/1.1).

417 Expectation Failed (Ожидаемое неприемлемо) — По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

418 I’m a teapot (Я — чайник) — Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами.

422 Unprocessable Entity (Необрабатываемый экземпляр) — Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.

423 Locked (Заблокировано) — Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

424 Failed Dependency (Невыполненная зависимость) — Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.

425 Unordered Collection (Неупорядоченный набор) — используется в расширении WebDAV Advanced Collections Protocol. Посылается, если клиент указал номер элемента в неупорядоченном списке, или запросил несколько элементов в порядке, отличающемся от серверного.

426 Upgrade Required (Необходимо обновление) — Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.

428 Precondition Required (Необходимо предусловие) — Сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.

429 Too Many Requests (Слишком много запросов) — Клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.

431 Request Header Fields Too Large (Поля заголовка запроса слишком большие) — Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.

434 Requested host unavailable. (Запрашиваемый адрес недоступен) — Запрашиваемый адрес недоступен.

449 Retry With (Повторить с) — Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

451 Unavailable For Legal Reasons (Недоступно по юридическим причинам) — Доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту».

456 Unrecoverable Error (Некорректируемая ошибка) — Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV.

499 () — Используется Nginx, когда клиент закрывает соединение до получения ответа.

5xx: Server Error (Ошибка сервера)

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

500 Internal Server Error (Внутренняя ошибка сервера) — Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.

501 Not Implemented (Не реализовано) — Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

502 Bad Gateway (Плохой, ошибочный шлюз) — Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.

503 Service Unavailable (Сервис недоступен) — Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.

504 Gateway Timeout (Шлюз не отвечает) — Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505 HTTP Version Not Supported (Версия HTTP не поддерживается) — Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.

506 Variant Also Negotiates (Вариант тоже проводит согласование) — В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507 Insufficient Storage (Переполнение хранилища) — Не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.

508 Loop Detected (Обнаружена петля) —

509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала) — Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.

510 Not Extended (Нет расширения) — На сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

511 Network Authentication Required (Требуется сетевая аутентификация) — Этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.

Проверка доступности сайта online (PING)

Доступность сайта проверяется с помощью 4-х попыток подключения к Вашему веб-серверу (аналог ping-запросов) с разных серверов.

Вы можете проанализировать время отклика сайта, качество интернет-соединения (по количеству потерянных пакетов).

Другие проверки
Выберите чтобы перейти к проверке————————————————————Комплексная проверка сайта————————————————————Проверка доступности сайта PINGПроверка загрузки страницы HTTP/HTTPSПроверка ответа от DNSПроверка доменаПроверка сертификатаПроверка сайта на вирусыПроверка доступности FTPПроверка произвольного порта

Эти данные будут собраны онлайн со всех серверов, которые Вы отметили для проверки.

Для того, чтобы статистика о Вашем ресурсе собиралась постоянно — запустите постоянный мониторинг

ЗАПУСТИТЬ ПОСТОЯННЫЙ МОНИТОРИНГ БЕСПЛАТНО!

Для новых пользователей бесплатный мониторинг одного сайта — 15 дней!

Описание PING

Ping — это утилита для проверки целостности и качества соединений в сетях на основе TCP/IP.

Функционал этой утилиты заключается в отправке запросов по протоколу ICMP указанному узлу сети и получении ответов.
После получения ответа, утилита подсчитывает время между отправкой запроса и получением ответа — RTT (Round Trip Time).
Это позволяет определять задержку передачи данных по маршруту и частоту потери пакетов.
По этим данным можно определить загруженность на каналах передачи данных и промежуточных устройствах, их пропускную способность,
качество интернет-соединения.

ICMP (Internet Control Message Protocol) — это сетевой протокол, входящий в стек протоколов TCP/IP.
В основном ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных
(например: запрашиваемая услуга недоступна, хост или маршрутизатор не отвечает).

Проверка сети

При диагностике сети в первую очередь происходит оценка запросов Ping, которые определяют целостность и качество соединения на предмет потери пакетов.

Обычный ping-запрос имеет длину 64 байта (+ 20 байт IP-заголовка). По стандарту RFC 791 IPv4 суммарный объём пакета не может превышать 65 535 байт.

Возможные причины отсутствия ответов PING

Основная причина отсутствия ответов утилиты PING заключается в неработоспособности сервера, либо его очень большой загрузкой.

Постоянное отсутствие ICMP-ответов может также означать, что удалённый узел (или какой-либо из промежуточных узлов) блокирует ICMP-запрос или ICMP-ответ.

Основные причины необходимости PING-проверок:

Проверка сервера

Необходимо всегда быть уверенным в том, что сервер работает, не завис, имеет доступ в интернет.

Доступность сайта

Проверка работы веб-сервиса на сервере, доступность сайта из разных точек

Проверка PING — основной метод мониторинга сервера

Перед запуском постоянного ежеминутного мониторинга, попробуйте проверить сайт
— это основные проверки онлайн (
проверить ответ сервера,
проверить DNS,
проверить домен,
проверить сертификат
проверить сайт на вирусы
).

10 онлайн-инструментов для проверки SSL, TLS и последних уязвимостей

От переводчика.

Привет! В последнее время было обнаружено довольно много уязвимостей, связанных с SSL, поэтому мне захотелось сделать перевод статьи, в которой собран список инструментов для тестирования SSL, TLS и различных уязвимостей. В статье довольно много терминов, поэтому хочу извиниться, если что-то перевела не совсем корректно. Если вы можете предложить лучший вариант перевода, пожалуйста, напишите в личные сообщения.

Проверяйте SSL, TLS и шифрование

Проверка SSL необходима для обеспечения правильного отображения параметров сертификата. Существует множество способов проверки SSL-сертификатов. Проверка с помощью инструментов в сети позволяет получить полезную информацию, находящуюся ниже. Она также поможет вам выявить угрозы на ранних стадиях, а не после получения жалобы клиента.

Я получил ряд вопросов после своей последней публикации «Усиление защиты Apache. Гид по безопасности» о проверке TLS и SSL. В этой статье я расскажу вам о некоторых полезных инструментах для проверки SSL-сертификатов в сети.

Symantec SSL Toolbox

Проверка CSR — очень важно проверить CSR перед отправкой для подписи запроса. Вы сможете удостовериться в том, что CSR содержит все требуемые параметры, например, CN, DN, O, OU, алгоритм и др.

Проверка установки сертификата — после установки всегда полезно удостовериться в том, что сертификат действителен и содержит необходимую информацию. Этот онлайн инструмент позволит вам проверить CN, SAN, название организации, OU, город, серийный номер, тип применяемого алгоритма, длину ключа и подробности о цепочке сертификата.

Wormly Web Server Tester

Тестирование web сервера от Wormly позволяет получить подробный обзор параметров ссылки. Обзор включает в себя данные о сертификате (CN, срок действия, цепочка сертификата), шифровании, длине открытого ключа, безопасности повторного согласования, протоколах типа SSLv3/v2, TLSv1/1.2.

DigiCert SSL Certificate Checker

Инструмент для проверки установки SSL сертификатов от DigiCert — еще один прекрасный инструмент, который позволит вам преобразовать DNS в IP адрес, узнать кто выдал сертификат, его серийный номер, длину ключа, алгоритм подписи, SSL-шифрование, поддерживаемое сервером и срок действия сертификата.

SSL Shopper

Проверка SSL от SSL Shopper — подойдет для быстрой проверки типа сервера, срока действия, SAN и цепочки доверия. Вы сможете оперативно найти ошибку в цепочке сертификата или узнать, что он не работает должным образом. Инструмент отлично подходит для устранения неполадок в работе.

GlobalSign SSL Check

Проверка конфигурации SSL от GlobalSign предоставляет очень подробную информацию о веб-сервере и SSL. Инструмент ставит баллы в зависимости от данных сертификата, поддержки протоколов, обмена ключами и надёжности шифра. Это незаменимый инструмент при настройке нового безопасного URL или проведении аудита. Обязательно попробуйте!

Qualys SSL Labs

Позволяет оценить ваш сайт в отношении безопасности SSL-сертификата. Предоставляет очень подробную техническую информацию. Советую системным администраторам, аудиторам, инженерам по интернет-безопасности для выявления и наладки “слабых” параметров.

Free SSL Server Test

Производит проверку вашей https ссылки и отображает следующую информацию, которую при желании можно скачать в PDF-формате:

• Совместимость PCI DSS
• Соответствие принципам NIST
• Размер DH
• Поддержка протоколов
• Поддержка шифров
• Откат TLS соединения
• Поддержка повторного согласования
• Основные наборы шифров
• Контент третьих лиц

COMODO SSL Analyzer

SSL анализатор от COMODO позволяет провести анализ https URL и быстро получить отчеты по различным параметрам, включая

• Серийный номер
• Отпечаток
• Действительность SSL-сертификата
• Эмитент
• Поддержка протокола (SSL/TLS)
• Защита от атак Downgrade
• Безопасность повторного согласования (по инициативе сервиса или клиента)
• Сжатие
• Session tickets
• Активные наборы шифрования

SSL Checker

Что действительно хорошо в SSL Checker, так это то, что инструмент позволяет настроить напоминание (за 30 дней) об истечении срока действия сертификата. Это отлично, мне кажется, что бесплатно эту услугу больше нигде получить нельзя. Кроме того, инструмент позволяет выполнить базовую проверку таких параметров, как:

• Цепочка сертификата
• Корневой сертификат
• Алгоритм подписи
• Отпечаток
• Элементы цепочки
• SAN

HowsMySSL

Этот инструмент отличается от остальных. Он позволяет проверить клиента (браузер) и получить оценку состояния по следующим параметрам:

• Поддерживаемая версия протокола
• Сжатие
• Поддержка session ticket
• Поддерживаемое шифрование

Для проверки клиента, просто зайдите на HowsMySSL в браузере.

Другие инструменты онлайн-проверки

Проверка уязвимости POODLE:
Проверка уязвимости FREAK:
Проверка уязвимости LogJam:
Проверка уязвимости SHA-1:
Я считаю, что перечислил все бесплатные онлайн-инструменты для проверки параметров SSL-сертификата и получения достоверной технической информации для проведения аудита и обеспечения безопасности веб-приложений. Если вам понравилось, поделитесь с друзьями.

P. S. Приглашаем в наше Хостинг Кафе. Работают и активно развиваются 6 сайтов для поиска хостинговых услуг:

• VDS.menu — Поиск виртуальных серверов
• SHARED.menu — поиск виртуального хостинга
• DEDICATED.menu — поиск выделенных серверов
• HTTPS.menu — поиск SSL сертификатов
• LICENSE.menu — поиск лицензий
• BACKUP.menu — поиск места для резервных копий

Спасибо andorro за помощь с подготовкой публикации.

О нас | Server Check.in

Узнайте, когда ваш сервер не работает.

• 15 долларов в год за 5 серверов, 48 долларов в год за 25.
• Проверяет каждую минуту.
• Уведомления по электронной почте и SMS, когда ваш сервер не работает.
• Монитор с проверками ping, HTTP и содержимого.
• Отслеживайте задержку сервера (время ответа) во времени.

Зарегистрироваться

… или просмотрите планы и цены

Server Check.in — это простой сервис мониторинга работоспособности и производительности веб-сайта.Всего за 15 долларов в год (всего 1,25 доллара за долларов в месяц!) Вы можете быть спокойны, зная, когда ваши веб-сайты и серверы в сети, а когда не работают. Мы отправим вам текстовое сообщение и / или электронное письмо, когда ваш сервер выйдет из строя, а также будем отслеживать и отображать производительность вашего сервера с течением времени.

Мы также предоставляем некоторые инструменты, которые помогут вам убедиться, что ваши сайты и серверы находятся в сети и работают хорошо (например, наш инструмент «Проверка веб-сайта или сервера»), даже если у вас нет учетной записи.

Скриншоты

Ваша домашняя страница с кратким обзором состояния ваших серверов:

Щелкните сервер, чтобы просмотреть сведения о задержке и отключении:

Серверы

можно проверить простым эхо-запросом на IP-адрес, проверкой статуса «200 OK» для веб-страницы или проверкой конкретной разметки на веб-странице.Вы также можете установить разные настройки уведомлений для каждого сервера:

Подробнее

• Server Check.in отправляет SMS-сообщения с реального номера телефона — мы не используем шлюз электронной почты в текст. (Примечание: SMS-сообщения работают со многими операторами связи по всему миру (и почти со всеми в США и Канаде). Уточните у нас, используете ли вы номер телефона за пределами США, чтобы убедиться, что наша служба SMS поддерживается в вашем регионе.)
• Когда ваш сайт не работает, мы дважды проверяем, чтобы убедиться, что это не случайная ошибка.Это избавит вас от получения уведомлений, когда ваш сайт на самом деле не работает.
• Наш мониторинг задержки может помочь вам определить, когда ваш сервер работает или становится медленнее со временем.

Follow Server Check.in

.Средство проверки кодов состояния HTTP

~ Средство проверки кода ответа заголовка сервера

Инструменты SEO

Инструменты, которые помогут вам создать и продвигать свой веб-сайт.

Расширения Firefox

Веб-инструменты

Если вам нужна обратная связь или у вас есть какие-либо животрепещущие вопросы, задавайте их на форуме сообщества, чтобы мы могли их решить.

Обзор

Обзор содержания сайта.Включает карту сайта, глоссарий и контрольный список для быстрого старта.

SEO

Содержит информацию о ключевых словах, SEO на странице, построении ссылок и социальном взаимодействии.

КПП

Советы по покупке трафика в поисковых системах.

Отслеживание

Узнайте, как отслеживать свой успех с помощью обычных объявлений SEO и PPC. Включает информацию о веб-аналитике.

Доверие

Создание заслуживающего доверия веб-сайта — это основа того, чтобы быть достойным ссылок и продавать клиентам.

Монетизация

Узнайте, как зарабатывать деньги на своих веб-сайтах.

Аудио и видео

Ссылки на полезную аудио и видео информацию. Мы будем создавать новые SEO-видео каждый месяц.

Интервью

Эксклюзивные интервью только для участников.

Скидки

купонов и предложений, которые помогут вам сэкономить деньги на продвижении ваших сайтов.

Карта сайта

Просмотрите все наши учебные модули, на которые есть ссылки на одной странице.

См. Также:

Получите конкурентное преимущество сегодня

Ваши ведущие конкуренты годами инвестируют в свою маркетинговую стратегию.

Теперь вы можете точно знать, где они ранжируются, выбирать лучшие ключевые слова и отслеживать новые возможности по мере их появления.

Изучите рейтинг своих конкурентов в Google и Bing сегодня с помощью SEMrush.

Введите конкурирующий URL-адрес ниже, чтобы быстро получить бесплатный доступ к их истории эффективности обычного и платного поиска.

Посмотрите, где они занимают место, и побейте их!

• Исчерпывающие данные о конкуренции: исследований эффективности в обычном поиске, AdWords, объявлениях Bing, видео, медийной рекламе и многом другом.
• Сравните по каналам: используйте чью-то стратегию AdWords, чтобы стимулировать рост вашего SEO, или используйте их стратегию SEO, чтобы инвестировать в платный поиск.
• Глобальный охват: Отслеживает результаты Google по более чем 120 миллионам ключевых слов на многих языках на 28 рынках.
• Исторические данные о производительности: восходит к прошлому десятилетию, до появления Panda и Penguin, поэтому вы можете искать исторические штрафы и другие потенциальные проблемы с рейтингом.
• Без риска: Бесплатная пробная версия и низкая ежемесячная плата.

Ваши конкуренты, исследуют ваш сайт

Найдите новые возможности сегодня

.

проверяют функциональность, анонимность и скорость прокси-серверов. Онлайн, экспорт ip-порта — hidemy.name

Наш прокси-чекер имеет высокую скорость проверки в 64 потока и интеллектуальные алгоритмы распознавания прокси в списках.
Мы проверяем прокси по множеству параметров, включая пинг, скорость соединения и анонимность.
Результаты потоковой передачи имеют гибкие настройки, поэтому вы можете экспортировать только ту информацию, которая вам нужна.

Наша программа проверки прокси может бесплатно проверить работу прокси.Кроме того, он определяет тип прокси, страну, город, скорость и степень анонимности. Дополнительные сведения о степени анонимности и типах прокси см. В списке прокси.

Умный алгоритм может распознать и проверить любой формат прокси. Например, если вы скопировали список прокси с сайта, который не соответствует классическому формату ip: port, но разделен табуляцией, пробелом или чем-то еще, средство проверки сможет отфильтровать лишнее и запустить проверку. успешно.

Вы даже можете ввести ссылку на другой сайт в строке проверки! Наш робот-паук загрузит эту страницу, попытается распознать там прокси и сразу же начнет их проверять.Адрес страницы должен быть таким же и начинаться с http: // или https: //

Вот что еще может делать наша программа проверки прокси:

• Загрузить проверенные прокси в текстовом формате Ip: Port или таблицу в формате .csv .
• Увеличьте скорость проверки прокси с помощью многопоточности. Для бесплатной проверки доступно 20 потоков, а пользователям с платной подпиской доступно до 64 потоков.
• Один прокси проверяется около 30 секунд. В бесплатной версии доступно 20 потоков одновременной проверки.Платная версия имеет 64 потока проверки прокси.
• Вы можете проверить 100 прокси за раз. Если вы планируете регулярно проверять большое количество прокси-серверов, авторизуйтесь со своим кодом доступа и проверяйте наличие прокси без ограничений.
• Параметр «Таблица результатов» отображает процесс проверки и его результаты в реальном времени.
• При проверке большого листа вы можете снять флажок «нерабочий», чтобы лишние строки не появлялись.

Есть API для проверки прокси.Вы можете встроить проверку прокси в свою программу или на свой сайт. Условия доступны по запросу.

.

Проверка сервера имен с помощью WebSite Pulse [Руководство]

Чтобы ваш веб-сайт был виден в Интернете, ваше доменное имя должно быть указано на серверах имен вашего хостинг-провайдера. Посетители могут получить доступ к вашему веб-сайту, используя ваше доменное имя, а не IP-адреса, благодаря системе доменных имен (DNS).

Как работает DNS?

DNS преобразует доменные имена, понятные людям, в IP-адреса, понятные для компьютеров.Вот объяснение доменных имен и IP-адресов.

Доменное имя

Текстовое имя, которое используется для идентификации веб-сайта или его международного местонахождения, является доменным именем. например redwidgets.com

IP-адреса

Это числа, которые используются для определения местоположения веб-сайта или компьютера, подключенного к Интернету. IP-адрес позволяет компьютерам связываться друг с другом и с веб-серверами. Пример числового формата IP-адреса — 219.44,42,79.

DNS преобразует идентификатор местоположения или доменное имя, вводимое пользователем, в IP-адрес местоположения в Интернете или связанного веб-сайта. Используя DNS, пользователи могут легко запоминать машиночитаемые интернет-адреса и текстовые домены.

Как DNS определяет используемый сервер?

Информация о любом доменном имени хранится в файле зоны. На серверах имен хранится набор файлов зон. Когда пользователь ищет доменное имя, сервер просматривает файл зоны, чтобы определить сервер имен, содержащий доменное имя.Чтобы доменное имя было найдено или доступно в Интернете, оно должно указывать на сервер имен, у которого есть свой конкретный файл зоны.

Какой сервер имен мне использовать?

После того, как вы зарегистрировали доменное имя в компании по регистрации доменов, вы должны указать его на серверы имен, предоставленные вашей хостинговой компанией. Если вы регистрируете свой домен у регистранта, отличного от вашей хостинговой компании, вам придется изменить серверы имен для доменного имени, чтобы оно распространялось в Интернете.

Иногда ваш веб-сайт может быть недоступен в Интернете из-за неправильной настройки серверов имен. Вы можете использовать WebsitePulse Test Tool не только для проверки серверов имен, но и для проверки состояния вашего веб-сайта, службы и сети.

Чтобы выполнить проверку сервера имен, просто зайдите на сайт www.websitepulse.com/tools и щелкните вкладку «DNS». Затем введите свое доменное имя или IP-адрес в поле вкладки и нажмите «выполнить тест». Инструмент выполнит поиск в DNS и получит информацию о вашем домене.Вы можете использовать этот инструмент, чтобы проверить, верны ли записи DNS и связан ли ваш конкретный домен с правильным IP-адресом.

Помимо проверки сервера имен хостов, вы также можете проверить следующее: поиск MX, поиск записи NS, обратный DNS, поиск SPF и проверка черного списка. Ниже приводится обзор каждого из вариантов:

Проверка имени хоста

Когда выбрана эта вкладка, инструмент будет искать DNS указанного вами имени хоста или домена (например,г. redwidgets.com). В результатах запроса также будет указан IP-адрес (например, 219.76.78.89) домена. Тест обычно полезен, когда вы хотите проверить, указывает ли конкретный домен на правильный IP-адрес или правильны ли его записи DNS.

Поиск MX

Чтобы выполнить этот поиск, введите адрес электронной почты. Когда выбрана вкладка поиска MX, ваш тест будет запрашивать запись MX (Mail Exchange) для введенного вами адреса электронной почты. В результате будут показаны серверы и порядок, в котором они доставляют электронные письма на запрашиваемый адрес.Тест также покажет IP-адрес и имя хоста серверов почтового обмена.

Поиск записи NS

Когда эта вкладка отмечена, запрос выполняет проверку записей серверов имен для имени хоста, которое вы вводите в поле поиска. Результаты запроса показывают записи серверов имен, которые были назначены домену.

Поиск SPF

Более опытные пользователи могут захотеть узнать SPF домена. Тест поиска SPF запрашивает записи DNS и показывает доступную запись SPF для доменного имени, которое вы запрашиваете.Чтобы узнать больше о SPF, посетите официальный сайт. SPF — это аббревиатура от Sender Policy Framework.

Обратный DNS

Как следует из названия, запрос выполняет обратный поиск в DNS для введенного вами IP-адреса. Результаты показывают доменное имя, связанное с IP-адресом.

Проверка черного списка

Этот запрос проверяет ваш IP-адрес в основных черных списках DNS, включая PSBL, CBL, NJABL, Spamhaus и Sorbs. Результаты показывают, был ли ваш домен занесен в черный список за рассылку спама.

Вы можете выполнить бесплатную проверку сервера имен с помощью WebsitePulse Test Tool. Просто зайдите на сайт www.websitepulse.com/tools и введите доменное имя, которое хотите проверить.

.