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

Потому что нужен заголовок Host и информация об имени хоста для TLS/SSL.

Тебе бы матчасть по сетям подучить. В части HTML-заголовков, например, и как они влияют на балансировщики входные.

Потому что на одном сервере может хостится несколько сайтов и сервер решает какой из них отдавать по заголовку Host. Если его нет, то непонятно какой сайт отдавать. Та же проблема если сайт за CDN - один IP делится множеством сайтов, маршрутизация по Host.

Если его нет, то непонятно какой сайт отдавать.

Понятно, первый в конфиге или тот что указан дефолтным (например, для nginx - default_server в listen).

Что за html-заголовки, влияющие на балансировщики?

https://a.b.c.d

Потому что это не IP.

Что за html-заголовки, влияющие на балансировщики?

Входящий трафик часто балансируется по заголовку, где передаётся доменное имя запроса.

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

А с каких пор запросы стали в формате html присылаться?😱

А с каких пор запросы стали в формате html присылаться?

А, так это я опечатался, ну :) HTTP

открываются, которые сделаны/спроектированы подобным образом.
никто не мешает писать ip в src/href в тегах html.
но без fqdn/ssl/tls, предположительно.
правда о них никто не знает)

Верно. Настоящий IP-адрес — это http://a:b:c:d:e:f:g:h

Настоящий, но не твой.

P.S.: http или https или ftp или другое всталять не нужно, не шариишь в этом, не надо так делать.

Верно. Настоящий IP-адрес — это http://a:b:c:d:e:f:g:h

Погоди, как он настоящий?

Если имеется в виду IPv6, то разве там не шестнадцатиричные числа должны быть? Что тогда за g и h?

В старых версиях HTTP заголовки передаются в формате key-value. Это создаёт ограничение: один ключ может принимать только одно значение на уровне протокола.

В HTTP/4 (следующая версия HTTP) планируют исправить этот фундаментальный недостаток: заголовки будут передаваться в формате таблицы, закодированной в HTML-теги <tr> и <td>.

RFC2068 от 1997 года.

RFC2068

3.2.2 HTTP URL.
«Http» схема используется для доступа к сетевым ресурсам при помощи протокола HTTP. Этот раздел определяет схемо-определенный синтаксис и семантику для HTTP URL.

http_URL = «http:» «//» host [ ":" port ] [ abs_path ]

host = <допустимое доменное имя машины
или IP адрес (в точечно-десятичной форме),
как определено в разделе 2.1 RFC 1123>

port = *DIGIT
Если порт пуст или не задан - используется порт 80. Это означает, что идентифицированный ресурс размещен в сервере, ожидающем TCP соединений на специфицированном порте port, компьютера host, и запрашиваемый URI ресурса - abs_path. Использования IP адресов в URL СЛЕДУЕТ избегать, когда это возможно (смотрите RFC 1900 [24]). Если abs_path не представлен в URL, он ДОЛЖЕН рассматриваться как «/» при вычислении запрашиваемого URI (Request-URI) ресурса (раздел 5.1.2).

разве там не шестнадцатиричные числа должны быть? Что тогда за g и h?

Пардон. Исправляюсь:

http://a:b:c:d:e:f:-f:-e

(Теперь это отрицательные шестнадцатиричные числа)

которые сделаны/спроектированы подобным образом.

особо нечего проектировать, даже бесплатный сертификат на ip-адрес сейчас выдаёт Let’s Encrypt

https://datatracker.ietf.org/doc/html/rfc2068#section-14.23

Что там, Host обязательный? так при запросе по ip-адресу, в Host указывается ip-адрес.

Я за бан. Такой low effort фарм шкворца это наглость. Мог бы придумать что-то оригинальнее

технически валидны оба варианта.
hostname-based routing это уже дополнительная опция.

