WebFixer24 Обсудить задачу

Сайт на Tilda не открывается: диагностика домена, HTTPS, DNS и редиректов

Обновлено: Время чтения: около 20 минут

Сайт на Tilda может перестать открываться по очень разным причинам. Иногда проблема вообще не в самой Tilda: домен указывает не туда, DNS ещё не обновился, HTTPS не настроен, включён конфликтующий редирект или браузер продолжает показывать старый кеш.

А иногда всё проще: главная страница не опубликована или не назначена в настройках сайта.

Поэтому главное — не менять всё подряд.

Нормальная диагностика выглядит так:

Сайт не открывается
        ↓
Какой именно симптом?
        ↓
┌─────────────────────────────┬─────────────────────────────┐
│ Домен вообще не находится   │ Домен открывается, но      │
│                             │ браузер ругается на HTTPS  │
│ → DNS                       │ → сертификат               │
│ → A / NS                    │ → настройки HTTPS          │
├─────────────────────────────┼─────────────────────────────┤
│ Открывается страница Tilda  │ Бесконечный редирект       │
│ или пустая страница         │                             │
│ → публикация                │ → HTTP/HTTPS               │
│ → главная страница          │ → WWW                      │
│ → ограничения               │ → Cloudflare               │
└─────────────────────────────┴─────────────────────────────┘

Tilda сама разделяет эти случаи: проблемы с публикацией и главной страницей, ошибки DNS и отдельные ошибки HTTPS.

Что сделать сразу, если сайт Tilda не открывается

↑ К оглавлению

Не начинайте одновременно:

менять DNS
+
включать HTTPS
+
менять NS
+
переключать Cloudflare
+
добавлять редиректы

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

Сначала зафиксируйте:

  • адрес сайта;
  • что именно показывает браузер;
  • работает ли служебный адрес Tilda;
  • работает ли домен по HTTP;
  • работает ли домен по HTTPS;
  • были ли недавно изменения DNS, домена или Cloudflare.

После этого идём по симптомам.

Шаг 1. Определяем точный симптом

↑ К оглавлению

Попробуйте открыть:

https://example.com

Возможны несколько сценариев.

Сценарий A

Браузер пишет:

Не удаётся получить доступ к сайту
DNS_PROBE_FINISHED_NXDOMAIN
DNS address could not be found

Это почти наверняка ветка:

домен / DNS

Сценарий B

Браузер открывает сайт, но пишет:

Соединение не защищено

или показывает ошибку сертификата.

Это ветка:

HTTPS / SSL

Сценарий C

Открывается пустая страница с логотипом Tilda.

Тогда проблема может быть в том, что:

  • главная страница не опубликована;
  • главная страница не назначена;
  • включено ограничение доступа по IP.

Сценарий D

Браузер пишет:

Too many redirects
ERR_TOO_MANY_REDIRECTS

Это ветка:

HTTP / HTTPS / WWW / Cloudflare / редиректы

Шаг 2. Проверяем, опубликована ли главная страница

↑ К оглавлению

В Tilda страница может существовать в проекте, но не быть опубликована.

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

Если страница давно редактировалась, но после изменений не публиковалась, посетители могут видеть старую версию или вообще не увидеть ожидаемую страницу.

Если Tilda сообщает:

Pages are not published

опубликуйте страницы.

Шаг 3. Проверяем, назначена ли главная страница

↑ К оглавлению

Откройте:

Настройки сайта
→ Главная страница

Убедитесь, что нужная страница действительно выбрана как главная.

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

После изменения:

  1. сохраните настройки;
  2. опубликуйте сайт;
  3. откройте домен снова.

Шаг 4. Проверяем ограничения доступа

↑ К оглавлению

Откройте:

Настройки сайта
→ Права доступа

или соответствующий раздел Permissions.

Проверьте, не включено ли ограничение по IP.

Если ограничение было включено случайно, отключите его, сохраните настройки и снова опубликуйте сайт.

