Если локальный веб-сайт или сервер разработки работает по адресу 127.0.0.1, но не работает по localhost, либо работает только с одним семейством адресов, проверьте адрес прослушивания сервера и протестируйте каждый путь отдельно. На Mac 127.0.0.1 — это петлевой адрес IPv4, а ::1 — петлевой адрес IPv6; оба указывают на ваш собственный компьютер. Успешная проверка одного из них не доказывает, что служба прослушивает другой.

1. Проверьте, прослушивает ли служба подключения

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

lsof -nP -iTCP:8000 -sTCP:LISTEN

Команда lsof выводит список открытых файлов, включая сетевые сокеты. Параметры сужают вывод до TCP-прослушивателей на этом порту и отключают преобразование имен. Если вывод отсутствует, служба может быть не запущена, использовать другой порт или не открыть TCP-прослушиватель. Проверьте вывод при запуске приложения и настроенный порт, прежде чем изменять сетевые настройки macOS. (Справочное руководство по lsof)

Посмотрите на адрес в столбце NAME. Прослушиватель, отображаемый как 127.0.0.1:8000, привязан к петлевому интерфейсу IPv4; отображаемый как [::1]:8000 — к петлевому интерфейсу IPv6. Использование подстановочного адреса (wildcard) может означать прослушивание не только локальной петли, в зависимости от сервера и операционной системы. Ключевой момент диагностики — включает ли фактический адрес привязки сервера то семейство адресов, которое вы тестируете. Такая интерпретация следует из адреса сокета, о котором сообщает lsof; конфигурация приложения определяет, какой именно адрес открывает сервер.

2. Протестируйте IPv4 и IPv6 напрямую

Выполните запрос к тому же порту и пути через каждый из петлевых адресов. Утилита curl позволяет протестировать HTTP-соединение, не полагаясь на выбор адреса браузером.

curl -v --connect-timeout 3 http://127.0.0.1:8000/
curl -g -v --connect-timeout 3 'http://[::1]:8000/'

Квадратные скобки обязательны для литерала IPv6 в URL; флаг -g указывает curl не интерпретировать их как синтаксис сопоставления шаблонов (globbing). Одинарные кавычки сохраняют URL в исходном виде в стандартных командных оболочках macOS. В документации curl описаны эти правила формирования URL, а также параметры --ipv4 и --ipv6 для ограничения разрешения имен хостов. (Синтаксис URL в curl, руководство curl)

Отказ в соединении обычно означает, что по данному адресу и порту нет прослушивателя, принимающего подключения. Превышение времени ожидания (timeout) указывает на то, что соединение не установилось в пределах лимита. Если curl возвращает HTTP-ответ, включая код ошибки (например, 404), TCP- и HTTP-соединение дошло до сервера; в этом случае причину следует искать в пути или ответе приложения, а не считать это сбоем подключения по IPv4/IPv6.

3. Сравните localhost с каждым адресом

Теперь протестируйте имя хоста, используя параметры curl для IPv4 и IPv6, а затем попробуйте без ограничения по семейству:

curl -4 -v --connect-timeout 3 http://localhost:8000/
curl -6 -v --connect-timeout 3 http://localhost:8000/
curl -v --connect-timeout 3 http://localhost:8000/

Параметры curl -4 и -6 запрашивают адреса только IPv4 или только IPv6 для имен хостов. В документации отмечается, что macOS может возвращать отображенные на IPv4 адреса (IPv4-mapped) при запросе разрешения только по IPv6, поэтому рассматривайте эти тесты как ограниченные попытки подключения через curl, а не как полный аудит поведения системного резолвера для каждого приложения. (Руководство curl)

Используйте полученные результаты для сужения круга возможных причин. Если прямой тест IPv4 работает, а прямой тест IPv6 завершается ошибкой, при этом lsof показывает прослушиватель только для IPv4, то, скорее всего, сервер необходимо настроить на прослушивание IPv6, если требуется доступ по IPv6. Обратное верно, если работает только прослушиватель IPv6. Если оба прямых теста успешны, но localhost не работает, сравните результаты curl с принудительным выбором семейства и проверьте настройки имени хоста, прокси или URL приложения. Различные приложения могут разрешать имена или подключаться к ним по-разному; Apple рекомендует разработчикам использовать независимые от семейства адресов сетевые API для создания приложений, работающих с IPv4 и IPv6. (Apple Developer: Поддержка сетей только с IPv6)

4. Примените исправление в соответствии с выявленными данными

Если подключения принимает только один петлевой адрес, измените конфигурацию адреса привязки (bind-address) локального сервера или используйте то семейство адресов, которое он фактически поддерживает. Не думайте, что изменение настроек IPv4 или IPv6 для Wi-Fi на Mac исправит работу прослушивателя на петлевом интерфейсе: петлевые запросы направлены на сам Mac, тогда как эти сетевые настройки задают параметры соединения физического или беспроводного интерфейса. Элементы управления TCP/IP в Apple позволяют настроить IPv4 и IPv6 для выбранной сетевой службы, но они не управляют сокетом прослушивания отдельного приложения. (Служба поддержки Apple: Изменение настроек TCP/IP на Mac)

Если ни один прямой адрес не работает, убедитесь, что сервер запущен, порт указан правильно, а ожидаемый протокол — HTTP или HTTPS. Если один прямой адрес работает, но результаты для имени хоста различаются, используйте адрес из lsof вместе с выводом curl, чтобы решить, что корректировать: адрес привязки сервера или URL на клиенте. Такая последовательность позволяет отличить отсутствие прослушивателя от проблемы с привязкой к конкретному семейству, не сводя каждый сбой с localhost к проблеме с DNS.

Источники