Last updated by Sascha Brockel on 17 April 2021
For months I had cURL error 28 in my WordPress instance and with it the problem that I had loading times of 30 seconds to one minute for calling a single page in the whole dashboard respectively jp-admin area.
I have really tried everything and then for a long time also had no more time and at some point also lost the desire, because the direct calls through caching plugins were still fast and thus not noticeable for the visitor. By chance I then came across the solution.
For quite a lot of POST calls I have the said error cURL error 28: Resolving timed out after 3000 milliseconds get. The milliseconds were of course different for some calls. Some plugins showed me the problem, but also internal WordPress functions. In the following image this is well illustrated.
Due to cURL error 28 no background updates were running anymore. That is, not a single cronjob ran and thus was not checked for updates, plugins sent no more emails and more. Only if you manually triggered the functions quasi by browsing in jp-admin.
I have also turned to plugin developers with the problem, since their plugins have occasionally caused exactly the same error. But they couldn't help me there either. On a Linux server, the DNS settings should be checked first.
Several free WordPress plugins are used for verification. The most important plugin is the one shown in the picture Query Monitor with which you can debug your website very well. You navigate through your website and especially in the jp-admin area and can see under HTTP API calls, which calls were made and how long they took. Also errors like cURL error 28 can be easily detected.
Also helpful is the plugin Health Check & Troubleshooting with which critical errors or recommended improvements are displayed. Among other things, I was told that my REST API had a bug.
These two plugins are good for detecting known or even unknown problems.
Solution for cURL error 28
The solution to the problem in my case is so incredible that I still can't believe it. The cause was my router. I have a slightly older FRITZ!Box in operation. After entering new dial-up data, I already noticed that the WLAN now has connection interruptions. At Christmas I wanted to connect a LED light chain controller via WLAN, but this could not be found. In other WLAN networks this worked very well.
Years ago I had a similar case with the same FRITZ!Box. The FRITZ!Box seems to fill up with WLAN devices after a certain time or to crash due to updates. So I reset everything once to factory settings and manually reconfigured everything. No sooner said than done and suddenly I was surprised that I could browse in jp-admin so fast again.
Another indicator for an improper FRITZ!Box is the ERR_NO_MEMORY Error. This occurs when you want to call the user interface of the FRITZ!Box. You can fix this by disconnecting the power for a short time, but then you already know that something is wrong.
It was really only due to the FRITZ!Box, whose configuration seemed to be faulty. The server is directly connected to the FRITZ!Box. There were no problems in any other Docker container. Every service ran flawlessly, whether in Docker or outside. Only WordPress would no longer work flawlessly. The Linux system itself didn't make any semblance of an error either. Coming up with that is probably rather impossible.
I hope I can help some people with this who also have the said cURL error 28. It's not a guarantee that this is the reason, as it could be anything from incorrect DNS setting on the server to internal WordPress files. However, as a last step, I would definitely recommend you to do this. It's worth a try with other routers as well.
Before resetting your router, make a backup file just in case and take pictures of the most important settings. In a case like mine, you should completely recreate the configuration and not load a backup, otherwise you will load the errors again.