Шаг 5. Проверяем сам домен

↑ К оглавлению

Если служебный адрес Tilda работает, например:

project123456.tilda.ws

а ваш домен:

example.com

не открывается, проблема почти наверняка находится не в содержимом сайта, а в подключении домена.

Откройте:

Настройки сайта
→ Домен

Проверьте, какой домен указан и что показывает сама Tilda.

Если Tilda пишет, что домен подключён неправильно, дальше смотрим DNS.

Шаг 6. Проверяем DNS

↑ К оглавлению

Самый простой способ — посмотреть, во что резолвится домен.

В Windows:

nslookup example.com

В Linux/macOS:

dig example.com

или:

nslookup example.com

Если DNS вообще не возвращает IP:

Non-existent domain
NXDOMAIN

это означает, что домен пока не настроен правильно или изменения ещё не распространились.

Проверяем A-запись

↑ К оглавлению

Если домен подключается через A-запись, она должна указывать на IP, который Tilda показывает именно для вашего проекта в:

Настройки сайта
→ Домен

Не копируйте IP из старых инструкций или чужих проектов.

Проверить текущую запись можно так:

dig A example.com

или:

nslookup example.com

Что делать, если A-записей несколько

↑ К оглавлению

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

Типичная проблема:

example.com → старый хостинг
example.com → Tilda

Часть запросов может уходить на один сервер, часть — на другой.

Результат:

у одного пользователя сайт работает
у другого — нет

или сайт ведёт себя непредсказуемо.

Проверяем WWW

↑ К оглавлению

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

www.example.com

проверьте DNS для www.

Например:

dig A www.example.com

Если работает:

example.com

но не работает:

www.example.com

проблема может быть только в записи www.

Шаг 7. Проверяем NS-серверы

↑ К оглавлению

Если вы передали управление DNS самой Tilda, используются:

ns1.tildadns.com
ns2.tildadns.com

Проверить текущие NS можно:

dig NS example.com

или через:

nslookup -type=ns example.com

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

Это очень частая логическая ошибка:

DNS управляется у регистратора A
↓
пользователь меняет записи в панели B
↓
ничего не происходит

Шаг 8. После изменения DNS сайт может не заработать мгновенно

↑ К оглавлению

Это важно.

Изменения DNS могут распространяться от нескольких часов до 24 часов.

Поэтому сценарий:

изменил A-запись
↓
через 30 секунд сайт всё ещё не работает
↓
начал менять всё остальное

— плохой.

Сначала проверьте, какой IP уже виден через DNS.

Например:

dig example.com

Если вы всё ещё видите старый IP, возможно, изменения просто ещё не дошли до вашего DNS-резолвера.

Проверяем DNS через разные резолверы

↑ К оглавлению

Можно запросить конкретный DNS-сервер.

Например Google DNS:

dig @8.8.8.8 example.com

Cloudflare DNS:

dig @1.1.1.1 example.com

Если:

8.8.8.8 → новый IP
1.1.1.1 → новый IP
локальный DNS → старый IP

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

Шаг 9. Проверяем HTTPS

↑ К оглавлению

Если HTTP работает:

http://example.com

а HTTPS:

https://example.com

не работает, идём в настройки HTTPS.

В Tilda:

Настройки сайта
→ SEO
→ HTTPS

или соответствующий раздел HTTPS Settings.

Сертификат подключается после того, как домен уже корректно настроен. После включения сертификата обычно требуется некоторое время на выпуск — ориентир порядка 5–30 минут.

Проверяем HTTPS через curl

↑ К оглавлению
curl -Iv https://example.com/

Если соединение устанавливается нормально, вы увидите успешный TLS handshake и HTTP-ответ.

Если видите:

SSL certificate problem

или:

certificate verify failed

нужно сначала разобраться с сертификатом.

Почему нельзя чинить HTTPS до DNS

↑ К оглавлению

