Fly proxy issues with fastify?

[tanktusSui]

These are my server logs doesnt seem to be any issues

Im also getting 502 error on request from nginx reverse proxy to the .internal hostname of the server above

I also get this in my fly deploy logs, my code is explicitly running on 0.0.0.0 port 3000

WARNING The app is not listening on the expected address and will not be reachable by fly-proxy.
You can fix this by configuring your app to listen on the following addresses:

• 0.0.0.0:3000
  Found these processes inside the machine with open listening sockets:
  PROCESS | ADDRESSES
  -----------------*---------------------------------------
  /.fly/hallpass | [fdaa:1:951d:a7b:2da:50e0:67fb:2]:22

---

Cleared lease for 185e276f454e98

Checking DNS configuration for firstgate-backend.fly.dev
WARN DNS checks failed: read udp 10.24.18.174:57416->8.8.8.8:53: i/o timeout

Its not making any sense to me.
My toml file

app = ‘firstgate-backend’
primary_region = ‘syd’
kill_signal = ‘SIGINT’
kill_timeout = ‘5s’

[build]

[http_service]
internal_port = 3000
force_https = true
auto_stop_machines = ‘stop’
auto_start_machines = true
min_machines_running = 1
processes = [‘app’]

[[services.ports]]
port = 80
handlers = [‘http’]
force_https = true

[[services.ports]]
start_port = 443
end_port = 443
handlers = [‘tls’, ‘http’]

[[services.ports]]
start_port = 3005
end_port = 3005

[[vm]]
memory = ‘1024mb’
cpu_kind = ‘shared’
cpus = 1

[ktosiek]

It looks like https://firstgate-backend.fly.dev/ is serving requests now. Have you managed to fix this problem?

[tanktusSui]

Yes it was always serving requests. I could go to that endpoint just fine on the public address.

However in my nginx reverse proxy pointing to http://firstgate-backend.internal/api endpoint, it gives me a 502 error when trying to go there

Whats also weirder is that I had exactly the same setup in the past and that worked fine?

[ktosiek]

Oh, so only .internal is problematic. I’ve missed that part.

Can you try to run curl -v http://firstgate-backend.internal/api from the machine that runs the proxy? This should say more about actual connectivity inside your app’s network.

Nginx writes logs about specific problems with upstream connections to a separate errors.log, if you can find it that could also help.

(BTW nginx, unless you are using the commercial subscription, has a serious flaw: it will only resolve upstream server names on restart. See the documentation for the resolve parameter)

[tanktusSui]

This is my nginx file for the reverse proxy

server {
  listen 8080;
  listen [::]:8080;

  root /usr/share/nginx/html;
  index index.html;

  location / {
    try_files $uri $uri/ /index.html;
  }

  server_name firstgate-dark-firefly-7933.fly.dev;

  location /socket.io {
            proxy_pass 'http://firstgate-backend.internal:3005/socket.io';
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            # Preserve and pass cookies from upstream server
          proxy_cookie_path / "/; secure; HttpOnly";
          proxy_set_header X-Forwarded-Host $http_host;
  
  # Allow CORS
    add_header Access-Control-Allow-Origin $http_origin;
    add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
    add_header Access-Control-Allow-Headers "Authorization, Content-Type";
    add_header Access-Control-Allow-Credentials true;
  }

  location /api/v1/ {
    proxy_pass "http://firstgate-backend.internal:3000/api/v1/";
  # Preserve and pass cookies from upstream server
    proxy_cookie_path / "/; secure; HttpOnly";
    proxy_set_header X-Forwarded-Host $http_host;
    # Allow CORS
    if ($request_method = OPTIONS) {
      add_header Access-Control-Allow-Origin $http_origin;
      add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
      add_header Access-Control-Allow-Headers "Authorization, Content-Type";
      add_header Access-Control-Allow-Credentials true;
      add_header Access-Control-Max-Age 86400;
      return 204;
    }
    add_header Access-Control-Allow-Origin $http_origin;
    add_header Access-Control-Allow-Methods "GET, POST";
    add_header Access-Control-Allow-Credentials true;
    add_header Access-Control-Allow-Headers "Authorization, Content-Type";
  }
}

It connects to the websocket just fine on port 3005 which is running fastify listening on port 3000.

[ktosiek]

That “Connection refused” seems off, like your app is not listening on that IPv6 address?

Running ss -nlp | grep 3000 on the app’s machine should show how the ports are actually bound. You want to see something listening on [::]:3000 (for IPv6) or *:3000 (for both IPv4 and v6).

[tanktusSui]

[tanktusSui]

I changed fastify to listen on :: instead of 0.0.0.0 and that resolves the issue.