GET /example HTTP/1.1
Host: 127.0.0.127
User-Agent: curl/6.6.6
Accept: */*

технически валидны оба варианта.

Однако у ТСа не получается. И я ему написал, почему. Хотя это максимально странный вопрос для человека, который называет себя программистом.

По ip лезут боты, поэтому без заголовка Host - пинок под зад (return 444)

Тут скорее вопрос почему умники из репозиториев решили, что нужно вообще ложить default page с установкой веб-сервера. По хорошему по ip-адресу вообще веб не должен открываться, кроме локалхоста, а так все только с SNI. Нормально настроенный веб-сервер по ip-адресу не должен открывать ничего, тем более Internet Explorer давно умер к счастью.

Это зависит от реализации веб сервера. Легко могу представить, что какие-то не отдадут ничего нормального. ТС не сказал к какому сайту обращаться, а значит мы не можем быть уверены, что там nginx.

А ещё у ТС в ссылке https протокол, а тут уже без SNI веб-сервер банально не сможет выбрать какой сертификат использовать (сертификаты на IP адреса технически возможны, но практически не используются). В итоге будет ошибка ещё на этапе установки TLS туннеля.

я бы не доверял бы серту без fqdn, особенно без резолва.
ip-only это история без dns/tls/ssl.
а за Ваш LE-mitm в приличном обществе по лицу бьют.

ну на прямую 1.1.1.1 сам себя находит через хром, правда редиректит на one.one.one.one[видимо для tls/ssl].

хых, все технологии современности познать не возможно :) физические не успеешь все изучить… и потому ими пользуются как чОрным ящиком.
это всегда и везде так.

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

в каждой специальности есть такие вродеб аксиматические азы, однако не столкнувшись, ну вот никак.
я как то заикнулся на пьянке что вот надобно в гараже койчего доделать. так меня чуть ли не ниже пола закатали - всё не так и всё неправильно. ну а чё, они-то всю жизнь по внутренней отделке и стройкам, а я всего лишь электронщик, мастерка в руках не державший и следственно самых примитивнейших и дебильнейших азов не знавший…
ну вот так… :)

Ну ХЗ. Вот смотри, я сейчас вопрос чуть-чуть ТС-а изменю (тоже азы) и уверен что кроме сетевиков и местных кулибиных никто ничего путного не скажет. Предположим есть локалка и в ней машника 192.168.1.10, на той машинке крутится несколько веб-морд для локалки (торрентокачалка, файлопомойка, какой-нибудь Nextcloud Office/ONLYOFFICE Workspace, может что-то ещё). Как всё это настроить, чтоб было удобно пользоваться и не покупать новое железо? Аптайм компа с веб мордами может быть не круглосуточный, а локальная сеть и интернет в квартире должны работать всегда со всех устройств (чего нельзя сказать о веб мордах, те работают пока комп работает).

без SNI веб-сервер банально не сможет выбрать какой сертификат использовать

Так же как с хостом будет первый/дефолтный, в браузер может ругатся на несовпадение домена/ip в сертификате, а ботам не проверяющим, без разницы - в поисковой выдаче гугла много https ссылок с неправильными сертификатами.

сертификаты на IP адреса технически возможны, но практически не используются

Практически на всех DNS over HTTPS используются.

Попробовал на своём сервере с Caddy. При обращении по IP/неизвестному хосту по HTTP происходит редирект на тот же хост, но HTTPS (auto https - поведение по умолчанию, которое я не отключал). Если пройти по редиректу, то происходит ошибка TLS (не неверный сертификат, а именно просто ошибка SSL, полагаю, сервер закрывает коннект, когда не находит подходящий сертификат для домена, проигнорировать ошибку со стороны клиента невозможно).

Попробовал то же самое, но с CloudFlare (я не в России, РКН не влияет, если что). Зарезолвил IP сайта, который заведомо за CF, сделал curl по IP. Отдаёт plain text «error code: 1003» с 403 статусом. Через браузер то же самое. Если же обратиться по HTTPS, то отдаёт нечто с сертификатом от cdnjs.cloudflare.com. Если проигнорировать невалидность сертификата, то там минимальная HTML страница с ошибкой 403.

Отдавать рандомный сайт это поведение специфичное для Nginx (и, возможно, Apache). Более молодые проекты веб-серверов, а также CDN отдают ошибку/рвут коннект (что ИМХО корректнее), если Host не сконфигурирован.

Практически на всех DNS over HTTPS используются.

Это не обычный сайт, а инфраструктурный сервис. Таких серверов 0.01% от общего числа или меньше. Большинство админов не поднимают свой публичный DNS торчащий наружу.

это специфическое поведение для ситуации «один сайт == один ip», в локалке или еще как. что вполне логично для такого варианта.
однако у веб-хостеров на одном ip могут быть сотни сайтов. так что по http://ip они не будут отдавать ни рандомный, ни чего либо подобного. предположу что и заглушка или редирект 301 там тоже отсутствует.

так при запросе по ip-адресу, в Host указывается ip-адрес.

Именно. И пропускается балансировщиком на входе, потому что тот по хосту раскидывает запросы.

Как всё это настроить, чтоб было удобно пользоваться

Я без понятия, как именно тебе и твоим домашним удобно.

Себе я бы завёл на роутере в локальной зоне несколько имён (torrent, cloud, office, etc -> 192.168.1.10) и разрулил, засунув все веб-морды за проксирующий nginx с виртхостами.

Себе я бы завёл на роутере в локальной зоне несколько имён

А вот это засада. Далеко не все роутеры могут так, некоторые вообще не могут, мой, например, может, но только при настройке через telnet (вебморда не имеет таких возможностей, при этом через консольку я к нему подключался 2 раза в жизни, первый чтоб посмотреть что она есть и работает, а второй раз когда роутер завис и веб морда не открывалась для проведения диагностики - меня дудосил провайдер у которого была техническая неисправность, что впрочем решилось через пять минут после того как я дозвонился). Так что тут правда чтоб такое знать, надо именно с этим столкнуться ИРЛ. А далеко не все программисты программируют сайты и веб. Тем кто пишет дрова для железок, софт на пекарни и игрушки на смартфоны вообще сеть фиолетово как работает. Пожалуй кроме веб программистов и админов остальным она нужна только как сервис, за который отвечает кто-то другой.

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

Вот пример сессии для linux.org.ru:

% curl -v https://178.248.233.6
*   Trying 178.248.233.6:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
*   subject: CN=linux.org.ru
*   start date: Apr 28 08:42:34 2026 GMT
*   expire date: Jul 27 08:42:33 2026 GMT
*   issuer: C=US; O=Let's Encrypt; CN=E7
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*  subjectAltName does not match ipv4 address 178.248.233.6
* SSL: no alternative certificate subject name matches target ipv4 address '178.248.233.6'
* closing connection #0
curl: (60) SSL: no alternative certificate subject name matches target ipv4 address '178.248.233.6'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

При попытке подключения сервер выдал сертификат, который действителен для linux.org.ru и для www.linux.org.ru, но для адреса 178.248.233.6 этот сертификат уже не подходит, поэтому TLS соединение после этого разрывается.

Но если проигнорировать эту ошибку, то сайт вполне открывается и выдаёт полезный ответ:

% curl -k -i https://178.248.233.6
HTTP/1.1 302 
Server: QRATOR
Date: Thu, 04 Jun 2026 11:34:02 GMT
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=15
Location: https://www.linux.org.ru/

Здесь нам повезло. К этому IP-адресу привязан только сайт лора (ну или по крайней мере он в какой-то степени основной).

Если за одним IP-адресом прячутся многие сайты, то после этого будет другая проблема - веб-сервер не поймёт, куда именно ты хочешь зайти и выдаст тебе что-нибудь, что тебе, скорей всего, было не надо. Например такое:

% curl -ik 'https://104.16.133.229'
HTTP/2 403 
server: cloudflare
date: Thu, 04 Jun 2026 11:43:33 GMT
content-type: text/html
content-length: 151
cf-ray: a066ae3b3f93dc3d-AKX

<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>cloudflare</center>
</body>
</html>

Если сформулировать ответ более общо. То ответ - потому, что конкретный сайт не рассчитан на такое использование. То, что у тебя есть техническая возможность писать что угодно в адресную строку обозревателя, не означает, что любой сайт это будет поддерживать. Ты должен зайти на сайт по правильному адресу и в дальнейшем пользоваться сайтом как положено, щёлкая по ссылкам, а не вбивая в адресную строку что бог на душу положит. А если и пишешь так - не удивляйся тому, что не работает.

(сертификаты на IP адреса технически возможны, но практически не используются

Let's encrypt вполне их раздаёт, правда живут они 6 дней

Задал бы ты этот вопрос лет двадцать назад - узнал бы о себе много нового. Например в топике тоже поднимался этот вопросик Фришники! :-) Помогите...