Ошибки CNAME
При публикации из пользовательского рабочего процесса GitHub Actions любой файл CNAME игнорируется и не требуется.
Если публикация выполняется из ветви, личные домены хранятся в файле CNAME в корне источника публикации. Вы можете добавить или обновить этот файл с помощью параметров репозитория либо вручную. Дополнительные сведения см. в разделе Управление личным доменом для сайта "Страницы GitHub".
Чтобы сайт преобразовывал нужный домен для просмотра, убедитесь, что файл 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 личного домена:
- Средство CLI, например
dig
. Дополнительные сведения см. в разделе "Управление личным доменом для сайта "Страницы GitHub"". - Средство поиска DNS в Интернете.
Неподдерживаемые имена личных доменов
Если личный домен не поддерживается, может потребоваться изменить домен на поддерживаемый. Вы также можете обратиться к поставщику DNS, чтобы узнать, предлагает ли он службы переадресации для доменных имен.
Убедитесь, что сайт:
-
Не использует несколько доменов Apex. Например, значения
example.com
иanotherexample.com
. -
Не использует несколько поддоменов
www
. Например, значенияwww.example.com
иwww.anotherexample.com
. -
Не использует ни домен Apex, ни пользовательский поддомен. Например, значения
example.com
иdocs.example.com
.Единственным исключением является поддомен
www
. При правильной настройке поддоменwww
автоматически перенаправляется в домен Apex. Дополнительные сведения см. в разделе Управление личным доменом для сайта "Страницы GitHub".
Предупреждение. Настоятельно рекомендуется не использовать дикие записи DNS карта, например*.example.com
. Эти записи ставят вас под непосредственный риск отработки домена, даже если вы проверяете домен. Например, если проверить example.com
это, кто-то не сможет использоватьa.example.com
, но он по-прежнему может взять на b.a.example.com
себя (который охватывается диким карта ЗАПИСЬ DNS). Дополнительные сведения см. в разделе Проверка личного домена для GitHub Pages.
Список поддерживаемых пользовательских доменов см. в разделе "Сведения о личных доменах и страницах GitHub".
Ошибки HTTPS
Доступ к сайтам GitHub Pages, использующим личные домены, которые правильно настроены с помощью записей DNS CNAME
, ALIAS
, ANAME
или A
, можно получить по протоколу HTTPS. Дополнительные сведения см. в разделе Защита сайта GitHub Pages с помощью HTTPS.
После настройки личного домена может потребоваться около часа, чтобы ваш сайт стал доступным по протоколу HTTPS. После обновления существующих параметров DNS может потребоваться удалить и повторно добавить личный домен в репозиторий сайта, чтобы активировать процесс включения HTTPS. Дополнительные сведения см. в разделе Управление личным доменом для сайта "Страницы GitHub".
Если вы используете записи авторизации центра сертификации (CAA), должна существовать по крайней мере одна такая запись со значением letsencrypt.org
для сайта, чтобы он был доступен по протоколу HTTPS. Дополнительные сведения см. в статье Авторизация центра сертификации (CAA) в документации по Let's Encrypt.
Форматирование URL-адресов в Linux
Если URL-адрес сайта содержит имя пользователя или название организации, которое начинается либо заканчивается тире или содержит последовательные тире, пользователи, выполняющие просмотр, используя Linux, при попытке посетить сайт получат ошибку сервера. Чтобы исправить это, измените имя пользователя GitHub Enterprise Cloud и удалите символы, которые не являются буквами или цифрами. Дополнительные сведения см. в разделе Изменение имени пользователя для GitHub.
Кэш браузера
Если вы недавно изменили или удалили личный домен и не можете получить доступ к новому URL-адресу в браузере, вам может потребоваться очистить кэш браузера для получения доступа. Дополнительные сведения об очистке кэша см. в документации браузера.
Доменное имя, взятое
Если вы пытаетесь использовать личный домен, и он говорит, что домен уже используется, вы можете сделать домен доступным для собственного использования, сначала проверив его. Дополнительные сведения см. в разделе Проверка личного домена для GitHub Pages.