DevShtab
← Все статьи
#DNS#SSL#бизнес#ошибки#сайт#сервер#техподдержка#хостинг

Сайт не открывается: что проверить в первую очередь

Короткий чек-лист для владельцев бизнеса: что проверить, если сайт внезапно перестал открываться — DNS, SSL, хостинг, сервер и ошибки приложения.

Сайт не открывается: что проверить в первую очередь



Сайт может перестать открываться по разным причинам: сбой DNS, просроченный SSL-сертификат, проблема на хостинге, ошибка Nginx, неработающий PHP, упавшая база данных или закончившееся место на сервере.

Для владельца бизнеса это выглядит одинаково: клиенты не могут зайти на сайт, заявки не приходят, а реклама может продолжать тратить бюджет.

Ниже — практический порядок проверки: что открыть, какие команды выполнить и какой результат ожидать.

Если вы не уверены в командах на сервере — лучше не меняйте настройки вслепую. Сначала соберите информацию и передайте её специалисту.


1. Проверьте, проблема только у вас или у всех



Сначала нужно понять: сайт действительно не работает или проблема только на вашем компьютере/интернете.

Проверьте сайт:

1. С телефона через мобильный интернет, не через Wi-Fi.
2. В другом браузере.
3. В режиме инкогнито.
4. С другого устройства.
5. Через другого человека, который находится не в вашей сети.

Если сайт не открывается только у вас, часто виноваты кэш браузера, DNS провайдера или настройки сети.

Если сайт не открывается у всех — нужно проверять домен, DNS, сервер, SSL и приложение.

2. Посмотрите точный текст ошибки в браузере



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

DNS_PROBE_FINISHED_NXDOMAIN



Браузер не смог найти IP-адрес сайта по домену.

Частые причины:

домен не продлён;
не настроены DNS-записи;
недавно менялись NS-серверы;
DNS ещё не обновился;
провайдер или роутер закэшировал старый ответ.

ERR_CONNECTION_REFUSED



Домен нашёлся, но сервер отклонил подключение.

Частые причины:

не работает Nginx или Apache;
порт 80 или 443 закрыт;
firewall блокирует подключение;
сайт не привязан в конфиге веб-сервера.

ERR_CONNECTION_TIMED_OUT



Сервер слишком долго не отвечает.

Частые причины:

сервер выключен;
сервер завис;
проблема у хостинга;
firewall режет трафик;
перегрузка сервера.

Ошибка SSL или “Подключение не защищено”



Проблема с HTTPS-сертификатом.

Частые причины:

сертификат закончился;
сертификат выпущен не на этот домен;
не подключен fullchain-сертификат;
Nginx смотрит не на тот файл сертификата;
после обновления сертификата не перезапустили Nginx.

Ошибка 500



Сервер отвечает, но внутри сайта произошла ошибка.

Частые причины:

ошибка PHP;
не работает база данных;
сломался конфиг приложения;
не хватает прав на файлы;
после обновления кода появилась ошибка.

3. Проверьте DNS с компьютера Windows



Если сайт не открывается с ошибкой DNS, откройте командную строку Windows.

Нажмите:


Win + R
cmd
Enter


Выполните команду:


nslookup example.ru


Вместо example.ru укажите свой домен.

Пример хорошего результата:


Name:    example.ru
Address: 185.91.179.71


Это значит, что домен нашёл IP-адрес.

Пример плохого результата:


*** UnKnown can't find example.ru: Non-existent domain


или:


NXDOMAIN


Это значит, что DNS не нашёл домен.

4. Проверьте DNS через Google и Cloudflare



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

Проверьте через Google DNS:


nslookup example.ru 8.8.8.8


Проверьте через Cloudflare DNS:


nslookup example.ru 1.1.1.1


Проверьте www-версию:


