Dockerised self hosted kutt. Cannot curl the API container from another container on the same docker host.

[darrendignam]

I have two containers: one kutt, one a webapp
The webapp cannot generate shortlinks via the API between the containers.

The webapp uses curl, I cant change that right now.

If I curl the domain name of kutt, I get a connection refused message. If I use the docker hostname via a docker network, I get redirected to the domain name, and it fails again.

It looks like the curl command fails because the dns redirect for the curl request is all for the same public IP address of the server and then kutt refuses to accept the connection. (the webapp and the kutt instance both have the same public IP - so when curl sees that it is trying to make a connection to 'itself' it's like doing curl PUBLIC_IP:443 or localhost:443 and bypassing the proxy and domain name?)

Both the web server and kutt work fine. I can use a browser and see the website, and the kutt GUI, and manually create short urls. Browse my website, all is good, I want the website to be able to create shortlinks for itself via the API for social media sharing etc

Ideally, I would like a setting that allowed kutt to accept incoming api calls on the DEFAULT_DOMAIN that is the HTTPS externally facing one, AND a second ALTERNATE_DOMAIN that I could put the docker internal hostname into, so that my local containers could also generate short urls.

More details:

So I have a self hosted kutt instance running here at lets say "mykutt.com"
I use docker-ompose.yml and a .env
I have these working settings in my .env:

SITE_NAME=mykutt.com
DEFAULT_DOMAIN=mykutt.com

I use a reverse nginx proxy via these two images:
nginxproxy/acme-companion
nginxproxy/nginx-proxy

I have a working self hosted HTTPS letsencrypt kutt running.

I also have a webapp on the same server myapp.com it is also HTTPS via the proxy. all is good.

If i get a shell on the webapp and try and curl to the mykutt.com container i get this output:

WEBBAPP to KUTT

bash-5.1# curl -L -vvvv https://mykutt.com/
*   Trying 122.102.221.152:443...
* connect to 122.102.221.152 port 443 failed: Connection refused
* Failed to connect to mykutt.com port 443 after 1505 ms: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mykutt.com port 443 after 1505 ms: Connection refused

If I instead try the docker hostname:

WEBBAPP to KUTT

bash-5.1# curl -L -vvvv kutt_link_shortner_kutt_1:3000
*   Trying 172.31.0.13:3000...
* Connected to kutt_link_shortner_kutt_1 (172.31.0.13) port 3000 (#0)
> GET / HTTP/1.1
> Host: kutt_link_shortner_kutt_1:3000
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< X-DNS-Prefetch-Control: off
< X-Frame-Options: SAMEORIGIN
< Strict-Transport-Security: max-age=15552000; includeSubDomains
< X-Download-Options: noopen
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Location: https://mykutt.com/
< Vary: Accept
< Content-Type: text/plain; charset=utf-8
< Content-Length: 49
< Date: Thu, 20 Feb 2025 13:33:45 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Ignoring the response-body
* Connection #0 to host kutt_link_shortner_kutt_1 left intact
* Issue another request to this URL: 'https://mykutt.com/'
*   Trying 122.102.221.152:443...
* connect to 122.102.221.152 port 443 failed: Connection refused
* Failed to connect to mykutt.com port 443 after 1519 ms: Connection refused
* Closing connection 1
curl: (7) Failed to connect to mykutt.com port 443 after 1519 ms: Connection refused

And just for completeness, if I connect from my local PC via curl to the domain name mykutt.com I can see the SSL stuff in action and working:

MY-PC to KUTT

curl -L -vvvv https://mykutt.com/
*   Trying 122.102.221.152:443...
* Connected to mykutt.com (122.102.221.152) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=mykutt.com
*  start date: Jan 21 12:12:17 2025 GMT
*  expire date: Apr 21 12:12:16 2025 GMT
*  subjectAltName: host "mykutt.com" matched cert's "mykutt.com"
*  issuer: C=US; O=Let's Encrypt; CN=R11
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x556fece5f620)
> GET / HTTP/2
> Host: mykutt.com
> user-agent: curl/7.74.0
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200 
< server: nginx/1.27.0
< date: Thu, 20 Feb 2025 13:05:36 GMT
< content-type: text/html; charset=utf-8
< content-length: 37851
< x-dns-prefetch-control: off
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=15552000; includeSubDomains
< x-download-options: noopen
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< x-powered-by: Next.js
< etag: "93db-wXRhpycdcfC7GbJ+gsJ1e89443E"
< vary: Accept-Encoding
< strict-transport-security: max-age=31536000
< 
<!DOCTYPE html>
....
</html>

So my issue is that curl does not seem to want to do the SLL stuff from container to container. So does anyone know a work around or curl option that I could try?

Or is there some kutt settings i can put in my .env file to allow connections from both the hostname, and the web address? and not get into a redirection that wont work?

I have seen other issues here but they are not exactly like mine, and one suggestion was to have two instances running, for two different domain names, so perhaps that could work, but it seems a bit overkill and wasteful of server resources. It seems like this should be a common use case, so was hoping someone has also got a working setup like this.

Cheers