New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 224215 link

Starred by 14 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Apr 2013
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocked on:
issue 117850

Sign in to add a comment

Can't access a local webserver anymore

Reported by, Mar 27 2013

Issue description

Chrome Version       : 26.0.1410.43
OS Version: OS X 10.8.3
URLs (if applicable) : -
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 4.x: OK
     IE 7/8/9: OK

What steps will reproduce the problem?
1. php -S localhost:8000
2. open http://localhost:8000/

Or any other steps to run a webserver on localhost.

What is the expected result?

Connect to localhost.

What happens instead of that?

Chrome can't connect to localhost.

This stopped working with the update to Chrome Version 26.0.1410.43.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31

I figured out that the following works:

$ php -S
$ open http://localhost:8000/

But using "localhost" instead of "" doesn't:

$ php -S localhost:8000
$ open http://localhost:8000/

Result: Error 102 (net::ERR_CONNECTION_REFUSED)

Using "localhost" to start the local webserver work in every browser, except Chrome 26.

Comment 2 by, Mar 27 2013

Labels: Cr-Internals-Network-DNS Cr-Internals-Network
I'm guessing that the reason is that:
1) php -S localhost:8000 listens on ::1 (IPv6 loopback)
2) getaddrinfo(localhost, AF_UNSPEC) returns [::1,]
3) chrome can connect to ::1

But you most likely had the built-in DNS resolver enabled and therefore in step 2.
2) built-in DNS found in /etc/hosts and returns []
3) chrome cannot connect to

Therefore, when you tell php in step (1) to listen on, the connection works.

To confirm this theory please go to chrome://flags and set "Built-in Asynchronous DNS" to "Disabled", then restart the browser and see if the first scenario works.
Thanks for your reply! Setting the "Built-in Asynchronous DNS" to "Disabled" indeed fixes the issue.

I think that this will lead a lot of people using build in web servers for PHP, Rails etc. development into confusion. Especially since most people do not even realize that Chrome was updated and this behavior has changed.

Thanks again for your help!

Comment 4 by, Mar 27 2013

Blockedon: chromium:117850

Comment 5 by, Mar 27 2013

Confirmed that this broke between 10.8.2 and 10.8.3, and that disabling built-in asynchronous DNS fixes the issue using AppEngine at localhost:8080.

Comment 6 by, Mar 27 2013

szym:  This seems like a pretty significant issue to me, and I don't think we want to be encouraging people to disable the async resolver, since it has performance benefits.  Do you think it's worth disabling it on M26?  Not sure we could get merge approval for a fix.

Comment 7 by, Mar 27 2013

Or is it not launching in M26?  Don't think we'd have any trouble getting a patch in M27.

Comment 8 by, Mar 27 2013

The trial is disabled on M26 so no immediate action required. However, I'd
to merge into M26 so we can launch as planned.
I might be misunderstanding the comments above about things being disabled and thus not significant, but for me and my colleagues, Chrome Stable has updated to 26.0.1410.43 (OS X) yesterday/today, we all had the "Built-in Asynchronous DNS" flag set to "Default" and connecting to localhost (specifically to servers running using the appengine SDK) now fails. (Changing the flag to Disabled does indeed fix the problem.)

Comment 10 by, Mar 28 2013

That is a bug. The feature is not supposed to be enabled yet on stable. I'm
on it.

Comment 11 by, Mar 28 2013

Status: Assigned
Thanks again for reporting the problem here.

We have taken steps to ensure the feature is disabled on the Stable channel for the time being.

We have also fixed the problem ( Issue 117850 ) on Canary.

Thank you szym for your quick action on this issue.

Comment 13 by, Apr 1 2013

Would you be able to verify that the issue is fixed in the Canary?
szym, how can I verify it? I manually disabled built-in asynchronous DNS as you recommended it and my Chrome version is still the same (no auto update).
Still facing the issue with Canary Version 28.0.1468.0 on my side with at least Google Appengine, on Mac OS 10.8.3.

With the built-in DNS flag set to default: "Oops! Google Chrome could not connect to localhost:9100"
With the built-in DNS flag set to disabled: works like a charm