Сертификат выпускается для конкретного домена.

Если домен ещё указывает не туда, HTTPS может не подключиться корректно.

Поэтому порядок должен быть:

домен
↓
DNS
↓
сайт открывается
↓
HTTPS
↓
редирект HTTP → HTTPS

а не наоборот.

Шаг 10. Почему браузер пишет «соединение не защищено»

↑ К оглавлению

Возможны несколько вариантов:

  1. сертификат ещё не выпущен;
  2. домен подключён неправильно;
  3. HTTPS включён, но DNS ещё ведёт не туда;
  4. браузер попадает на старый сервер;
  5. используется конфликтующая конфигурация через Cloudflare;
  6. сертификат ещё не обновился.

Шаг 11. Проверяем редирект HTTP → HTTPS

↑ К оглавлению

Когда HTTPS уже работает, можно включать редирект:

http://example.com
↓
https://example.com

В Tilda он настраивается в:

Настройки сайта
→ SEO
→ WWW, HTTPS Redirects

Проверить можно:

curl -I http://example.com/

Нормально:

HTTP/1.1 301
Location: https://example.com/

Шаг 12. Проверяем цепочку редиректов

↑ К оглавлению

Используйте:

curl -IL --max-redirs 10 http://example.com/

Нормальная цепочка:

http://example.com
↓ 301
https://example.com
↓ 200

Плохая:

http://example.com
↓
https://example.com
↓
http://example.com
↓
https://example.com
↓
...

или:

example.com
↓
www.example.com
↓
example.com
↓
www.example.com

Шаг 13. WWW и без WWW

↑ К оглавлению

Выберите один основной вариант:

example.com

или:

www.example.com

Не надо заставлять оба адреса постоянно перекидывать друг друга.

В Tilda редиректы между WWW и non-WWW настраиваются в том же разделе:

SEO
→ WWW, HTTPS Redirects

Шаг 14. Если появился ERR_TOO_MANY_REDIRECTS

↑ К оглавлению

Сначала посмотрите цепочку:

curl -IL --max-redirs 10 https://example.com/

Если видите:

example.com
↓
www.example.com
↓
example.com

значит, разные системы спорят между собой.

Возможные участники:

Tilda
+
Cloudflare
+
регистратор
+
внешний redirect

Шаг 15. Проверяем Cloudflare

↑ К оглавлению

Это отдельная важная ветка.

Если DNS управляется через Cloudflare, проверьте, включён ли proxy.

Tilda предупреждает, что Cloudflare proxying может конфликтовать с системой защиты Tilda и делать сайт недоступным; для диагностики важно проверить работу DNS без лишнего proxy-слоя.

То есть:

оранжевая облачко Cloudflare

не всегда полезно.

Что происходит при конфликте Cloudflare

↑ К оглавлению

Схема:

Браузер
↓
Cloudflare
↓
Tilda

Если одновременно:

  • Cloudflare делает HTTPS;
  • Tilda делает HTTPS;
  • Cloudflare перенаправляет;
  • Tilda тоже перенаправляет;

можно получить:

redirect loop

или проблемы с SSL.

Не меняйте режим SSL Cloudflare наугад

↑ К оглавлению

Если Cloudflare используется осознанно, сначала определите текущую схему.

Не надо просто переключать:

Flexible
Full
Strict

по кругу.

Сначала решите:

кто завершает HTTPS
и
кто выполняет HTTP → HTTPS redirect

Шаг 16. Проверяем старые редиректы Tilda

↑ К оглавлению

В Tilda есть отдельные 301-редиректы для страниц:

Настройки сайта
→ SEO
→ 301 redirects

Если проблема возникает только на конкретной странице:

example.com/old-page

а главная работает, проверьте 301 redirects.

Проверяем конкретную страницу

↑ К оглавлению
curl -IL --max-redirs 10 https://example.com/old-page

Посмотрите:

куда она ведёт

Если редирект:

A → B → A

