Проблема с доменом .рф

mbin
На сайте с 29.03.2008
Offline
68
1944

Столкнулся с проблемой при размещении на хостинге домена .рф. Создаю домен в ISPmanager, всё проходит как обычно, но при попытке зайти на сайт через браузер получаю 403 ошибку. .htaccess в корне нету, лежит только дефолтный index.html от ISP, права все стоят нормальные, владелец тоже. Все остальные домены, не IDN, на этом хостинге (Park-web) работают нормально, на других хостингах с ISPmanager IDN тоже уже прикручивал без проблем. То есть проблема только с IDN и только на этом хостинге. Саппорт порекомендовал удалить и снова установить домен и переименовать для него корневую директорию (заменить xn--... на что-нибудь попроще), но результата это не дало.

Никто не сталкивался с чем-нибудь подобным? В чем может быть причина?

pupseg
На сайте с 14.05.2010
Offline
347
#1
mbin:
Столкнулся с проблемой при размещении на хостинге домена .рф. Создаю домен в ISPmanager, всё проходит как обычно, но при попытке зайти на сайт через браузер получаю 403 ошибку. .htaccess в корне нету, лежит только дефолтный index.html от ISP, права все стоят нормальные, владелец тоже. Все остальные домены, не IDN, на этом хостинге (Park-web) работают нормально, на других хостингах с ISPmanager IDN тоже уже прикручивал без проблем. То есть проблема только с IDN и только на этом хостинге. Саппорт порекомендовал удалить и снова установить домен и переименовать для него корневую директорию (заменить xn--... на что-нибудь попроще), но результата это не дало.

Никто не сталкивался с чем-нибудь подобным? В чем может быть причина?

ну а банально в логах что пишет вебсервер ? суется он за дефолтной html туда куда надо?

Качественная помощь в обслуживании серверов. (/ru/forum/661100) Бесплатных консультаций не даю, не помогаю, не обучаю. Минималка от 100$. Как пропатчить KDE-просьба не спрашивать. Есть форумы (http://linux.org.ru) и полезные сайты (http://www.opennet.ru/).
mbin
На сайте с 29.03.2008
Offline
68
#2

В логах пишет:

188.128.119.9 - - [17/Nov/2010:17:34:20 +0600] "GET / HTTP/1.0" 403 202 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 GTB7.1 (.NET CLR 3.5.30729)"

В ошибках:

[Wed Nov 17 17:34:20 2010] [error] [client 188.128.119.9] client denied by server configuration: /usr/home/h1070/data/www/mydomain/
rustelekom
На сайте с 20.04.2005
Offline
522
#3

client denied by server configuration - в .htaccess запрет не стоит на доступ к сайту?

SSD VPS, SSD хостинг и выделенные серверы в Германии или РФ, FTP хранилища, регистрация доменов и SSL сертификаты ( https://www.robovps.biz/ ) Контакты: Telegram ( https://t.me/rustelekom_bot )
mbin
На сайте с 29.03.2008
Offline
68
#4

.htaccess вообще отсутствовал.

Собственно, уже перенес сайт на другой хостинг, там всё заработало, правда, возникли проблемы другого рода, но, думаю, решаемые.

bydem
На сайте с 02.10.2010
Offline
7
#5

Автор, это была ошибка nginx. Решается она на стороне администратора сервера. Отписали бы ему и все. У наших клиентов подобное пару раз проскакивало. Все решаемо.

Хостинг. VDS/Dedicated. Лицензия связи РФ №69884
mbin
На сайте с 29.03.2008
Offline
68
#6
bydem:
Автор, это была ошибка nginx. Решается она на стороне администратора сервера. Отписали бы ему и все. У наших клиентов подобное пару раз проскакивало. Все решаемо.

Возможно и так (саппорту-то я, понятное дело, в первую очередь отписал), потому что как раз с ошибкой nginx я столкнулся потом на паре своих VDS, а именно - на доменах .рф ни в какую не хотели отдаваться файлы стилей и картинок, в итоге страницы открывались в текстовом виде. Разумеется, подозрение у меня сразу пало на nginx, и немного покопавшись, я выяснил, что баг вызван тем, что nginx отказывался работать с длинными доменами, а .рф в пуникоде, конечно, короткими не назовешь. Решение довольно простое - надо в конфиге (nginx.conf) в блоке http явным образом прописать размер корзины в хэш-таблицах имён серверов с помощью строки server_names_hash_bucket_size. Значение можно задать 64, ну или на всякий случай - 128. В итоге должно получиться что-то вроде:


http {
.....
server_names_hash_bucket_size 128;

.....

}

После рестарта nginx всё замечательно заработало.

Думаю, в связи с теперешним лавинообразным распространением IDN, такие проблемы могут возникать довольно часто на серверах, где nginx стоит с настройками по умолчанию (по которым для hash bucket size задается минимально возможный размер), так что, может быть, кому-то это будет полезно :)

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий