github-starred/templates
2
0
Fork 1
mirror of https://github.com/Dokploy/templates.git synced 2026-07-16 04:48:50 -05:00
Code Issues 3.0k Packages Projects Releases Wiki Activity

[GH-ISSUE #128] WordPress Template : REST API and Loopback Requests Failing due to cURL timeout (Error 28) #10083

New Issue
Open
opened 2026-06-07 20:39:29 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-06-07 20:39:29 -05:00
Owner
Copy Link

Originally created by @thepiyushchandwani on GitHub (Apr 27, 2025).
Original GitHub issue: https://github.com/Dokploy/templates/issues/128

To Reproduce

  1. Deploy a WordPress site using the default WordPress Install Template on Dokploy.
  2. Complete the deployment without modifying any isolation or network settings.
  3. Visit WordPress Admin → Tools → Site Health.

You will find two major errors :

  • REST API is not working :
    (http_request_failed) cURL error 28: Connection timed out after 10000 milliseconds

  • Loopback request failed :
    cURL error 28: Connection timed out after 10000 milliseconds

Current vs. Expected behavior

Current Behavior:
After following the steps above, REST API endpoints fail to respond, and loopback requests timeout, breaking several WordPress features such as the Block Editor, scheduled cron jobs, and plugin/theme management.

Expected Behavior:
REST API endpoints and loopback requests should work immediately after a clean deployment without manual intervention, ensuring full functionality of WordPress.

Image

Provide environment information

Operating System : Ubuntu 24.04.2 LTS x86_64
Dokploy : v0.21.8
What application are you trying to deploy : Wordpress

Which area(s) are affected? (Select all that apply)

Docker Compose, Traefik, Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

The site is accessible, but internal cURL requests fail, which seems related to networking setup in the template.

Will you send a PR to fix it?

No

Originally created by @thepiyushchandwani on GitHub (Apr 27, 2025). Original GitHub issue: https://github.com/Dokploy/templates/issues/128 ### To Reproduce 1. Deploy a WordPress site using the default WordPress Install Template on Dokploy. 2. Complete the deployment without modifying any isolation or network settings. 3. Visit WordPress Admin → Tools → Site Health. You will find two major errors : - REST API is not working : (http_request_failed) cURL error 28: Connection timed out after 10000 milliseconds - Loopback request failed : cURL error 28: Connection timed out after 10000 milliseconds ### Current vs. Expected behavior Current Behavior: After following the steps above, REST API endpoints fail to respond, and loopback requests timeout, breaking several WordPress features such as the Block Editor, scheduled cron jobs, and plugin/theme management. Expected Behavior: REST API endpoints and loopback requests should work immediately after a clean deployment without manual intervention, ensuring full functionality of WordPress. ![Image](https://github.com/user-attachments/assets/75cdbebf-8f65-469d-9484-a3efa73634e2) ### Provide environment information ```bash Operating System : Ubuntu 24.04.2 LTS x86_64 Dokploy : v0.21.8 What application are you trying to deploy : Wordpress ``` ### Which area(s) are affected? (Select all that apply) Docker Compose, Traefik, Application ### Are you deploying the applications where Dokploy is installed or on a remote server? Same server where Dokploy is installed ### Additional context The site is accessible, but internal cURL requests fail, which seems related to networking setup in the template. ### Will you send a PR to fix it? No
GiteaMirror commented 2026-06-07 20:39:30 -05:00
Author
Owner
Copy Link

@Siumauricio commented on GitHub (May 11, 2025):

Ok errors related to templates, they are handled in another repository, I will transfer

<!-- gh-comment-id:2869367343 --> @Siumauricio commented on GitHub (May 11, 2025): Ok errors related to templates, they are handled in another repository, I will transfer
GiteaMirror commented 2026-06-07 20:39:31 -05:00
Author
Owner
Copy Link

@JerresonJ commented on GitHub (Jun 2, 2025):

@Siumauricio

I don't think this is strictly a template issue. I am using a raw compose with my own custom WP image, and I am now seeing this issue in WP Health Check on deployments.

Raw Compose - network isolated deployment
Health check now shows it cannot complete loopback or rest api requests. I don't recall this ever showing during any prev tests.

Were any updates released that could be breaking something here?

I'll keep digging into it for a bit.

<!-- gh-comment-id:2931119647 --> @JerresonJ commented on GitHub (Jun 2, 2025): @Siumauricio I don't think this is strictly a template issue. I am using a raw compose with my own custom WP image, and I am now seeing this issue in WP Health Check on deployments. Raw Compose - network isolated deployment Health check now shows it cannot complete loopback or rest api requests. I don't recall this ever showing during any prev tests. Were any updates released that could be breaking something here? I'll keep digging into it for a bit.
GiteaMirror commented 2026-06-07 20:39:32 -05:00
Author
Owner
Copy Link

@thepiyushchandwani commented on GitHub (Jun 4, 2025):

@Siumauricio

I don't think this is strictly a template issue. I am using a raw compose with my own custom WP image, and I am now seeing this issue in WP Health Check on deployments.

Raw Compose - network isolated deployment Health check now shows it cannot complete loopback or rest api requests. I don't recall this ever showing during any prev tests.

Were any updates released that could be breaking something here?

I'll keep digging into it for a bit.

@Siumauricio ,

After some digging, I found a solution that worked for my setup.

Problem

WordPress couldn't properly talk to itself using its public domain from inside the container. This caused issues like:

  • Failed health checks
  • Internal loopback timeouts

Solution

1. Set correct WordPress URLs in docker-compose.yml

Make sure the WordPress container knows its actual public URL:

services:
  wordpress:
    environment:
      WP_HOME: https://yourdomain.com       # Replace with your real domain
      WP_SITEURL: https://yourdomain.com    # Replace with your real domain

2. Add extra_hosts to handle internal loopback

This was the key part.

a. Find your Traefik container's internal IP on the shared Docker network

Run:

docker inspect <traefik_container_name_or_id>

Then look for something like:

"Networks" -> "<your_shared_network>" -> "IPAddress"

Example:

10.0.1.48 on the dokploy-network

b. Add extra_hosts to your WordPress service

Tell your WordPress container that requests to its public domain should route to Traefik's internal IP.

Here's how your docker-compose.yml would look:

services:
  wordpress:
    image: wordpress
    environment:
      WP_HOME: https://yourdomain.com
      WP_SITEURL: https://yourdomain.com
    volumes:
      - ./wp-data:/var/www/html
    networks:
      - dokploy-network     # Replace with your shared network name
    extra_hosts:
      - "yourdomain.com:10.0.1.48"  # Use the Traefik IP you found
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.wordpress.rule=Host(`yourdomain.com`)"
        - "traefik.http.services.wordpress.loadbalancer.server.port=80"
        - "traefik.docker.network=dokploy-network"

Example Configuration

In my case, the working line looked like this:

extra_hosts:
  - "wp.domain.com:10.0.1.48"

Why This Works

When WordPress performs internal actions like cron jobs or health checks, it tries to connect to https://yourdomain.com.

Without extra_hosts: WordPress may try to go out to the public internet and route back in. This could be:

  • Blocked by firewalls
  • Completely fail (especially with no internet access)

With extra_hosts: You force WordPress to resolve the domain to an internal IP (your Traefik container), making the request stay inside the Docker network.

How It Works

  1. WordPress sends a request to https://yourdomain.com
  2. DNS resolves it to 10.0.1.48 (Traefik's internal IP)
  3. Traefik sees it's for yourdomain.com, and forwards it right back to the WordPress container

This keeps everything local, fast, and reliable.

<!-- gh-comment-id:2939244923 --> @thepiyushchandwani commented on GitHub (Jun 4, 2025): > [@Siumauricio](https://github.com/Siumauricio) > > I don't think this is strictly a template issue. I am using a raw compose with my own custom WP image, and I am now seeing this issue in WP Health Check on deployments. > > Raw Compose - network isolated deployment Health check now shows it cannot complete loopback or rest api requests. I don't recall this ever showing during any prev tests. > > Were any updates released that could be breaking something here? > > I'll keep digging into it for a bit. @Siumauricio , After some digging, I found a solution that worked for my setup. ## Problem WordPress couldn't properly talk to itself using its public domain from inside the container. This caused issues like: - Failed health checks - Internal loopback timeouts ## Solution ### 1. Set correct WordPress URLs in docker-compose.yml Make sure the WordPress container knows its actual public URL: ```yaml services: wordpress: environment: WP_HOME: https://yourdomain.com # Replace with your real domain WP_SITEURL: https://yourdomain.com # Replace with your real domain ``` ### 2. Add extra_hosts to handle internal loopback This was the key part. #### a. Find your Traefik container's internal IP on the shared Docker network Run: ```bash docker inspect <traefik_container_name_or_id> ``` Then look for something like: ```json "Networks" -> "<your_shared_network>" -> "IPAddress" ``` **Example:** ``` 10.0.1.48 on the dokploy-network ``` #### b. Add extra_hosts to your WordPress service Tell your WordPress container that requests to its public domain should route to Traefik's internal IP. Here's how your `docker-compose.yml` would look: ```yaml services: wordpress: image: wordpress environment: WP_HOME: https://yourdomain.com WP_SITEURL: https://yourdomain.com volumes: - ./wp-data:/var/www/html networks: - dokploy-network # Replace with your shared network name extra_hosts: - "yourdomain.com:10.0.1.48" # Use the Traefik IP you found deploy: labels: - "traefik.enable=true" - "traefik.http.routers.wordpress.rule=Host(`yourdomain.com`)" - "traefik.http.services.wordpress.loadbalancer.server.port=80" - "traefik.docker.network=dokploy-network" ``` ### Example Configuration In my case, the working line looked like this: ```yaml extra_hosts: - "wp.domain.com:10.0.1.48" ``` ## Why This Works When WordPress performs internal actions like cron jobs or health checks, it tries to connect to `https://yourdomain.com`. **Without extra_hosts:** WordPress may try to go out to the public internet and route back in. This could be: - Blocked by firewalls - Completely fail (especially with no internet access) **With extra_hosts:** You force WordPress to resolve the domain to an internal IP (your Traefik container), making the request stay inside the Docker network. ### How It Works 1. WordPress sends a request to `https://yourdomain.com` 2. DNS resolves it to `10.0.1.48` (Traefik's internal IP) 3. Traefik sees it's for `yourdomain.com`, and forwards it right back to the WordPress container This keeps everything local, fast, and reliable.
GiteaMirror commented 2026-06-07 20:39:32 -05:00
Author
Owner
Copy Link

@JerresonJ commented on GitHub (Jun 4, 2025):

I went in a slightly different direction to make management easier.

Traefik handles all requests & SSL termination as usual.

https://myname.tld -> Traefik -> Container port 80

Since we deploy our own WP images I added a MU Plugin that automatically forces all internal requests to 127.0.0.1
So internal requests for https://myname.tld are modified directly to http://127.0.0.1

https://myname.tld -> http://127.0.0.1

Now those requests never leave the container & they bypass DNS entirely.
This should effectively handle all requests WP makes for internal processes.

I'm letting this run for a bit & testing to ensure I didn't over-simplify this fix and break anything but this should work.

<!-- gh-comment-id:2941401156 --> @JerresonJ commented on GitHub (Jun 4, 2025): I went in a slightly different direction to make management easier. Traefik handles all requests & SSL termination as usual. `https://myname.tld -> Traefik -> Container port 80` Since we deploy our own WP images I added a MU Plugin that automatically forces all internal requests to `127.0.0.1` So internal requests for `https://myname.tld` are modified directly to `http://127.0.0.1` `https://myname.tld -> http://127.0.0.1` Now those requests never leave the container & they bypass DNS entirely. This should effectively handle all requests WP makes for internal processes. I'm letting this run for a bit & testing to ensure I didn't over-simplify this fix and break anything but this should work.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
pull-request
Mirrored from GitHub Pull Request
 template
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/templates#10083
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?