nslookup [www.example.ru](http://www.example.ru) 8.8.8.8


Хороший результат:


Name:    example.ru
Address: 185.91.179.71


Если через 8.8.8.8 и 1.1.1.1 IP есть, а через обычный nslookup нет — проблема, скорее всего, в DNS вашего провайдера, роутера или локальном кэше.

В этом случае можно временно сменить DNS на компьютере на:


8.8.8.8
1.1.1.1


И сбросить DNS-кэш Windows:


ipconfig /flushdns


Ожидаемый результат:


Successfully flushed the DNS Resolver Cache.


5. Проверьте DNS на Linux или macOS



Если у вас Linux или macOS, можно использовать dig.

Проверка A-записи:


dig +short example.ru A


Ожидаемый результат:


185.91.179.71


Проверка через Google DNS:


dig @8.8.8.8 +short example.ru A


Проверка www:


dig @8.8.8.8 +short [www.example.ru](http://www.example.ru) A


Если команда ничего не выводит — DNS-запись не найдена или ещё не обновилась.

6. Проверьте, доступен ли сервер по сети



Если DNS отдаёт IP, нужно понять, отвечает ли сервер.

На Windows выполните:


ping example.ru


Хороший результат:


Reply from 185.91.179.71: bytes=32 time=40ms TTL=55


Плохой результат:


Request timed out.


Важно: ping может быть отключён на сервере, поэтому отсутствие ответа на ping не всегда означает, что сайт умер.

Лучше проверить порты 80 и 443.

В PowerShell можно выполнить:


Test-NetConnection example.ru -Port 80
Test-NetConnection example.ru -Port 443


Хороший результат:


TcpTestSucceeded : True


Плохой результат:


TcpTestSucceeded : False


Если порт 443 не отвечает, HTTPS работать не будет. Если порт 80 не отвечает, HTTP работать не будет.

7. Проверьте HTTP-ответ сайта через curl



На Linux, macOS или Windows с установленным curl выполните:


curl -I http://example.ru


И отдельно HTTPS:


curl -I https://example.ru


Хороший результат может выглядеть так:


HTTP/2 200
server: nginx
content-type: text/html; charset=UTF-8


или так:


HTTP/1.1 200 OK
Server: nginx


Код 200 означает, что сайт отвечает нормально.

Возможные ответы:


HTTP/1.1 301 Moved Permanently


Это обычно нормально. Значит сайт перенаправляет, например, с HTTP на HTTPS.


HTTP/1.1 403 Forbidden


Доступ запрещён. Возможны проблемы с правами файлов, индексным файлом или конфигом Nginx.


HTTP/1.1 404 Not Found


Сервер работает, но нужная страница не найдена.


HTTP/1.1 500 Internal Server Error


Ошибка внутри сайта или приложения.


curl: (6) Could not resolve host


Проблема DNS.


curl: (7) Failed to connect


DNS сработал, но подключиться к серверу не получилось.

8. Проверьте SSL-сертификат



Если проблема только с HTTPS, проверьте сертификат.

Команда:


echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null | openssl x509 -noout -dates -subject -issuer


Хороший результат:


notBefore=Jun 01 00:00:00 2026 GMT
notAfter=Aug 30 23:59:59 2026 GMT
subject=CN = example.ru
issuer=C = US, O = Let's Encrypt, CN = R11


Обратите внимание на строку:


notAfter=Aug 30 23:59:59 2026 GMT


Это дата окончания сертификата.

Если сертификат просрочен, браузер может показывать ошибку безопасности.

Если команда выводит ошибку подключения, значит проблема может быть не в самом сертификате, а в Nginx, firewall или порте 443.

9. Если есть доступ к серверу — подключитесь по SSH



Если сайт находится на VPS или выделенном сервере, подключитесь по SSH.

Пример:


ssh user@185.91.179.71


Если порт нестандартный:


ssh -p 2222 user@185.91.179.71


После успешного входа вы увидите примерно такую строку:


user@server:~$


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

10. Проверьте, не закончилось ли место на диске



Одна из частых причин падения сайта — закончилось место на сервере.

Команда:


df -h


Хороший результат:


Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   18G   30G  38% /


Плохой результат:


Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   50G     0 100% /


Если Use% близко к 100%, сайт, база данных или PHP могут работать неправильно.

Также можно проверить inode:


df -i


Если IUse% 100%, место вроде есть, но новые файлы создаваться не смогут.

11. Проверьте нагрузку и память



Команды:


uptime
free -h


Пример нормального результата uptime:


18:20:01 up 10 days,  2:15,  1 user,  load average: 0.12, 0.20, 0.18


Если load average очень высокий, сервер может быть перегружен.

Пример free -h:


total        used        free
Mem:           3.8G        1.2G        1.6G
Swap:          2.0G        0.0G        2.0G


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

12. Проверьте Nginx



Если сайт работает через Nginx, проверьте статус:


sudo systemctl status nginx


Хороший результат:


Active: active (running)


Плохой результат:


Active: failed


или:


Active: inactive (dead)


Проверка конфига Nginx:


sudo nginx -t


Хороший результат:


nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful


Плохой результат:


nginx: [emerg] cannot load certificate
nginx: configuration file /etc/nginx/nginx.conf test failed


или:


nginx: [emerg] unknown directive


Если nginx -t показывает ошибку, Nginx может не запускаться после перезагрузки или изменения конфига.

Посмотреть последние ошибки Nginx:


sudo journalctl -u nginx -n 50 --no-pager


И лог ошибок сайта:


sudo tail -n 100 /var/log/nginx/error.log


13. Проверьте Apache, если сайт работает на Apache



Если вместо Nginx используется Apache:


sudo systemctl status apache2


Хороший результат:


Active: active (running)


Проверка конфига:


sudo apachectl configtest


Хороший результат:


Syntax OK


Логи Apache:


sudo tail -n 100 /var/log/apache2/error.log


14. Проверьте PHP-FPM



Если сайт на PHP, например Laravel, WordPress, Bitrix или самописный PHP-проект, часто нужен PHP-FPM.

Проверьте версию PHP-FPM, которая используется на сервере.

Например:


ls /run/php/


Можно увидеть:


php8.1-fpm.sock
php8.2-fpm.sock
php8.3-fpm.sock


Проверьте статус нужной версии:


sudo systemctl status php8.3-fpm


Хороший результат:


Active: active (running)


Плохой результат:


Active: failed


Если Nginx настроен на socket php8.3-fpm.sock, а реально работает только php8.1-fpm.sock, сайт может отдавать ошибку 502.

Проверить логи PHP-FPM:


sudo journalctl -u php8.3-fpm -n 50 --no-pager


15. Проверьте базу данных MySQL или MariaDB



Если сайт зависит от базы данных, проверьте MySQL:


sudo systemctl status mysql


или MariaDB:


sudo systemctl status mariadb


Хороший результат:


Active: active (running)


Плохой результат:


Active: failed


Проверить подключение к MySQL:


mysql -e "SELECT 1;"


Ожидаемый результат:


+---+
| 1 |
+---+
| 1 |
+---+


Если команда не работает, может быть проблема с доступом, паролем, сокетом MySQL или самим сервисом.

Посмотреть ошибки MySQL:


sudo journalctl -u mysql -n 100 --no-pager


или:


sudo tail -n 100 /var/log/mysql/error.log


Частая проблема:


No space left on device


Это означает, что на диске закончилось место.

16. Проверьте сайт локально с самого сервера



Иногда снаружи сайт не открывается, но внутри сервера отвечает.

На сервере выполните:


curl -I http://127.0.0.1


Ожидаемый результат:


HTTP/1.1 200 OK
Server: nginx


Если сайт должен отвечать по конкретному домену, можно проверить так:


curl -I -H "Host: example.ru" http://127.0.0.1


Если локально сайт отвечает, а снаружи нет — проблема может быть в DNS, firewall, открытых портах или сетевых настройках.

17. Проверьте firewall



Если сервер доступен по SSH, но сайт не открывается по HTTP/HTTPS, возможно закрыты порты 80 и 443.

Если используется ufw:


sudo ufw status


Хороший вариант:


Status: active

To                         Action      From
22/tcp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere


Если 80 и 443 нет в списке, их можно открыть:


sudo ufw allow 80/tcp
sudo ufw allow 443/tcp


После этого снова проверить:


sudo ufw status


Не закрывайте SSH-порт, через который вы подключены к серверу. Иначе можно потерять доступ.


18. Проверьте, какой сайт привязан к домену в Nginx



Список доступных конфигов:


ls -la /etc/nginx/sites-available/


Список включённых сайтов:


ls -la /etc/nginx/sites-enabled/


Нужно найти конфиг, где указан ваш домен:


sudo grep -R "server_name" /etc/nginx/sites-available/ /etc/nginx/sites-enabled/


Пример нормальной строки:


server_name example.ru [www.example.ru](http://www.example.ru);


Если домена нет в server_name, Nginx может отдавать другой сайт или ошибку.

После изменения конфига всегда проверяйте:


sudo nginx -t


И только если тест успешный, перезагружайте Nginx:


sudo systemctl reload nginx


19. Проверьте права на файлы сайта



Если сайт отдаёт 403 или 500, возможна проблема с правами.

Посмотрите владельца и права папки сайта:


ls -la /var/www/


И конкретного проекта:


ls -la /var/www/example/


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

Например, для Laravel часто проверяют:


ls -la storage
ls -la bootstrap/cache


Если в логах есть:


Permission denied


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

20. Проверьте последние изменения



Очень часто сайт ломается после конкретного действия.

Вспомните, что менялось перед сбоем:

меняли DNS-записи;
переносили сайт;
обновляли CMS или плагины;
меняли Nginx-конфиг;
обновляли PHP;
чистили файлы;
обновляли SSL;
меняли пароль базы данных;
добавляли новый сайт на сервер.

Если есть Git, можно посмотреть последние изменения:


git log --oneline -5


Если проект недавно обновляли, можно проверить статус:


git status


21. Что отправить специалисту для быстрой диагностики



Чтобы специалист быстрее нашёл проблему, отправьте ему:

1. Адрес сайта.
2. Скриншот ошибки в браузере.
3. Когда началась проблема.
4. Что менялось перед сбоем.
5. Результат nslookup или dig.
6. Результат curl -I.
7. Есть ли доступ к серверу по SSH.
8. Какая панель или хостинг используется.

Пример сообщения:


Сайт: https://example.ru

Ошибка:
DNS_PROBE_FINISHED_NXDOMAIN

Когда началось:
Сегодня примерно в 14:30.

Что менялось:
Меняли DNS-записи домена и подключали новый сервер.

Проверка:
nslookup example.ru 8.8.8.8 показывает IP 185.91.179.71
обычный nslookup через роутер показывает NXDOMAIN

Нужна помощь:
Понять, проблема в DNS, сервере или настройках домена.


Короткий чек-лист диагностики



Если сайт не открывается, проверьте по порядку:

1. Открывается ли сайт с другого устройства и мобильного интернета.
2. Какой точный текст ошибки показывает браузер.
3. Работает ли DNS через nslookup или dig.
4. Совпадает ли IP домена с IP сервера.
5. Открыты ли порты 80 и 443.
6. Отвечает ли сайт через curl -I.
7. Не просрочен ли SSL-сертификат.
8. Есть ли место на диске сервера.
9. Работает ли Nginx или Apache.
10. Работает ли PHP-FPM.
11. Работает ли MySQL или MariaDB.
12. Нет ли ошибок в логах.
13. Что менялось перед сбоем.

Когда лучше обратиться к специалисту



Если сайт связан с рекламой, заявками, продажами или работой компании, лучше не тратить часы на хаотичные попытки исправить проблему. Часто достаточно 15–30 минут диагностики, чтобы понять причину: DNS, SSL, сервер, Nginx, PHP, база данных или ошибка в коде.

В DevShtab мы помогаем с такими задачами: проверяем сайт, находим причину сбоя, исправляем ошибки, настраиваем сервер, SSL, почту, Nginx, PHP, базу данных и возвращаем сайт в рабочее состояние.

Если сайт перестал открываться — не всегда нужно переделывать всё с нуля. Чаще всего проблему можно найти по логам, DNS, SSL и состоянию сервера, а затем аккуратно исправить.