What is the URL used for the loopback curl check?

The plugin will be attempting to connect to the ‘WordPress Address’ from the admin under Settings -> General.

The way I do it, in a docker-compose setup, is by adding to the PHP container:

extra_hosts:
      - "localhost:172.18.0.1"

iirc, 172.18.0.1 is the default docker gateway and ‘localhost’ is the WordPress Address in my setup (without the http bit at the start).

In case it is helpful here is a link to my docker-compose.yml.

• This reply was modified 6 years ago by Peter Booker.
• This reply was modified 6 years ago by Peter Booker.
• This reply was modified 6 years ago by Peter Booker.
• This reply was modified 6 years ago by Peter Booker.

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

Do you have a docker-compose.yml or more details on your Docker setup? I suspect that you do not want to make the domain point to 127.0.0.1 from within the PHP container but to the web server container instead.

That is the main issue with loopback requests in Docker setups, by default the PHP container does not know how to get from the domain to the correct entry point (web server).

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.

No problem, something simplified in a script you can run directly should allow you to troubleshoot further:

<?php
$r = wp_remote_get( admin_url(), compact( 'cookies', 'headers', 'timeout' ) );
var_dump( $r );

• This reply was modified 6 years ago by Peter Booker.
• This reply was modified 6 years ago by Peter Booker.

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?

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?

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.

I was out for the evening so missed the fun. I am glad you got it working, good job troubleshooting and detailing your findings!