Troubleshooting intermittent problem with a specific site?

[DoYouKubuntu]

NOTE: I had no idea where to post this...any more. Before, I would've stuck it in the Miscellaneous Linux Info board ITSELF, not in one of its subsections, but I can't do that now.

Anyway, here's the story. There's a specific web site, TexasPhotoRoundup.com, that inexplicably becomes unreachable for SOME people. It really looks like a regional problem, but I have no idea WHAT problem. When it first started [a couple weeks ago] it was limited to people using AT&T's Uverse cable Internet in Texas, so it looked pretty straightforward that the problem was at AT&T's end, despite their saying there was nothing wrong. (Anyone remember *MY* issues with AT&T?! So, yeah. Whatever.)

Now it's happening with other ISPs, including Time Warner cable--but only regionally--so the AT&T idea kind of went out the window. Specifically, people in Austin and Houston are having problems accessing the site, while people [including myself] in California are not, even though we're using the same ISP [in my case, Time Warner/Earthlink].

My daughter, in Austin, needs to access it--and always can, via her smartphone's 3G, but not always via her ISP [Uverse]. She's on Mac, but since it's UNIX, too, I've had her run various things including traceroute and ping, and try going through a proxy server.

Right now, traceroute yields an 'unknown host' [I think] for her, while I get:

# traceroute texasphotoroundup.com                                                                     
traceroute to texasphotoroundup.com (173.248.188.91), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  1.225 ms  2.252 ms  2.300 ms
 2  user-118bis1.cable.mindspring.com (66.999.999.129)  25.535 ms  25.828 ms  33.226 ms
 3  cpe-76-167-21-193.socal.res.rr.com (76.167.21.193)  18.396 ms  18.728 ms  19.054 ms
 4  tge0-9-0-1.lamdca1-cr02.socal.rr.com (72.129.9.232)  33.469 ms  33.909 ms  34.076 ms
 5  agg28.tustca1-cr01.socal.rr.com (72.129.9.2)  26.594 ms  26.933 ms  27.293 ms
 6  107.14.17.134 (107.14.17.134)  22.014 ms  16.136 ms  15.824 ms
 7  ae-1-0.pr0.lax00.tbone.rr.com (66.109.6.129)  17.057 ms  21.726 ms  22.037 ms
 8  xe-4-2-0.edge1.LosAngeles6.Level3.net (4.26.0.77)  103.168 ms xe-7-2-0.edge1.LosAngeles6.Level3.net (4.26.0.21)  115.295 ms xe-7-1-0.edge1.LosAngeles6.Level3.net (4.26.0.25)  115.694 ms
 9  vlan60.csw1.LosAngeles1.Level3.net (4.69.144.62)  26.282 ms  24.200 ms vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254)  109.332 ms
10  ae-62-62.ebr2.LosAngeles1.Level3.net (4.69.137.17)  102.191 ms ae-82-82.ebr2.LosAngeles1.Level3.net (4.69.137.25)  23.033 ms ae-62-62.ebr2.LosAngeles1.Level3.net (4.69.137.17)  102.745 ms
11  ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202)  41.938 ms  42.295 ms  42.594 ms
12  ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142)  36.717 ms  37.282 ms  37.781 ms
13  ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  33.597 ms  33.978 ms  34.470 ms
14  ae-3-3.ebr1.Denver1.Level3.net (4.69.132.58)  80.008 ms  89.851 ms  79.915 ms
15  ae-1-51.edge3.Denver1.Level3.net (4.69.147.72)  74.455 ms  72.205 ms  73.646 ms
16  HANDY-NETWO.car1.Denver1.Level3.net (4.53.12.246)  100.142 ms  100.035 ms  97.627 ms
17  vlan10.core2.denver2.wehostwebsites.com (68.71.128.145)  100.603 ms  95.590 ms  100.319 ms
18  173.248.188.91 (173.248.188.91)  111.252 ms  94.707 ms  95.016 ms

She CAN ping it [today--in the past, no] and get back 0% packet loss, however her times [in milliseconds] are much slower than mine.

She CAN connect to the site by going through a proxy server.

She CAN connect to the site using her phone's 3G service.

She CANNOT connect to it [right now] via her normal method on her computers, i.e., Uverse cable over wireless.

