Domain Access Fails for Services Created via Docker Compose

[cunpingtai]

1. When an application is created via the Application button, the domain is configured, and the deployment is completed, the service can be successfully accessed via the domain.
2. When a service is created using Template or Compose, the domain is configured, and the deployment is completed, but the service cannot be accessed via the domain.(Additional info: Inside the corresponding service container, running curl 127.0.0.1: returns a normal response.)

I conducted tests using the same domain and discovered that, in method (1), Traefik’s File System dynamic directory automatically generates a corresponding configuration file. However, in method (2), no such configuration file is created in the dynamic directory of the Traefik File System.

Originally, my Dokploy version was 0.8, but even after upgrading to the latest 0.18 version, the issue persists.

I recorded a video demonstrating that when using the same domain across applications created with different methods, only those created via Compose fail to be accessed via the domain. I can’t figure out what’s causing the issue and would really appreciate some help.

The video is just one example. I’ve tried creating services using different templates, but none of them work. Even following the tutorial from Dokploy’s official documentation doesn’t solve the issue.

youtube

Current vs. Expected behavior

Current Behavior:
• When creating an application using the Template or Compose method, configuring a domain, and deploying the service, the domain does not successfully route to the service.
• However, accessing the service inside the container using curl 127.0.0.1: returns a normal response.
• After deployment, no corresponding configuration file is generated in the dynamic directory of Traefik’s File System.

Expected Behavior:
• The service should be accessible via the configured domain, just like when deploying through the Application button.
• A corresponding configuration file should be automatically created in the dynamic directory of Traefik’s File System upon deployment.

Provide environment information

OS: Ubuntu

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

Docker Compose

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

Same server where Dokploy is installed

Additional context

youtube

Will you send a PR to fix it?

No

[Siumauricio]

Can you try to deploy this basic template?

services:
  proof:
    image: traefik/whoami

and in your domain assign like this:

I tried the same steps as the video and it works fine for me, also for docker-compose we don't create files as we do in applications, so this is normal behavior

[cunpingtai]

Operation Video
I followed the provided configuration for deployment, but the issue remains the same. Deploying the application normally works fine, but it doesn’t work when using Compose.

I checked the logs of the Traefik container on the server and noticed something interesting:

1. For services created using the application method, adding or removing a domain triggers log output in the Traefik container.
2. For services created using the Compose method, adding or removing a domain does not generate any log messages in the Traefik container.

I’m not sure if this is expected behavior.

[Siumauricio]

Have you checked the traefik logs?

[cunpingtai]

### Abnormal:
{"ClientAddr":"172.69.169.226:34302","ClientHost":"172.69.169.226","ClientPort":"34302","ClientUsername":"-","DownstreamContentSize":19,"DownstreamStatus":404,"Duration":15624,"GzipRatio":0,"OriginContentSize":0,"OriginDuration":0,"OriginStatus":0,"Overhead":15624,"RequestAddr":"s.mytreasurepocket.com","RequestContentSize":0,"RequestCount":2035,"RequestHost":"s.mytreasurepocket.com","RequestMethod":"GET","RequestPath":"/","RequestPort":"-","RequestProtocol":"HTTP/2.0","RequestScheme":"https","RetryAttempts":0,"StartLocal":"2025-02-24T07:33:42.641266604Z","StartUTC":"2025-02-24T07:33:42.641266604Z","TLSCipher":"TLS_AES_128_GCM_SHA256","TLSVersion":"1.3","entryPointName":"websecure","level":"info","msg":"","time":"2025-02-24T07:33:42Z"}

### Normal:
{"ClientAddr":"141.101.86.60:61202","ClientHost":"141.101.86.60","ClientPort":"61202","ClientUsername":"-","DownstreamContentSize":757,"DownstreamStatus":200,"Duration":1256143,"OriginContentSize":757,"OriginDuration":1224584,"OriginStatus":200,"Overhead":31559,"RequestAddr":"as.mytreasurepocket.com","RequestContentSize":0,"RequestCount":2147,"RequestHost":"as.mytreasurepocket.com","RequestMethod":"GET","RequestPath":"/","RequestPort":"-","RequestProtocol":"HTTP/2.0","RequestScheme":"https","RetryAttempts":0,"RouterName":"r2-demo-yejvki-router-websecure-129@file","ServiceAddr":"r2-demo-yejvki:4173","ServiceName":"r2-demo-yejvki-service-129@file","ServiceURL":"http://r2-demo-yejvki:4173","StartLocal":"2025-02-24T07:34:17.338899807Z","StartUTC":"2025-02-24T07:34:17.338899807Z","TLSCipher":"TLS_AES_128_GCM_SHA256","TLSVersion":"1.3","entryPointName":"websecure","level":"info","msg":"","time":"2025-02-24T07:34:17Z"}

### ChatGPT o1 :

Here’s a comparative analysis of the two Traefik Access Log entries you provided:

1. HTTP Response Status

   1. First log entry
      • DownstreamStatus: 404
      This indicates that the request resulted in a 404 Not Found response. It suggests Traefik did not successfully route the request to a specific backend service or the backend returned a 404.
   2. Second log entry
      • DownstreamStatus: 200
      This indicates the request was handled successfully and returned 200 OK. That means Traefik successfully matched a router and forwarded the request to the configured backend service.

2. Router and Service Matching

   1. First log
      • No RouterName, ServiceName, or ServiceURL fields are present.
      This usually means Traefik did not match any configured router (e.g., no rule matched the Host/Path), so Traefik responded with a default 404.
   2. Second log
      • RouterName: r2-demo-yejvki-router-websecure-129@file
      • ServiceName: r2-demo-yejvki-service-129@file
      • ServiceURL: http://r2-demo-yejvki:4173
      This indicates the request matched a specific router (r2-demo-yejvki-router-websecure-129@file) and was forwarded to the backend service at r2-demo-yejvki:4173. The service responded successfully (status 200).

3. Origin Status and Duration

   1. First log
      • OriginStatus: 0
      • OriginDuration: 0
      Because the request never made it to any backend service, Traefik did not record a backend response status or duration. The entire request was handled internally by Traefik (resulting in a 404).
   2. Second log
      • OriginStatus: 200
      • OriginDuration: 1224584 (units typically microseconds or nanoseconds)
      This shows the backend was called and returned a 200 response in about 1.224584 milliseconds of backend processing time.

4. Content Size

   1. First log
      • DownstreamContentSize: 19
      • OriginContentSize: 0
      This indicates only a minimal response (19 bytes, likely the default “404 Not Found” body from Traefik) was sent to the client, and there was no actual backend content.
   2. Second log
      • DownstreamContentSize: 757
      • OriginContentSize: 757
      The client received 757 bytes of response data, which also matches the amount of data returned by the backend. This confirms that the backend did serve content successfully.

5. Overall Conclusion
   • First log entry represents a request that did not match any router or was intentionally denied, leading to a 404 response.
   • Second log entry shows a successful request where Traefik forwarded to a backend service, received a valid response, and returned a 200 status to the client.

These logs highlight the importance of router matching in Traefik’s flow:
• If a router is matched (RouterName, ServiceName, etc.), the request is forwarded to the specified backend and a DownstreamStatus of 200 or other status code from the backend is returned.
• If no router matches or there’s a misconfiguration, Traefik typically returns 404 and logs minimal data (no router/service info, zero origin content, etc.).

[chai3]

I am having a similar problem.
It may be related to #1345 (#1371)
The same issue still occurs in v0.20.1.