No response from server

[ztonyot]

Hi All,

we have a "Run Dependabot for Nuget and Npm" in azuredevops pipeline, the job runs on a rocky9 build machine I am getting something like this:

proxy | 2024/11/07 22:25:32 [905] POST http://host.docker.internal:44617/update_jobs/update_0_nuget_all/update_dependency_list proxy | 2024/11/07 22:25:32 [905] No response from server proxy | 2024/11/07 22:25:32 Received nil response proxy | 2024/11/07 22:25:32 [905] No response from server proxy | 2024/11/07 22:25:32 Received nil response updater | 2024/11/07 22:25:32 ERROR <job_update_0_nuget_all> dial tcp 172.17.0.1:44617: connect: connection refused updater | updater | 2024/11/07 22:25:32 ERROR <job_update_0_nuget_all> /home/dependabot/dependabot-updater/lib/dependabot/api_client.rb:223:in `block in update_dependency_list'

the port number will change after each run, I have tried to disable firewalld, but it did not help

[drummerwolli]

i have the same problem, and the workaround mentioned in https://github.com/dependabot/cli?tab=readme-ov-file#post-httphostdockerinternalportupdate_jobscliupdate_dependency_list-no-response-from-server does not work 😢

[ahokinson]

I'm getting this as well. Did either of you find workarounds?

updater | 2025/09/02 21:32:58 INFO Processing engine constraints for node
  proxy | 2025/09/02 21:32:59 [007] POST http://host.docker.internal:38157/update_jobs/cli/update_dependency_list
  proxy | 2025/09/02 21:32:59 [007] No response from server
  proxy | 2025/09/02 21:32:59 Received nil response
  proxy | 2025/09/02 21:32:59 [007] No response from server
  proxy | 2025/09/02 21:32:59 Received nil response
updater | 2025/09/02 21:32:59 ERROR dial tcp 172.17.0.1:38157: connect: connection refused

[ahokinson]

Some caveats to my issue after further investigation:

• My work network policy prevents network requests via 0.0.0.0.
• The recommended workaround from the readme does not fix the problem.
• The api-url param seems to hold a clue to get this working, but it's unclear how this needs to be set up.
• I am running this on a Mac using Rancher, but with the appropriate socket for communication.

Running this on a personal machine with Docker Desktop worked fine.

@jakecoffman, do you have any advice with regard to how these pods communicate and how I might possibly debug this?

[ahokinson]

@jakecoffman, changing the port with FAKE_API_PORT works, but the FAKE_API_HOST doesn't seem to work.

FAKE_API_PORT=8080 FAKE_API_HOST=127.0.0.1

Still results in:

proxy | 2025/09/04 16:03:10 [011] POST http://host.docker.internal:8080/update_jobs/cli/update_dependency_list

[ahokinson]

Setting the --api-url to use 127.0.0.1 makes these values consistent, but I think I must be misunderstanding the architecture of the CLI. Especially because I'm realizing that the proxy container is probably running in bridge network mode and not host network mode and that would mean host.docker.internal is correct. If you have any ideas for secure environments with port/socket functionality, they would be appreciated.

[jakecoffman]

FAKE_API_HOST is used to set the host/ip of the server, what you are seeing there is the URL of the request. You would have to use --api-url to change where the request is going.

You mentioned you are using Rancher, which container engine are you using? https://docs.rancherdesktop.io/1.7/ui/preferences/container-engine/

If you aren't using dockerd, host.docker.internal will not work but you are on the right track.

One thing you can try is get your LAN IP address, for instance mine currently is 192.168.1.94, and run like this:

FAKE_API_PORT=8080 FAKE_API_HOST="192.168.1.94" dependabot update go_modules dependabot/cli --api-url "http://192.168.1.94:8080"

Explaination:

• FAKE_API_PORT sets the port explicitly so it can be specified in --api-url, otherwise it would use a random one
• FAKE_API_HOST sets the server listening for only the LAN route
• api-url tells dependabot-core to request this specific IP/host

[ahokinson]

Thank you, @jakecoffman, for pointing this out.

If you aren't using dockerd, host.docker.internal will not work but you are on the right track.

This was the key.

Using the official docker:dind image, I changed the entrypoint to dockerd. It works.