CURL my api via .internal is way slower then via the fly.dev address

1

Hello Fly community,

I hope this message finds you well. I am currently facing an issue with private networking in my Fly organization and would appreciate some guidance.

When I use the internal address (http://api-example.internal:8080) to curl my API instance from my front-end server, I notice a delay of approximately 5 seconds before receiving the response. However, when I use the fly.dev address (https://api-example.fly.dev), the response is instantaneous (from that same server).

I’m curious if anyone has encountered a similar situation or has insights into what might be causing this delay in private networking requests. Your expertise and suggestions would be immensely helpful.

curl -i http://api-example.internal:8080

If anyone could shed some light on this matter, I would be grateful.

Thank you in advance for your assistance!

1 Like
2

Interesting! Try out this curl command from here, I’m interested to see if the pause is related to DNS resolution (time_namelookup).

Your case would be something like:

curl -s --connect-timeout 10 \
-w "time_namelookup: %{time_namelookup}, time_connect: %{time_connect}, time_appconnect: %{time_appconnect}, time_pretransfer: %{time_pretransfer}, time_redirect: %{time_redirect}, time_starttransfer: %{time_starttransfer}, time_total: %{time_total}\n" \
-o /dev/null \
http://api-example.internal:8080

And if you grab the private IPv6 of the api-example app, you can try to run a curl request directly to that to further see if DNS resolution might be the issue there.

1 Like
3

Hi, thanks for the answer, I’ve ran the command multiple times and I get the following outputs :

  • When I curl the instance through the private network, I get a result like this :
time_namelookup: 0.000636, time_connect: 0.202028, time_appconnect: 0.000000, time_pretransfer: 0.202072, time_redirect: 0.000000, time_starttransfer: 0.208683, time_total: 0.208750

However, I sometimes (approximately each 5 times), get a slower response like this :

time_namelookup: 0.000747, time_connect: 1.203455, time_appconnect: 0.000000, time_pretransfer: 1.203511, time_redirect: 0.000000, time_starttransfer: 1.213058, time_total: 1.213119
  • When I curl the instance throught the fly.dev DNS, I get the following output :
time_namelookup: 0.000705, time_connect: 0.000860, time_appconnect: 0.022968, time_pretransfer: 0.023121, time_redirect: 0.000000, time_starttransfer: 0.031022, time_total: 0.031093

I guess the DNS resolution is not the issue here…

By the way, I think I had a configuration issue, so the 5 seconds delay is in reality less, but I still have a difference between the two methods, as seen in the time results.

4

Any chance this is happening because Fly shuts down VM’s due to inactivity? (Default configuration is to auto-shut off when idle).

The Fly Proxy controls that, however the fly-proxy is not used when connecting over private DNS like this. So, the VM may be shutting down since the proxy thinks it’s idle.

After leaving it for a few minutes, check fly status for the API app to see if it’s off - the delay could be it restarting. It might only restart then when using the fly.dev way to access it, rather than over the private network.

You can configure the auto-shutdown behavior via fly.toml as per docs here: Automatically stop and start Machines · Fly Docs

5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.