вы нашли цикл.

Шаг 17. Проверяем кеш

↑ К оглавлению

Если настройки уже исправлены, а браузер продолжает показывать старую ошибку:

  1. откройте сайт в режиме инкогнито;
  2. попробуйте другой браузер;
  3. очистите кеш;
  4. проверьте через curl.

Как понять, что проблема именно в кеше

↑ К оглавлению

Если:

curl -I https://example.com/

возвращает:

200

а браузер всё ещё показывает старую ошибку, попробуйте:

инкогнито

или другой компьютер/телефон.

Если там всё работает — сервер уже исправлен.

Быстрый алгоритм диагностики

↑ К оглавлению

Если оставить только самое главное:

1. Открыть домен.

2. Если DNS error:
   проверить A / NS.

3. Если служебный адрес Tilda работает,
   а домен нет:
   проблема почти наверняка в домене/DNS.

4. Проверить:
   nslookup example.com
   или
   dig example.com

5. Сверить IP с:
   Настройки сайта → Домен.

6. Если DNS меняли недавно:
   подождать распространения.

7. Если HTTP работает, HTTPS нет:
   проверить настройки HTTPS.

8. Когда HTTPS уже работает:
   включить HTTP → HTTPS redirect.

9. Если ERR_TOO_MANY_REDIRECTS:
   curl -IL --max-redirs 10

10. Проверить:
    WWW
    HTTPS
    Cloudflare
    301 redirects

11. Проверить публикацию главной страницы.

12. Проверить назначение главной страницы.

13. Проверить ограничения доступа.

14. Очистить кеш.

15. Повторить проверку.

Быстрый набор команд

↑ К оглавлению

DNS

nslookup example.com

или:

dig example.com

A-запись

dig A example.com

WWW

dig A www.example.com

NS

dig NS example.com

Google DNS

dig @8.8.8.8 example.com

Cloudflare DNS

dig @1.1.1.1 example.com

HTTPS

curl -Iv https://example.com/

Redirect chain

curl -IL --max-redirs 10 http://example.com/

и:

curl -IL --max-redirs 10 https://example.com/

Что не стоит делать

↑ К оглавлению

1. Менять DNS каждые пять минут

DNS может обновляться часами.

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

2. Копировать чужой IP Tilda

Используйте IP, который Tilda показывает именно вашему проекту.

3. Одновременно менять NS и A-записи

Сначала определите, где реально управляется DNS.

4. Включать HTTPS до корректного подключения домена

Сначала:

домен → DNS → сайт

потом HTTPS.

5. Включать несколько редиректов сразу

Не нужно одновременно:

Tilda HTTP → HTTPS
Cloudflare HTTP → HTTPS
регистратор redirect

если вы не понимаете, зачем нужен каждый из них.

6. Считать любой 404 проблемой DNS

Если:

example.com

работает,

а:

example.com/page

даёт 404,

DNS здесь почти наверняка уже ни при чём.

7. Чинить Tilda, если проблема у регистратора

Если DNS не резолвится, редактирование блоков страницы никак не поможет.

Как понять, что сайт действительно исправлен

↑ К оглавлению

После изменений проверьте:

curl -I http://example.com/

Ожидаем:

301 → https://example.com/

Затем:

curl -I https://example.com/

Ожидаем:

200

Проверьте также:

example.com
www.example.com

Один из них должен быть основным, второй — корректно вести на него.

Проверяем сайт глазами

↑ К оглавлению

Откройте:

https://example.com/

Проверьте:

  • главную;
  • несколько внутренних страниц;
  • мобильную версию;
  • формы;
  • изображения;
  • кнопки;
  • корзину, если она есть.

Проблема «сайт не открывается» считается исправленной не тогда, когда открылась одна главная страница, а когда нормально работает основной пользовательский сценарий.

Диагностическая схема целиком

