Google Chromeなどの一部ツールは、サブドメイン付きのlocalhostのアドレス（subdomain.localhost）を自動的に127.0.0.1で名前解決してくれます

TL;DR

※2023年6月時点

Google Chromeなどのツールでは、サブドメイン付きのlocalhostのURL（例：http://hoge.localhost:3000）を、自動で127.0.0.1に名前解決してリクエストを行います
一方でSafariなどの一部ツールでは非対応なので、それらでも同様に名前解決したい場合は、別途実行環境のDNSの設定を変更する必要がある
自動的な名前解決が主流のようだが、ツール毎の差分や今後の仕様変更の可能性を考慮するなら、自動的な名前解決に依存しない運用が望ましい

TL;DR
目次
ブラウザやツールによってサブドメイン付きlocalhostの名前変換の仕様が異なる
※実行環境
非対応のツールでは実行環境にDNS設定を行う必要がある
lvh.meというドメインを使えば、非対応のツールでも対応可能だが。。。
RFC 6761での定義
Google Chromeも以前は未対応だった
今後の仕様変更の可能性を考慮するなら、自動での名前解決に依存しない設計が望ましい
参考リンク

ブラウザやツールによってサブドメイン付きlocalhostの名前変換の仕様が異なる

はてなブログのようなユーザー毎に任意のサブドメインを提供するようなサービス（API）を構築する際、ローカル環境（localhost）でも様々なサブドメインに切り替えた動作検証をしたいと思います。

その場合ホストマシンのDNSの設定などを変更する必要があると思いきや、Chromeなどの一部のツールは特にDNS関連の設定を変更しなくても、自動で127.0.0.1に名前解決してリクエストを行いました。

一方でSafariや各プログラミング言語のHTTPクライアントライブラリなどで実行すると、名前解決が行われずに、通信に失敗します。

以下は各ツールでのリクエスト結果です（2023年6月時点）

※実行環境

端末：MacBook Pro(M2)
OS：Ventura 13.4.1

ブラウザ

Google Chrome　→　成功

Edeg　→　成功

FireFox　→　成功

Safari　→　エラー

Postman（APIクライアント）　→　成功

CLI

ping　→　エラー

$ ping hoge.localhost
ping: cannot resolve hoge.localhost: Unknown host

curl　→　成功

$ curl 'http://hoge.localhost:3000/health'
"OK"

$ curl -V
curl 7.88.1 (x86_64-apple-darwin22.0) libcurl/7.88.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.51.0
Release-Date: 2023-02-20
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL threadsafe UnixSockets

HTTPクライアントライブラリ

Dio（Flutter）　→　エラー

flutter: *** DioError ***:
flutter: uri: http://hoge.localhost:3000
flutter: DioError [unknown]: null
Error: SocketException: Failed host lookup: 'hoge.localhost' (OS Error: nodename nor servname provided, or not known, errno = 8)

net/http（Go）　→　エラー

Get "http://hoge.localhost:3000": dial tcp: lookup hoge.localhost: no such host

非対応のツールでは実行環境にDNS設定を行う必要がある

Macであれば、/etc/hostsファイルにドメイン名を追記することでIPアドレスとのマッピングが可能です。

/etc/hosts

127.0.0.1 hoge.localhost
127.0.0.1 fuga.localhost

しかしホストPCに直接設定することになるので、チーム開発などをする際は、設定の差分に気を付ける必要があります。

lvh.meというドメインを使えば、非対応のツールでも対応可能だが。。。

実行環境のDNS設定を変更以外の方法を探すと、127.0.0.1でDNSに登録されているlvh.meというドメインが存在するそうで、それを使えばサブドメインを付けた状態でもループバックアドレスに名前解決できました。

lvh.meというループバックドメイン:Technical tips:Media hub

Safari

ただこのドメインは公的機関など信頼性のある団体ではなく、どこかの個人が管理しているようなので、突然使えなくなったり、情報漏洩などセキュリティ上のリスクが懸念されるので、商用サービスなどでの利用は控えた方が良さそうです。

dns - It is safe to use lvh.me instead of localhost for testing? - Stack Overflow

RFC 6761での定義

なおRFCの「localhost」に関するドメイン名の定義には、以下のように記述されていました。

6.3. Domain Name Reservation Considerations for "localhost."

The domain "localhost." and any names falling within ".localhost." are special in the following ways:

Users are free to use localhost names as they would any other domain names. Users may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address.

Application software MAY recognize localhost names as special, or MAY pass them to name resolution APIs as they would for other domain names.

Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).

Caching DNS servers SHOULD recognize localhost names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve localhost names. Instead, caching DNS servers SHOULD, for all such address queries, generate an immediate positive response giving the IP loopback address, and for all other query types, generate an immediate negative response. This is to avoid unnecessary load on the root name servers and other name servers.

https://www.rfc-editor.org/rfc/rfc6761#section-6.3

.localhost.を含むドメイン名はループバックアドレス（127.0.0.1）で解決することが推奨されているので、この仕様が現時点でのスタンダードのようです。

Google Chromeも以前は未対応だった

またGoogle Chromeに関しては、数年前の時点ではこの自動での名前解決に対応していなかったようで、途中で仕様変更の提案を受けて仕様が変わったようです。

dns - Why does Chrome resolve websitename.localhost as localhost? - Webmasters Stack Exchange

今後の仕様変更の可能性を考慮するなら、自動での名前解決に依存しない設計が望ましい

前述の通り、自動的に名前解決する方針が主流のようですが、各ツールごとに仕様が揃っていなかったり、仕様が変わったりしているのが現状です。

ローカル環境での話なので、そこまで神経質に取り扱う必要は無いかもしれないですが、今後の仕様変更などを考慮するなら、自動での名前解決に依存しない方針で開発を進めた方が良いかもしれません。

参考リンク

RFC 6761: Special-Use Domain Names