Загадочный Флажок .dev.localhost
При создании нового проекта ASP.NET Core в Visual Studio есть флажок, который легко пропустить: Use the .dev.localhost TLD in the application URL (Использовать домен верхнего уровня .dev.localhost в URL приложения). Давайте разберёмся, что он делает.
Проблема
Когда вы работаете над несколькими локальными веб-проектами, все они располагаются по одному и тому же адресу
localhost. Различить их можно только по номеру порта. Если у вас в работе 3 проекта, то в браузере может быть localhost:5001, localhost:5215, localhost:7099 — и вы не будете знать, какой из них какой, пока не посмотрите на страницу.Есть вторая, менее заметная проблема: поскольку все используют имя
localhost, файлы cookie и другие хранилища браузера, привязанные к домену, также используются всеми вашими локальными приложениями. Это обычно нежелательно при тестировании.Что такое .dev.localhost?
.localhost — это зарезервированный домен верхнего уровня, определённый в RFC2606 и RFC6761 специально для локального тестирования. Современные браузеры уже разрешают всё, что заканчивается на .localhost, напрямую в локальный адрес (127.0.0.1/::1), поэтому myapp.localhost ведет себя точно так же, как localhost, если только вы не отредактировали файл .hosts или настройки DNS.Начиная с .NET 10, ASP.NET Core развивает эту идею и добавляет полноценную поддержку поддомена
.dev.localhost. Шаблоны проектов для ASP.NET Core Empty и Blazor Web App могут объединить имя вашего проекта с этим суффиксом, поэтому вместо:https://localhost:7099
вы получите:
https://myapp.dev.localhost:7099
Для этого и флажок. Настройка также доступна из командной строки, если вы не используете мастер Visual Studio:
dotnet new web -n MyApp --localhost-tld
Примечание: Kestrel распознаёт адреса
.localhost. Когда ваш профиль запуска или ASPNETCORE_URLS указывает на имя .dev.localhost, Kestrel привязывается только к локальному адресу (127.0.0.1/::1), а не ко всем интерфейсам. Он также регистрирует как адрес .localhost, так и обычный localhost при запуске, поэтому оба варианта по-прежнему работают.Зачем?
- Вы сможете различать свои приложения. Название проекта отображается прямо в адресной строке, а не в номере порта, который вам нужно запоминать.
- Никаких конфликтов кук и хранилищ. Поскольку каждое приложение получает свой собственный поддомен, хранилище браузера, привязанное к домену, больше не является общим для всех ваших локальных проектов.
- HTTPS по-прежнему работает «из коробки». Сертификат разработчика ASP.NET Core уже указывает
*.dev.localhost в качестве альтернативного имени субъекта. Вам не нужно ничего дополнительно генерировать — dotnet dev-certs https уже это обеспечивает. Сертификат с подстановочным знаком для *.localhost сам по себе недействителен для домена верхнего уровня, именно поэтому существует поддомен .dev.- Ничего не сломается. Kestrel продолжает прослушивать обычный
localhost, поэтому инструменты или скрипты, которые обращаются к localhost:7099, продолжат работать.Единственная загвоздка: Safari
Safari на macOS не разрешает имена
*.localhost автоматически. Если вы тестируете в Safari, используйте обычный адрес localhost.То же самое относится и к клиентам, не являющимся браузерами. Некоторые HTTP-клиенты и инструменты разрешают имена
.localhost через обычный стек DNS вместо обработки их в особом порядке, и, если ваш DNS не знает, что с этим делать, запрос просто завершится неудачей. В таких случаях продолжайте использовать обычный localhost.Источник: https://bartwullems.blogspot.com/2026/07/the-mysterious-devlocalhost-checkbox.html
