Устранение неполадок с личными доменами и страницами GitHub

В этой статье

Вы можете проверить наличие распространенных ошибок, чтобы устранить проблемы в работе личных доменов или протокола HTTPS для сайта GitHub Pages.

GitHub Pages is available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see "GitHub’s plans."

Ошибки CNAME

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

Если публикация выполняется из ветви, личные домены хранятся в файле CNAME в корне источника публикации. Вы можете добавить или обновить этот файл с помощью параметров репозитория либо вручную. Дополнительные сведения см. в разделе «AUTOTITLE».

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

Затем убедитесь, что файл CNAME отформатирован правильно.

  • Имя файла CNAME должно быть записано прописными буквами.
  • Файл CNAME может содержать только один домен. Чтобы указать несколько доменов на сайт, необходимо настроить перенаправление через поставщика DNS.
  • Файл CNAME должен содержать только доменное имя. Например, www.example.com, blog.example.com или example.com.
  • Доменное имя должно быть уникальным для всех сайтов GitHub Pages. Например, если файл CNAME другого репозитория содержит example.com, нельзя использовать example.com в файле CNAME для репозитория.

Неправильные настройки DNS

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

Вы также можете использовать один из следующих методов для проверки правильности настройки записей DNS личного домена:

Неподдерживаемые имена личных доменов

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

Убедитесь, что сайт:

  • Не использует несколько доменов Apex. Например, значения example.com и anotherexample.com.

  • Не использует несколько поддоменов www. Например, значения www.example.com и www.anotherexample.com.

  • Не использует ни домен Apex, ни пользовательский поддомен. Например, значения example.com и docs.example.com.

    Единственным исключением является поддомен www. При правильной настройке поддомен www автоматически перенаправляется в домен Apex. Дополнительные сведения см. в разделе «AUTOTITLE».

Предупреждение. Настоятельно рекомендуется не использовать дикие записи DNS карта, например*.example.com. Эти записи ставят вас под непосредственный риск отработки домена, даже если вы проверяете домен. Например, если проверить example.com это, кто-то не сможет использоватьa.example.com, но он по-прежнему может взять на b.a.example.com себя (который охватывается диким карта ЗАПИСЬ DNS). Дополнительные сведения см. в разделе «AUTOTITLE».

Список поддерживаемых пользовательских доменов см. в разделе "Сведения о личных доменах и страницах GitHub".

Ошибки HTTPS

Доступ к сайтам GitHub Pages, использующим личные домены, которые правильно настроены с помощью записей DNS CNAME, ALIAS, ANAME или A, можно получить по протоколу HTTPS. Дополнительные сведения см. в разделе «AUTOTITLE».

После настройки личного домена может потребоваться около часа, чтобы ваш сайт стал доступным по протоколу HTTPS. После обновления существующих параметров DNS может потребоваться удалить и повторно добавить личный домен в репозиторий сайта, чтобы активировать процесс включения HTTPS. Дополнительные сведения см. в разделе «AUTOTITLE».

Если вы используете записи авторизации центра сертификации (CAA), должна существовать по крайней мере одна такая запись со значением letsencrypt.org для сайта, чтобы он был доступен по протоколу HTTPS. Дополнительные сведения см. в статье Авторизация центра сертификации (CAA) в документации по Let's Encrypt.

Форматирование URL-адресов в Linux

Если URL-адрес сайта содержит имя пользователя или название организации, которое начинается либо заканчивается тире или содержит последовательные тире, пользователи, выполняющие просмотр, используя Linux, при попытке посетить сайт получат ошибку сервера. Чтобы исправить это, измените имя пользователя GitHub Enterprise Cloud и удалите символы, которые не являются буквами или цифрами. Дополнительные сведения см. в разделе «AUTOTITLE».

Кэш браузера

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

Доменное имя, взятое

Если вы пытаетесь использовать личный домен, и он говорит, что домен уже используется, вы можете сделать домен доступным для собственного использования, сначала проверив его. Дополнительные сведения см. в разделе «AUTOTITLE».