Can't send HTTP requests to localhost from a trigger function

[HTMHell]

Bug report

Describe the bug

When trying to send a request from a trigger function, the request doesn't reach the server. In the _http_response table, the error message is:

Couldn't connect to server

To Reproduce

Do the following locally:

1. Create an edge function, and serve it.

2. Create a trigger function that makes an HTTP request to your edge function:

   begin
   perform
   net.http_post(
     url:='url_to_your_localhost_edge_function',
     body:='{}'::jsonb
   ) as request_id;
   
   return new;
   end;

3. Create a trigger that will execute the function
4. Trigger the function
5. You will notice the request did not reach the edge function.

Expected behavior

The request should go through.

Additional context

• I tried to use both 54321 and 8000 ports
• When I curl my edge function, it works
• When I use an external URL instead of localhost, it works

System information

• OS: macOS

[steve-chavez]

When trying to send a request from a trigger function, the request doesn't reach the server. In the _http_response table, the error message is: Couldn't connect to server

Hm, this looks more of an infra issue since pg_net is reporting the error correctly.

This seems related https://github.com/supabase/supabase/discussions/9837

@HTMHell Could you try reaching your edge function with pgsql-http?

[pcnc]

This seems related supabase/supabase#9837

Yep, this is unfortunately due to localhost mapping to the Postgres container itself - to reach the Docker host (and all ports exposed on it), either host.docker.internal or 172.17.0.1 have to be used as the target hostname.

@HTMHell could you try using any of the above options to confirm that the http request connects as expected?

[HTMHell]

This seems related supabase/supabase#9837

Yep, this is unfortunately due to localhost mapping to the Postgres container itself - to reach the Docker host (and all ports exposed on it), either host.docker.internal or 172.17.0.1 have to be used as the target hostname.

@HTMHell could you try using any of the above options to confirm that the http request connects as expected?

Yup, that did the trick. Thank you!

[chang-ryan]

Is anyone still seeing this problem in 2024?

To be clear, we are directly inputting the host.docker.internal base URL into the supabase dashboard (local instance) right?

[HTMHell]

Is anyone still seeing this problem in 2024?

To be clear, we are directly inputting the host.docker.internal base URL into the supabase dashboard (local instance) right?

It doesn't look like a Supabase edge function, so I don't think it applies to you. If it is, try http://host.docker.internal:54321/functions/v1/.... If not, maybe try the local IP address as a host instead.

[chang-ryan]

I'm trying to reach out to a nuxt instance being run on localhost:3000, not supabase edge functions

[HTMHell]

I'm trying to reach out to a nuxt instance being run on localhost:3000, not supabase edge functions

In that case, you're using the wrong hostname

[supermar1010]

@chang-ryan did you manage to get it working. I'm stuck at the same problem.

@HTMHell you're saying host.docker.internal is the wrong hostname. But what would be the right one. I've been trying many different ones (host.docker.internal, the ip address of my machine, 172.17.0.1, localhost, 127.0.0.1)

In my understanding host.docker.internal should be the right one, but it simply refuses to work.

The weird thing is I can rerach the dashboard at 54323 but no other service running under localhost

[HTMHell]

@chang-ryan did you manage to get it working. I'm stuck at the same problem.

@HTMHell you're saying host.docker.internal is the wrong hostname. But what would be the right one. I've been trying many different ones (host.docker.internal, the ip address of my machine, 172.17.0.1, localhost, 127.0.0.1)

In my understanding host.docker.internal should be the right one, but it simply refuses to work.

To my understanding, you should use that hostname if you're using an edge function (or any other service in the same Docker container). If you're running a server on your machine, since postgres is running in docker, which is a different machine, I'd assume you'll need to use your computer's local IP address. I don't have much knowledge in Docker, so I might be wrong here.

[supermar1010]

@HTMHell thank you for your reply!

I think th eissue is the netowrking mode, which is not set to host for the db container, but this is a cli issue rather than a pg_net issue, so I opened an issue there

https://github.com/supabase/cli/issues/2022

[unidesigner]

@chang-ryan Did you resolve the issue? I'm running into the same issue on my Ubuntu box with supabase 1.152.1. Host host.docker.internal or any of the other IP addresses does not work. If I use ngrok it works, so clearly the webhook is called, just not working for local connections. @supermar1010 's solution to reboot my machine did not work, unfortunately.

Any hints on how to debug this further would be very much appreciated.

[supermar1010]

@unidesigner a quick Google search told me that host.docker.internal is only for macos (and maybe windows?). So something else should work: https://stackoverflow.com/questions/48546124/what-is-the-linux-equivalent-of-host-docker-internal#48547074

[lougeo]

This seems related supabase/supabase#9837

Yep, this is unfortunately due to localhost mapping to the Postgres container itself - to reach the Docker host (and all ports exposed on it), either host.docker.internal or 172.17.0.1 have to be used as the target hostname.

@HTMHell could you try using any of the above options to confirm that the http request connects as expected?

This was necessary for me to make calls with the supabase client from an edge function after getting a very general connection refused error. After a decent amount of digging this was the only place I've seen this documented. Would be helpful to have a blurb about this somewhere in the docs - either in the local dev section or the edge functions section.

[unidesigner]

Thanks @supermar1010 for the feedback. Unfortunately, I cannot make it work with all the suggestions in the SO article. I tried 172.17.0.1 which is the inet field of docker0 as shown with ifconfig. Also tried to add 172.17.0.1 host.docker.internal to /etc/hosts. Using host.docker.internal works on MacOS on another machine. I'm using supabase CLI to start the containers, not sure how I could further debug this. As a workaround, I'm using a tunneling solutions for my local dev which is a bit suboptimal.

[davidfant]

@unidesigner did you find a better solution than tunneling for Linux?

[unidesigner]

@davidfant Unfortunately not yet.