But the problem comes and goes, with no [apparent] rhyme or reason. She'll LITERALLY be in the middle of doing something on the site and then she'll lose access to it. And that's how it's going for other visitors as well.

Any help on how to troubleshoot this issue would be greatly appreciated. BTW, the web hosting company [MDDHosting] denies any issues at their end, the ISPs involved deny any IP blocking at their ends, and so on. I know it's on Linux...so, there, we have a very loosely related Linux question!

[Snowhog]

NOTE: I had no idea where to post this...any more. Before, I would've stuck it in the Miscellaneous Linux Info board ITSELF, not in one of its subsections, but I can't do that now.

Because we care about our members, your wish was my command. Miscellaneous forum created under Miscellaneous Linux Info.

[DoYouKubuntu]

Because we care about our members, your wish was my command. Miscellaneous forum created under Miscellaneous Linux Info.

Now THAT'S what I call good service!

[lcorken]

Are you using opendns? I use opendns because the dns lookup is a lot faster than my ISP (charter).

I once had a site become suddenly unreachable. It turned out that after a router restart I got an IP that someone else had at opendns. Opendns alows you to block websites for parental control or whatever. This can sometimes be a problem with dynamic IP. If you are using opendns let me know and I will try to find the page that explains that and has a fix.

edit: Google also has public dns servers. And I think some ISPs also alow site blocking.

Ken.

[DoYouKubuntu]

But the problem only exists for SOME people, in SOME locations, SOME of the time, so what they are/aren't using [opendns vs their ISP, for example] can't be the problem. As I said, my daughter AND other random people in Texas will be using the site and then lose access to it, literally WHILE using it.

[SteveRiley]

It's worth investigating DNS issues, at least a little. DNS records include a time-to-live (TTL) value. Sometimes this is ignored by caching or forwarding DNS servers. At the moment someone loses connectivity, try opening a command shell and running dig FQDN-of-host. If it fails, you'll have found a problem. Next, try dig @4.2.2.1 FQDN-of-host. This redirects resolution to Verizon's primary DNS server, which always seems to be up. If it succeeds, then you'll be even closer to a solution.

[DoYouKubuntu]

Thanks, Steve. The event the web site is promoting happens tomorrow, so if I hear from my daughter again that she's lost access to it, I'll have her try your suggestions.

[wizard10000]

Put the site in /etc/hosts just for fun. If the problem goes away it's DNS - if it doesn't it's something else

Don't forget to remove the entry from hosts when you're done messing around.

[SteveRiley]

Why take the simple route when a more complicated method will do the same thing?

[DoYouKubuntu]

Great ideas, guys, but kindly keep in mind that it's not me who's having the problem--it's random people, some of whom are probably using 'doze [though most are likely on Mac], and most of whom wouldn't have a clue what /etc/hosts is or how to edit it--or that they NEED to edit it. They're just people out there trying to access a site...that's here, then not here, then here...

[SteveRiley]

Checking DNS is still a valid troubleshooting step for any user experiencing a problem. The dig command will work on any Linux (and probably a Mac, too, but I dunno squat about no fruity computers). For Windows, the equivalent commands would be nslookup FQDN-of-host and nslookup FQDN-of-host 4.2.2.1.

[wizard10000]

Why take the simple route when a more complicated method will do the same thing?

I had a problem like this today. Website load time ran anywhere from 2-50 seconds, but the time from first element on the page loading until the page completely loaded was always < 2 seconds. apache was humming along, mysql had no issues so I thought DNS until the /etc/hosts trick didn't make things any better - then I looked at the code on the page and saw it calling google-analytics. Commented out the line calling google and the page straightened right up.

[DoYouKubuntu]

Checking DNS is still a valid troubleshooting step for any user experiencing a problem.

I know--but other than my daughter I don't KNOW any of the random people experiencing this problem. So there's no way to tell them to check DNS issues in order to be able to access the site.

The dig command will work on any Linux (and probably a Mac, too, but I dunno squat about no fruity computers).

Hey--at least they're UNIX!

For Windows, the equivalent commands would be nslookup FQDN-of-host and nslookup FQDN-of-host 4.2.2.1.

Again, I can't tell any potential windoze users to try that, since I don't know who they are.