Screen Shot 2013-04-08 at 10.19.45 AM.png
75.5 KB View Download
Screen Shot 2013-04-08 at 10.20.33 AM.png
13.6 KB View Download
Screen Shot 2013-04-08 at 10.20.55 AM.png
31.4 KB View Download

Comment 16 by, Apr 8 2013

I cannot reproduce with Google App Engine (works as expected) with Canary 28.0.1469.0.

brieuc.schaff: When this happens, could you run:
netstat -anp tcp | grep LISTEN

It'd help to see what address/port the server is listening on your host. Could you also follow: 
Yesterday after working all day with App Engine, in the end I was not able to reproduce the issue. 

This morning however, after turning on the computer I can reproduce it again every time with the DNS setting on Default. Not sure this helps.

I've attached the netstat file and the dump from the net-internals tab in Canary. Let me know if you need anything else.

1.3 KB View Download
82.6 KB View Download

Comment 18 Deleted

I can reproduce this bug on ChromeOS 26.0.1410.57 (Official Build 191765) beta

(platform 3701.81.0 (Official Build) beta-channel x86-alex_he).

Is there a workaround for chromebooks?

Comment 20 by, Apr 9 2013

Status: Started
Re: #17, "Default" settings means eligible for experiments. On Mac Canary, you have 50% chance of having the feature enabled. 

Thanks for the logs. It looks like the problem is that Chrome thinks you don't have IPv6 support (you can see it in chrome://net-internals/#dns under "Default address family"). However, even if you don't have a global IPv6 address, your loopback IPv6 works just fine, and that's why GAE dev server listens on ::1.

Re: #19, How exactly are you running a server on a ChromeOS?

The primary workaround is to navigate to<port> rather than localhost:<port>. Alternatively, ensure that your development server starts on rather than ::1.

@szym I am running the webserver on the local network on another computer.

Comment 22 by, Apr 9 2013

@starbeamrainbowlabs: Could you follow

Please test twice: with the "Built-in Asynchronous DNS" flag in chrome://flags set to Enabled and Disabled.

Comment 23 by, Apr 9 2013

brieuc.schaff: I'm trying to diagnose how come the IPv6 detection issue is not affecting you when the Built-in Asynchronous DNS is disabled.

With the flag set to "Disabled" in chrome://flags, could you record and post a net-internals-log as you did in #17.
Here is the dump with the Built-in Async DNS set to disabled, loading my appengine app.

47.2 KB View Download

Comment 25 by, Apr 10 2013

Thanks! It looks like even though IPv6 is presumed absent, getaddrinfo still returned [::1] among others. I'll investigate.

Comment 26 by, Apr 10 2013

I have confirmed that on Mac OS X, getaddrinfo("localhost", ai_family=AF_INET) returns [::1,, fe80::1].

@#22 Never mind, I can't repro anymore must have been a glitch that fixed itself.

Very odd though.

Comment 28 by, Apr 12 2013

Turns out this is a regression on
We should add a test for that.
Project Member

Comment 29 by, Apr 17 2013

r194663 | | 2013-04-17T20:05:59.236820Z

Changed paths:

[net/dns] Add test DualFamilyLocalhost and fix it when DnsClient enabled.

On some platforms, listening on "localhost" binds to the IPv6 loopback
(::1), even if there's no global IPv6 connectivity. In such situations,
HostResolverImpl restricts lookups to IPv4 (AF_INET) for performance
reasons, but then navigating to http://localhost results in "connection

HostResolverProc has a workaround for this situation. This CL adds a
test for this behavior and replicates the workaround in
HostResolverImpl::ServeFromHosts (for the built-in asynchronous DNS).

BUG= 224215 

Review URL:

Comment 30 by, Apr 25 2013

Status: Fixed

Comment 31 by, May 20 2013

Same issue with 26.0.1410.63 (192696) on Linux. Additionally does not work either.

Comment 32 by, May 20 2013

 Issue 117850  was the cause on Linux and the fix is in M27.

However, opening does not involve a DNS lookup, so it is a different issue. Please, follow and file a new bug.

Sign in to add a comment