Error: connect ECONNREFUSED ::1:8080

[LeviSnoot]

I'm running micro through podman. When I deploy it, I get the expected invite URL in the logs, but with a double slash after the domain:

[Nest] 2  - 08/28/2023, 11:42:26 AM     LOG [InviteService] Go to https://url.example.com//invite/bunchoflettersandnumbers to create the first account.

But trying to visit either https://url.example.com//invite/bunchoflettersandnumbers or https://url.example.com/invite/bunchoflettersandnumbers results in the following log message:

Failed to proxy http://localhost:8080/v1/instance Error: connect ECONNREFUSED ::1:8080

    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {

  errno: -111,

  code: 'ECONNREFUSED',

  syscall: 'connect',

  address: '::1',

  port: 8080

}

and the website itself gives a 500 error.

I'm reverse proxying micro with Nginx. Here's the vhost file:

server {
  server_name                                     url.example.com;
  gzip                                            on;
  client_max_body_size                            200M;

        location / {
                proxy_pass                      http://localhost:1234;
                proxy_set_header                Host $host;
                proxy_set_header                X-Real-IP $remote_addr;
                proxy_set_header                X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header                X-Forwarded-Proto $scheme;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/url.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/url.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}server {
    if ($host = url.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


  server_name                                           url.example.com;
  listen                                                      80;
  return 404; # managed by Certbot


}

My .microrc.yaml

databaseUrl: postgresql://micro:secureToken@postgres/micro
secret: otherSecureToken
inquiries: hello@example.com
storagePath: /data
restrictFilesToHost: true
hosts:
  - url: https://url.example.com
  - url: https://url.example.com
    redirect: https://example.com
    tags: ["admin"]
# conversions:
#   - from: image/gif
#     to: video/webm
#     minSize: 1MB

My docker-compose.yml:

version: "3"
services:
  micro:
    image: sylver/micro:main
    container_name: micro
    restart: unless-stopped
    volumes:
      - $PWD/.microrc.yaml:/usr/src/micro/.microrc.yaml
      - $PWD/data:/data
      # uncomment this if you dont care about https, then comment out the proxy service
    ports:
      - 1234:3000
  postgres:
    image: postgres:12-alpine
    container_name: micro-db
    restart: unless-stopped
    environment:
      # lleaving this as default should be fine as postgres will only ever be exposed to services
      # in this docker-compose file, but you might still want to consider changing it to something more secure.
      - POSTGRES_PASSWORD=secureToken
      - POSTGRES_USER=micro
      - POSTGRES_DB=micro
    volumes:
      - $PWD/.pg-data:/var/lib/postgresql/data
  # comment this out if you dont care about https, then uncomment the above ports
#  proxy:
#    image: caddy:2-alpine
#    restart: unless-stopped
#    ports:
#      - 80:80
#      - 443:443
#    volumes:
#      - $PWD/.caddy-data:/data
#      - $PWD/.caddy-config:/config
#      - $PWD/Caddyfile:/etc/caddy/Caddyfile

I've tried allowing port 8080 through my firewall (ipv4 and ipv6) just in case, but that didn't solve it. My guess is something is using port 8080 that shouldn't be, but I'm not sure if that's on the host system or one of the containers.

[sylv]

I don't understand where /v1/instance is coming from. It looks like an error from the nextjs proxy, but it should never be trying to forward requests to a URL that looks like that, and if it did, it should be able to talk to :8080 since it's running in the same container.

Check the container logs for micro, the API might be crashing at startup and the container isn't restarting because it's kinda terrible. That still doesn't explain the path its trying to access though..

If that doesn't help, joining the discord server and pinging me will be faster.

[LeviSnoot]

Closing as I went for rootless docker instead and that seems to work.