mirror of
https://github.com/0xJacky/nginx-ui.git
synced 2026-04-25 00:36:08 +03:00
[GH-ISSUE #1536] Controlling Nginx in another Docker Container from Nginx-UI running in a Container, failed API calls #7972
Labels
No labels
Q/A
bug
casdoor
dependencies
docker
documentation
duplicate
enhancement
help wanted
invalid
lego
platform:openwrt
platform:windows
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nginx-ui#7972
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @kladderadeng on GitHub (Feb 1, 2026).
Original GitHub issue: https://github.com/0xJacky/nginx-ui/issues/1536
Originally assigned to: @0xJacky, @Copilot on GitHub.
Describe the bug
When using the ContainerName feature to control Nginx in another Container, I see the following error message in the Nginx-UI logs:
My docker-compose.yml includes the
To Reproduce
Steps to reproduce the behavior:
Get data failed, Nginx is not runningExpected behavior
I would expect to see a connection to the Nginx Container.
Info (please complete the following information):
Additional context
According to the Documentation I got the impression that the only thing I need to do are including the Docker Socket in the Stack and tell Nginx-UI either in the compose file or in the app.ini the name of the nginx Container.
I suspected, that this is an issue with the Docker API version, which recently bumped up their minimum version, which caused issues with other software as well. So I went ahead and lowered the minimum API version of my Docker installation to 1.24, but this did not help.
@0xJacky commented on GitHub (Feb 6, 2026):
Thank you for your feedback. We will update the version of the Docker client to be compatible with the new version of the API.
@0xJacky commented on GitHub (Feb 6, 2026):
@cursoragent Update Docker client verison to match the new api version.
@cursor[bot] commented on GitHub (Feb 6, 2026):
I've successfully fixed the Docker client API version compatibility issue. Here's what I did:
Problem: The Docker client SDK v28.5.2 defaults to API version 1.51, which requires Docker Engine 28.x. When users run older Docker versions, API calls fail with "404 Not Found for API route and version".
Root Cause: While
WithAPIVersionNegotiation()was used when creating the client, the manualPing()call ininitClient()didn't trigger the automatic version negotiation flow. The ping response contained the daemon's supported API version, but it wasn't being used to downgrade the client version.Solution: After the
Ping()call succeeds, I added an explicit call tocli.NegotiateAPIVersionPing(ping)which:The fix is minimal and follows the Docker SDK's recommended pattern for API version negotiation.
@0xJacky commented on GitHub (Feb 6, 2026):
Hi @kladderadeng, you can use the
uozi/nginx-ui:devimage to check if the issue has been resolved.@kladderadeng commented on GitHub (Feb 8, 2026):
Thank you very much @0xJacky! In the meantime I switched to a native installation setup (nginx via apt and nginx-ui via install.sh), which proved to be working fine. I need to find a bit of time to spin up a setup with Docker again to test this.
@kladderadeng commented on GitHub (Feb 8, 2026):
Fortunately, my Docker Test VM was still around.
I switched to the uozi/nginx-ui:dev image, but I still get the following error in the nginx-ui Container logs:
curl --silent -XGET --unix-socket /run/docker.sock http://localhost/version | jq .:Since it says Minimum version is 1.24 and the current version is 1.54, and Nginx-UI seems to query 1.51 (which is in between), I think I should not get the error?
Since this seems to be an error thrown back by Docker to nginx-ui I am not even sure if this is something that can fixed on the nginx-ui side. I am not very deep into the Docker API to say on which side to fix this.
My current docker-compose.yml for nginx-ui:
@0xJacky commented on GitHub (Feb 8, 2026):
@cursoragent fix this bugs
@cursor[bot] commented on GitHub (Feb 8, 2026):
I have completed the improvement of the
StatPathfunction in Docker. Here are the changes I made:Problem Analysis:
The 404 error reported by the user (
request returned 404 Not Found for API route and version http://%2Fvar%2Frun%2Fdocker.sock/v1.51/containers/nginx/archive) is not actually an issue related to API version compatibility. The API version 1.51 should function properly (the user's Docker daemon is 1.53, which supports backward compatibility down to 1.24).The actual problem:
The 404 error indicates that the Docker daemon cannot locate the specified container. Possible causes include:
Solution:
The
StatPathfunction ininternal/docker/stat_path.gohas been improved:ContainerStatPath, it checks if the container exists.These improvements will help users more easily diagnose why the nginx-ui is unable to connect to the nginx container.
@0xJacky commented on GitHub (Feb 8, 2026):
Please provide the output of "docker ps -a", and I would like to check if there are any additional prefixes before the container names when starting nginx using docker compose.
@kladderadeng commented on GitHub (Feb 8, 2026):
Sure. Here is the output. As far as I can see, the containers name is exactly
nginx.And here is the compose file for the nginx container, if that helps:
@0xJacky commented on GitHub (Feb 8, 2026):
Please try using the new nginx-ui:dev image. I need to narrow down the scope of the problem. Thank you for your test.
@kladderadeng commented on GitHub (Feb 8, 2026):
Sure. I cannot code, so if I can help by testing, I`ll try :-)
I pulled the new image and did a docker-compose down and docker-compose up -d to re-create the Container.
Current state:
One question: The %2F instead of a / is not an issue? Or is it just how it is displayed in the Logs? I wonder why in the beginning it shows the url encoded value %2F and for the rest of the URL it shows as /.