Web server hangs intermittently
I'm having a bizarre problem with certain websites hosted on my server. Apache 2.2.24, PHP 5.4.21, cPanel 11.38.2 (build 11), firewall is csf+lfd.
Intermittently, when a user loads a particular site, that site will hang and fail to display. For one site in particular, the problem scenario is as follows:
1. User loads "http://mydomain.com" in browser.
2. mod_rewrite changes the protocol to https.
3. index.php checks for logged in status and, if the user is not logged in (usual status), redirects to login.php via PHP's header("Location") function.
Sometimes login.php loads. Sometimes it doesn't.
In examining apache domlogs for that domain, we find that the GET request for / results in a 302 status, which is "temporary redirect":
The next entry should then be a GET request for /login.php that results in 200 status.
When login.php loads, that is indeed the next entry. But when it fails, there's no record of the second GET request in the log. There is nothing notable in apache error_log, nothing in the site's PHP error_log. When I check the site's suphp_log, it appears that index.php is being executed each time, but nothing is being received back at the browser. This is browser and local-network independent, as I have tested it from multiple locations using the major browsers--all have this problem. I have tried this without the mod_rewrite directive also, relying instead on a PHP redirect to ensure we were in HTTPS, but there was no difference. I've tried everything I can think of to resolve this, but nothing works. Any suggestions about what could be causing this?
999.999.999.999 - - [24/Oct/2013:18:04:44 -0400] "GET / HTTP/1.1" 302 - "-" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"The next entry should then be a GET request for /login.php that results in 200 status.
999.999.999.999 - - [24/Oct/2013:18:04:44 -0400] "GET /login.php HTTP/1.1" 200 6698 "-" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"When login.php loads, that is indeed the next entry. But when it fails, there's no record of the second GET request in the log. There is nothing notable in apache error_log, nothing in the site's PHP error_log. When I check the site's suphp_log, it appears that index.php is being executed each time, but nothing is being received back at the browser. This is browser and local-network independent, as I have tested it from multiple locations using the major browsers--all have this problem. I have tried this without the mod_rewrite directive also, relying instead on a PHP redirect to ensure we were in HTTPS, but there was no difference. I've tried everything I can think of to resolve this, but nothing works. Any suggestions about what could be causing this?
-
Hello :) Is this only happening for one specific PHP script, or is it happening to other scripts on the server? It sounds like there may be an issue with the script itself that will need to be troubleshooted. Is it a custom script, or one that is available to the public? Have you tried reproducing the issue without using https at all? Thank you. 0 -
This has been a problem for a number of sites on our server, although the one in question is by far the highest volume and most critical customer. It is not confined to any PHP script in particular. The PHP scripts in question are all custom scripts, but they include simple redirects. Most importantly, they all functioned fine until we performed a series of upgrades about a month ago. I turned off the SSL requirement for these scripts as a test, and while there was still some unusual latency, the overall issue appears to go away. Obviously we can't just not use SSL, though. Is there a log I can examine to help pinpoint the issue? Is there some misconfiguration in the SSL? 0 -
Further testing via wireshark and tracert revealed that certain IPs on the server--all of which were associated with the affected domains as dedicated IPs--were being blocked at datacenter level. We've resolved the issue for our users by moving them to different IPs and will be having a discussion with the server provider about resolving the issue for the bad IPs. Thanks for your help focusing the issue. 0 -
I am happy to hear you were able to resolve the issue. Thank you for updating us with the solution. 0
Please sign in to leave a comment.
Comments
4 comments