One user at my site has reported that he reaches the content at /var/www when browsing to any of the vhosts at my server. As far as I’m aware, my Apache server does not contain a document root that references this folder. On top of that, this user seems to be the only one experiencing the issue. According to his ISP, the issue isn’t caused by them, yet, on his mobile connection, he can access the site. When browsing to my server’s IP, he also receives the correct content from the default vhost.

What could be the possible causes of this issue and how can I get it to stop? I’ve explored pretty much every option I could think of.

This question came from our site for computer enthusiasts and power users.

Can you see the client's requests in the server logs? It's likely the mobile client is not sending the correct host in the HTTP requests. You should be able to see this in the Apache logs if you have that log option enabled. If not and you can't enable it you should be able to see it in a packet capture.
–
Nathan VDec 4 '12 at 11:15

5 Answers
5

Did you switch DNS recently? It sounds like the ISP are mistaken, and are in fact caching an old DNS entry. I've run into this a couple of times in the past. Only after the ISP flushed things on their end was the problem resolved.

I told the user to change his DNS servers to Google DNS, flush his DNS cache and try again, but he says he still gets the same results.
–
FHannesNov 28 '12 at 12:40

That's all fine and good, but there is a level of caching that takes place at the ISP. I experienced an issue with an ISP reseller in Wisconsin (in the boonies). They refused to acknowledge that the rest of the civilized world was seeing the new site, but only the client under their wonderful service was seeing the old site. They did something on their end and 24 hours later the problem went away. Just saying...
–
Ian AtkinNov 29 '12 at 8:32

Well, my DNS hasn't changed for over a year, so I doubt it's a caching issue.
–
FHannesNov 29 '12 at 17:40

That's a VERY helpful site, thank you. Aside from the fact that I have a single point of failure, with my DNS located on a single server, it reported that the nameserver in my SOA record is not listed by my parent DNS. Which is true, but this hostname points to the same server that holds my DNS, so that shouldn't be an issue. I've fixed the issues, but I don't think this will resolve the problem.
–
FHannesDec 4 '12 at 18:39

I'd be curious if the user is using a browser that isn't using HTTP/1.1, but rather HTTP/1.0 requests that don't pass the hostname with the request. It sounds as if there's no identifying site information to trigger your web server to serve up the right page, so it's landing on the default web root. Perhaps you could encourage him to attempt a different browser as a troubleshooting step.

If you want to test that theory, you could get his IP and search the logs for it to see what he's sending. If there's any question as to whether he is accessing your site or another, you could attempt to put up a file in /var/www and direct him to that file as a test. Alternatively, you could configure your default webroot to point to a site you host that makes the most sense.

If I recall correctly, he uses Chrome, however, my own software which he uses as well, uses the HTTP protocol to download updates, and this doesn't seem to be working either. The downloaded files are corrupt, so I assume it's just downloading that same wrong page for some reason.
–
FHannesDec 7 '12 at 18:12

On a side-note, my default webroot is not the default apache folder, so I don't understand why it'd even display.
–
FHannesDec 8 '12 at 18:07

Look carefully at all request headers that come from client. It may be some headers sent by his provider's proxy server.

Not exactly same issue but there was a client which has gained access to the admin panel of something just by using a proxy server. His proxy sent the X-Forwarded-For: 192.168.0.something header which was taken as the real IP address by server software. And it turned out that admin access was only restricted by local IP address.