Skip to content

Nuface Blog

隨意隨手記 Casual Notes

Menu
  • Home
  • About
  • Services
  • Blog
  • Contact
  • Privacy Policy
  • Login
Menu

Fixing WordPress REST API Error: cURL Error 28 in Docker Environments

Posted on 2025-11-022025-11-04 by Rico

When running WordPress, you might encounter this warning in your Site Health Check page:

REST API Error
The REST API is one way WordPress and other applications communicate with the server.

Error: (http_request_failed) cURL error 28: Connection timed out after 10001 milliseconds

This message indicates that your WordPress instance failed to communicate with itself through the REST API. This issue is especially common when WordPress is running inside a Docker container or behind a reverse proxy.


🔍 The Symptom

WordPress internally calls its own REST API endpoint (for example, https://www.nuface.tw/wp-json/) to check whether the API is functioning.
If the container cannot resolve its own domain name due to a DNS configuration problem, the request will hang and eventually return:

cURL error 28: Connection timed out after 10001 milliseconds

In simple terms, WordPress is trying to talk to itself—but can’t find itself.


🧠 Root Cause

Inside Docker, containers often use their own DNS resolver, inherited from the Docker daemon.
If your environment relies on an internal DNS server (e.g., 172.16.100.1), but the container doesn’t explicitly know about it, the domain name lookup for www.nuface.tw will fail.
As a result, any loopback REST API request will time out.


🛠️ Step-by-Step Solution

1️⃣ Add Internal DNS to docker-compose.yml

Edit your WordPress service definition and specify the internal DNS:

services:
  wordpress:
    image: wordpress:latest
    container_name: wordpress
    restart: always
    ports:
      - "80:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: yourpassword
      WORDPRESS_DB_NAME: wordpress
    dns:
      - 172.16.100.1   # Internal DNS server

Then restart your containers:

docker compose down
docker compose up -d

2️⃣ Verify DNS Resolution

Log into the container and test DNS:

docker exec -it wordpress bash
cat /etc/resolv.conf
dig www.nuface.tw

If the domain resolves correctly, your internal DNS is working as expected.


3️⃣ Check the WordPress REST API Again

Go to Tools → Site Health → Status and rerun the test.
You should now see:

✅ REST API is working properly.


💡 Optional Improvements

  1. Set a global Docker DNS configuration
    Edit /etc/docker/daemon.json: { "dns": ["172.16.100.1", "8.8.8.8"] } Restart Docker: systemctl restart docker
  2. Use internal DNS for local services
    If your reverse proxy and WordPress containers share the same network,
    point all internal service names (like db, mail, api) to your internal DNS.

✅ Conclusion

This issue wasn’t caused by WordPress itself but by the Docker network’s DNS configuration.
By making sure your container can resolve its own domain name, you can restore normal REST API functionality—and eliminate the dreaded cURL error 28.


In short:
When WordPress can’t reach itself, check your DNS first.

Recent Posts

  • Enable Logrotate for Dovecot in Docker: Prevent Huge Log Files and Disk Overflow
  • 在 Docker Dovecot 中啟用 Logrotate:避免 log 爆量、磁碟被塞滿的最佳做法
  • How to Choose Suricata RuleSets on OPNsense — Practical Guide & Best Recommendations
  • OPNsense Suricata 使用指南 — 規則(RuleSets)該怎麼選?最佳實務與推薦設定
  • Proxmox VE + Proxmox Backup Server Integration & Cross-Node Restore Guide

Recent Comments

No comments to show.

Archives

  • November 2025
  • October 2025

Categories

  • AI
  • Apache
  • Cybersecurity
  • Database
  • DNS
  • Docker
  • Fail2Ban
  • FileSystem
  • Firewall
  • Linux
  • LLM
  • Mail
  • N8N
  • OpenLdap
  • OPNsense
  • PHP
  • QoS
  • Samba
  • Switch
  • Virtualization
  • VPN
  • WordPress
© 2025 Nuface Blog | Powered by Superbs Personal Blog theme