BmoreITDan

As a follow-up, I discovered the necessary changes: Add an extra_hosts entry to point the domain name to the load balancer. Reason: Our network does not allow for WAN loopback connections. Because of this, when the PHP container attempts to curl https://www.example.com, the DNS server returns the WAN IP for this (since this DNS is not managed internally). Adding an entry of the internal load balancer virtual IP as an extra_hosts entry solved my problem.

For those reading, this means that if your nslookup within the container returns a public / WAN IP, perhaps add an extra_hosts entry to your docker-compose.yml file so your domain name can resolve to an internal IP which can be serviced. for me it was “www.example.com:172.x.x.x” where 172.x.x.x is the VIP for our load balancer. For you this might be an Nginx reverse proxy server. If your site is HTTPS, this IP should point to whichever server is listening for those HTTPS connections.

As for the offending plugin, I was able to find this with the Troubleshooting Mode, enabling each plugin one-by-one then running the healthcheck. The offending plugin essentially caused the entire site to run slow due to poor MySQL query optimization, and because of such, caused the Health Check to timeout before the operation could be completed. Meaning, there was never any issue with the Health Check (other than needing the extra_hosts entry), but instead a crummy plugin caused the site to not run fast enough to complete the Health Check in time. This is an excellent example of why using quality plugins is important.

• This reply was modified 6 years ago by BmoreITDan.

Apologies, I should mark this as resolved. Somewhere along the way, I did not test this with all plugins disabled. Re-testing this with all plugins disabled returned a successful loopback request.

Once I identify the offending plugin, is there a way to determine which portion of code is causing this loopback test to fail?

Thanks for that. I’m not sure this helps me much. I did read through all the headers and posted info with the code above. Nothing indicated any errors, 404, 301, or any other issues I could pick out. Everything looks good to me. How does the Health Plugin call the curl php function? Can I simulate that with a script?

I wouldn’t feel comfortable sharing my docker-compose.yml file. I don’t have any issue with making hosts file changes. I have thoruoughly tested all different variations with dns resolutions, including pointing the domain name to 127.0.0.1, to the internal LB, to the reverse proxy. I can easily get “curl -v https://localhost” and “curl -v https://www.example.com” to return valid page data, but not a single time during any of those configurations can I get the Health Check plugin to not display a loopback issue.

Again, I can successfully bash into the PHP container, make a simple host file change, run curl successfully, but the Health Check plugin still shows an error. Would it be possible to extract the exact curl php command used by the plugin? I can manually run the php command or make a script to do so, which I can further troubleshoot.

This is important to my customers.

This doesn’t quite work still. My URL in the Settings > General > WordPress Address is “https://www.example.com”. If I add example.com and https://www.example.com to the list of DNS names which resolve to 127.0.0.1, running “curl -v https://www.example.com” (from within the container directly) reports a 301 redirect, while running “curl -v https://www.example.com” properly returns the page. Nevertheless, the Health Check update still reports that curl timed out. So how do I get

Hi,
I am having the same exact issue using the latest version of CF7 and WP. EXACT SAME. Although it is certainly within my capabilities to manipulate the CSS and HTML to make this appear correctly, I want to present it to the CF7 because it is definitely a formatting error which exists in this version. I also cannot show it to you as I cannot leave this error on my live site.
Thanks,
Dan