160504 2016-08-03 06:21:29 -0700 Localhost subdomains don't work 2025-09-19 13:18:38 -0700 1 1 1 Unclassified WebKit Page Loading Safari 9 Mac All RESOLVED MOVED https://bugs.webkit.org/show_bug.cgi?id=171934 https://bugs.webkit.org/show_bug.cgi?id=127676 https://bugs.webkit.org/show_bug.cgi?id=232223 https://bugs.webkit.org/show_bug.cgi?id=236049 InRadar P2 Normal --- 1 djeffery webkit-unassigned achristensen annevk ap beidson cdumez contact diogeneshamilton fran fred.wang ggaren github.j gulaschsuppe2 ianopolous jfernandez jjprevite lidel livid marcosc me michael+webkit mikaela mrsebastienleblanc ryan sabberworm webkit-bug-importer yoseduj youennf oldest_to_newest 1216902 0 djeffery 2016-08-03 06:21:29 -0700 Summary: Localhost subdomains (i.e. 'http://mysite.localhost') don't work in Safari. They work ok in all other web browsers (Chrome, Firefox, Opera etc..). I am not sure if this is a Safari/OS X issue or a webkit issue, feel free to close this bug report if that is the case. Steps to Reproduce: 1. Start up a local server that responds to the host header of 'mysite.localhost' on port 8000 (any port is fine) 2. Try to access the site in safari using the url: http://mysite.localhost:8000/ Expected Results: Every other web browser (Chrome, Firefox, Opera etc..) that I have tested will find the server and load the page as expected. Localhost subdomains don't seem to be mentioned in any official spec but the fact that they work in every other browser means that people use them for real-world development. Actual Results: Safari gives the error "Can't find server" Version: Tested on OS X 10.10 and OS X 10.11 with Safari 9.1.2. 1669807 1 contact 2020-07-08 11:04:01 -0700 https://tools.ietf.org/html/rfc6761 suggests that "localhost" can be treated specially and should hardcode localhost names to the loopback address: > "Application software MAY recognize localhost names as special" and: > "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).)." Chrome already support supports / ships this: https://bugs.chromium.org/p/chromium/issues/detail?id=510124 And firefox is working on this: https://bugzilla.mozilla.org/show_bug.cgi?id=1220810 It also appears that some of the web platform tests do test for this and were disabled: https://bugs.webkit.org/show_bug.cgi?id=161142 Any chance of get Safari to get Safari localhost to loopback address ? 1701856 2 webkit-bug-importer 2020-10-27 06:49:00 -0700 <rdar://problem/70720358> 1888203 3 jjprevite 2022-08-01 14:17:54 -0700 This appears to still be an issue in Safari 15.5 To reproduce: 1. `python -m http.server` 2. Navigate to http://anything.localhost:8000/ in Safari 1891927 4 jfernandez 2022-08-17 05:19:46 -0700 This bug doesn't affect the WebKitGtk+ port. At least, the test case described in comment c#3 works as expected in the mentioned WebKit port. 1892718 5 ap 2022-08-20 15:45:45 -0700 This is mostly something to fix in underlying networking libraries. As long as "ping mysite.localhost" doesn't work in Terminal, I wouldn't expect Safari to behave any differently. WebKit side of this is to make sure that this doesn't let websites work around any security or privacy mitigations we may have around talking to localhost. 1892720 6 livid 2022-08-20 15:57:02 -0700 If *.localhost can get implemented in the underlying network layer, it would be pretty useful in an IPFS context. Currently, with Chrome, I can access a decentralized website hosted on IPFS + ENS like this: http://uniswap.eth.ipns.localhost:18181/ http://planetable.eth.ipns.localhost:18181/ In the example above, localhost:18181 is the local IPFS gateway port. It would be awesome if it could work in Safari too. 1895298 7 jfernandez 2022-08-31 15:00:06 -0700 Not only Chrome, but Firefox and any WebKitGtk+ port browser are able to access localhost subdomain (like the test case in comment #3). Since Safari is the only one behaving differently, would it make sense to fix this in the Networking layer for the shake of ensuring browser interoperability ? 1958961 8 yoseduj 2023-05-30 23:59:15 -0700 I just came here to say that is May 2023 and in Safari 16.4 is still a problem. 1958962 9 yoseduj 2023-05-31 00:00:16 -0700 (In reply to Andrés from comment #8) > I just came here to say that is May 2023 and in Safari 16.4 is still a > problem. This avoid us to properly debug and develop in Safari. Is unfortunate. 1960077 10 ianopolous 2023-06-06 09:34:33 -0700 We also need this for Peergos, another P2P app - https://github.com/Peergos/Peergos/issues/1044 It would be great to support this like Firefox and Chrome. 1960126 11 lidel 2023-06-06 13:46:50 -0700 This continues to pose a challenge for IPFS gateway implementations that require Origin isolation (https://specs.ipfs.tech/http-gateways/subdomain-gateway/). The lack of subdomain support on localhost specifically impacts macOS Safari users, preventing them from achieving per-website Origin isolation and reducing their overall security. Examples in https://github.com/ipfs/in-web-browsers/issues/206 Not supporting localhost subdomain functionality in WebKit introduces a risk for end users, particularly in web applications and PWAs that store sensitive user data in localStorage scoped per Origin. Firefox and Chromium do not encounter this issue since they now bind localhost to the loopback and bypass the DNS resolver provided by the operating system. As a result, their users can load websites from the local gateway, where each website has its own Origin: http://en.wikipedia-on-ipfs.org.ipns.localhost:8080/wiki/ http://bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze.ipfs.localhost:8080/wiki/ 1973838 12 gulaschsuppe2 2023-08-27 14:32:01 -0700 For anyone stumbling upon this, subdomains work in safari after you add them in the `/private/etc/hosts/`: sudo nano /private/etc/hosts Then add your subdomain: 127.0.0.1 sub.localhost It is cumbersome, but still helpful if you don't want to switch away from Safari. 1999524 13 jfernandez 2023-12-14 03:41:04 -0800 Some updates on this bug; the issue is still reproducible in MacOS Ventura 13.4 with Safari 16.5. However, it seems it's not reproducible in MacOS Sonoma 14.2, either with Safari 17.1.2 and Safari Technology Preview 184. I assume some changes in MacOS, as suggested in comment #5, have caused this bug to be FIXED, or at least not reproducible any more. Hence, I think we can close this bug now. 1999599 14 ryan 2023-12-14 08:46:36 -0800 I may be missing something, but I'm still reproducing this on Sonoma 14.2 with Safari 17.2 (19617.1.17.11.9). Is it possible that you have adjusted your /etc/hosts file, Javier? 2000364 15 jfernandez 2023-12-18 04:11:44 -0800 (In reply to Ryan Hiebert from comment #14) > I may be missing something, but I'm still reproducing this on Sonoma 14.2 > with Safari 17.2 (19617.1.17.11.9). Is it possible that you have adjusted > your /etc/hosts file, Javier? Umm, I admit that further testing made me doubt the issue has been fixed. I need to devote more time to investigate it. Reopening for now. 2002370 16 michael+webkit 2023-12-31 17:35:54 -0800 It seems from my testing that Safari uses macOS's default DNS resolution for `*.localhost`, which goes like: 1. check /etc/hosts (which doesn't support wildcards) 2. use the default network DNS server, provided by the network interface settings This number 2 step is dependent on the good graces of your ISP or router hardware. Mine happens to resolve `*.localhost`, but that seems to be hit-and-miss, and unrelated to the client macOS version. You can check yours with `dig example.localhost` for your default DNS server, or `dig @1.1.1.1 example.localhost` for an explicit query to a specific DNS server (like `1.1.1.1` or `8.8.8.8`). Failed queries look like `status: NXDOMAIN`. Success has `status: NOERROR` and an `ANSWER SECTION:` with `example.localhost <expiry> IN A 127.0.0.1`. As mentioned earlier, Firefox and Chromium-based browsers have builtin code that bypasses the default resolution for `*.localhost` and always return `127.0.0.1` in that case. 2022640 17 mrsebastienleblanc 2024-03-20 21:34:59 -0700 Still not fixed in 2024 on Sonoma 14.4 / Safari 17.4 2117057 18 diogeneshamilton 2025-05-14 08:53:36 -0700 Just ran into this after switching my main browser to Safari... come on Apple! 2144481 19 github.j 2025-09-19 12:34:30 -0700 This seems to be fixed in macOS 26 Tahoe ✅ Repro: 1) Run `python3 -m http.server 8000` from a macOS terminal 2) Visit http://foo.bar.localhost:8000 in Safari In macOS 15.7: It fails with "Safari can't find the server "foo.bar.localhost"" In macOS 26.0: It works 🎉 2144500 20 ap 2025-09-19 13:18:38 -0700 Indeed, this was implemented in OS frameworks below WebKit.