↑ К оглавлению
Сайт Tilda не открывается
             ↓
      Домен резолвится?
        ↓          ↓
       НЕТ        ДА
        ↓          ↓
    DNS / A / NS   HTTPS работает?
                     ↓       ↓
                    НЕТ     ДА
                     ↓       ↓
                SSL / HTTPS  Что именно не работает?
                              ↓
                     ┌────────┴─────────┐
                     ↓                  ↓
                 Главная            Redirect loop
                     ↓                  ↓
                publication         curl -IL
                     ↓                  ↓
                home page          WWW / HTTPS
                     ↓                  ↓
                permissions        Cloudflare
                     ↓                  ↓
                     └────────┬─────────┘
                              ↓
                          исправили
                              ↓
                       очистили кеш
                              ↓
                      повторная проверка

Если сайт на Tilda всё равно не открывается

↑ К оглавлению

Не продолжайте менять настройки вслепую.

Соберите минимум:

1. Что показывает браузер.

2. Работает ли:
   project.tilda.ws

3. Работает ли:
   http://example.com

4. Работает ли:
   https://example.com

5. DNS:
   nslookup example.com

6. HTTPS:
   curl -Iv https://example.com/

7. Redirects:
   curl -IL --max-redirs 10 https://example.com/

8. Используется ли Cloudflare.

9. Менялись ли недавно:
   A
   NS
   HTTPS
   WWW
   redirects

После этого проблема обычно перестаёт выглядеть как:

«Tilda почему-то не работает»

и превращается в конкретную:

«домен всё ещё указывает на старый хостинг»

или:

«HTTPS работает, но Cloudflare и Tilda гоняют пользователя между HTTP и HTTPS»

или:

«сам домен работает, но главная страница не опубликована».

А конкретную проблему уже можно нормально исправлять.

Если домен уже открывается, а сбой возникает на сервере, полезна диагностика Nginx 504. Для WordPress после перехода на HTTPS есть отдельная проверка SSL и редиректов.

Частые вопросы

Почему сайт на Tilda не открывается после подключения домена?

Чаще всего причина в DNS: домен ещё не обновился, A-запись указана неправильно, используются неправильные NS или изменения редактируются не в той DNS-зоне.

Сколько ждать после изменения DNS?

Изменения могут распространяться от нескольких часов до 24 часов.

Почему Tilda работает по служебному адресу, но не работает по домену?

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

Почему после включения HTTPS сайт не открывается?

Сначала проверьте, что домен корректно подключён. HTTPS должен настраиваться уже поверх рабочего домена. Затем проверьте сертификат и редиректы.

Почему появляется ERR_TOO_MANY_REDIRECTS?

Обычно потому, что несколько систем одновременно перенаправляют HTTP/HTTPS или WWW/non-WWW. Частый кандидат — сочетание настроек Tilda и Cloudflare.

Нужно ли включать Cloudflare proxy для сайта Tilda?

Не обязательно. Proxying Cloudflare может конфликтовать с Tilda и приводить к недоступности сайта.

Почему после исправления сайт всё равно не работает у меня, а у других работает?

Возможен локальный DNS-кеш или кеш браузера. Сравните DNS через разные резолверы и откройте сайт в режиме инкогнито или с другого устройства.

Что делать, если всё проверил, но сайт всё равно не открывается?

Соберите:

домен
результат nslookup / dig
результат curl -Iv
цепочку curl -IL
скрин ошибки

И уже по этим данным можно точно понять, где ломается цепочка.

↑ К оглавлению

Нужна помощь, если сайт на Tilda не открывается?

Если сайт перестал открываться после подключения домена, DNS, HTTPS или Cloudflare, можно последовательно проверить всю цепочку:

домен → DNS → Tilda → HTTPS → редиректы → кеш.

Задача здесь не в том, чтобы бесконечно переключать настройки, а в том, чтобы найти точное место, где ломается открытие сайта, исправить его и затем проверить всё заново.

На KWORK Здесь, без регистрации
↑ К оглавлению