I'm not sure what you mean by virtual hosting on the local computer. Is this http: or file: protocol access?

It has always been my understand that Firefox uses the OS to resolve addresses. (The exception would be if you use a proxy.) So normally the OS checks the hosts file before doing a DNS lookup and supplies that information to FIrefox.

Here is what I have done and how you can duplicate the problem.

I develop a web site on my computer. Since it is called domain.com on the web, I call it domain.dev on my machine. I set up the Apache vhosts file to show the virtual host name as domain.dev and the alias as www.domain.dev, and the directory as /users/me/sites/whatever.

If a request comes to Apache for domain.dev, the /users/me/sites/whatever directory is that site's root directory so far as Apache is concerned.

In my hosts file, I have an entry "127.0.0.1 domain dev". If something comes in port 80 requesting domain.dev, the hosts site causes it to be directed to the local computer, and Apache, listening on port 80, uses /users/me/sites/whatever as that site's root and sends the to the browser.

The result:

If I enter domain.dev into Safari on my local machine, I see my local site. My code contains absolute paths, and Apache handles them correctly. I can test my site.

If I enter domain.dev into Firefox, it uses the default search engine and searches for domain.dev on the web. This cannot have happened if Firefox had read the hosts file.

If I put "localhost" into the browser, I get the first of the four sites I have set up on my computer. The other three are inaccessible with their domain names, which means they are not testable.

Why I have it set up this way is beside the point. Trust me, I can't restructure four sites just to accommodate Firefox's peculiarities on the local machine.

The bug remains. Firefox must read and honor the hosts file before it uses the URL as a search term.

Let's test something.

When you submit something that contains no spaces on the address bar, Firefox typically will check DNS. If DNS returns with no A record, then what you entered will be submitted to your current default search service. This is the keyword service and it can be disabled.

(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.

(2) In the search box above the list, type or paste keyw and pause while the list is filtered

(3) Double-click the keyword.enabled preference to switch it from true to false.

If you test again, do you get the anticipated DNS response?

If you notice Firefox adding a www subdomain, this can be caused by the fixup feature. When you have the keyword service enabled, this isn't relevant, but with that disabled, if you were to enter puppies on the address bar and press Enter, after the initial DNS response that there's no server, Firefox will try www.puppies.com (or whatever is specified in the various preferences whose names start with browser.fixup).

Anyway, if www is getting added, you know that the DNS lookup failed.

Is there anything in connection settings that would cause Firefox to bypass your operating system's internal DNS resolution? You can review that here:

Mac: "3-bar" menu button (or Firefox menu) > Preferences > Advanced > Network mini-tab > "Settings" button

Windows: "3-bar" menu button (or Tools menu) > Options > Advanced > Network mini-tab > "Settings" button

Changing the keyword.enabled setting fixed the problem.

Speculating:

The entries in the hosts file are obviously not on a DNS server. Setting the keyword.enabled option FALSE by itself should only turn off the feature that uses the address field as a search field. It would not give Firefox an additional ability that it did not have before.

Therefore, Firefox already contains the code to look in the hosts file, but it does things in the wrong order:

1. Look up the URL in the DNS server if not found: 2. Send the URL to the default search engine as a search term if not found: 3. Look in the hosts file

This is why setting keyword.enabled false fixes the problem. When keyword.enabled is true, step 3 can never happen. When keyword.enabled is false, step 2 never happens, which has the effect of enabling step 3.

The correct order would be one of the following:

1. Look in the DNS if not found: 2. Look in the hosts file if not found: 3. Send the URL to the default search engine as a search term

1. Look in the hosts file if not found: 2. Look in the DNS if not found: 3. Send the URL to the default search engine as a search term

This was implied before, but I think I can be more explicit: Firefox doesn't read the operating system's hosts file directly. Ever.

In its default configuration, Firefox sends DNS requests to your OS for resolution. Your OS should check the hosts file first since that has precedence, and if a host name is not in the file, then check its upstream DNS service provider.

As a further experiment, do you want to try turning off the fixup feature?

(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.

(2) In the search box above the list, type or paste fixup and pause while the list is filtered

(3) Double-click the browser.fixup.alternate.enabled to toggle it from true to false.

Does that have any effect on Firefox's ability to reach your server?

I was able to reproduce this using Chrome, Opera, and Rekonq on Xubuntu 14.04 (browser ignores hosts file). So I guess this is not only a problem with Firefox. Doesn't make it less annoying, though.

Hi plantron, is it possible you are using a proxy that does its own DNS resolution? Otherwise, I would think the OS would check the hosts file when responding to DNS requests from your browsers.

You're correct, I am using a proxy. But I have also changed my nsswitch.conf so it would check "files" first before "dns".