Can't get caddy to load any docker applications via domain proxy to port

(Most Hated) #1

Hello,
I am trying to simply get Caddy to point to internally hosted applications in Docker but they don’t end up working.

At first I kept getting back a 502 error, just to rule out using a .dev domain as being part of the issue I used a .com (both hosted on Cloudflare) but neither worked.

One application is made in Go Buffalo and running in a docker container, and is on port 4569
The other is just a standard phpmyadmin container running on port 4570

I can get to both just fine if I do 123.123.123.123:4569 or 123.123.123.123:4570 (using my real ip, of course)

I have tried everything I can find when it comes to my Caddyfile. Here are a few examples.

First I just had a very basic setup:

mydomain.dev:80 { 
        proxy / localhost:4569 {
                transparent
        }
}

I then tried:

mydomain.dev:80 {   # <---- I tried with and without a port, as well as *.domain.dev:80, domain.dev:80 and a few other variations of things I found examples of
        proxy / localhost:4569 {
                transparent
                websocket
        }
}

I tried changing some things around such as

mydomain.dev:80, mydomain.dev:443  {
        proxy / 127.0.0.1:4569 {  #(here I also tried http://localhost:4569,  http://127.0.0.1:4569, 0.0.0.0:4569, etc )
                transparent
                websocket
        }
}

Where I currently am after scouring the web for more examples to try is this, which of course still doesn’t seem to work properly:

mydomain.com:80 {
    root /srv/mydomain.com #( <---- this part works at the root of the domain to server normal files)
    browse
    gzip

    tls mydomain.com {
        dns cloudflare
    }

        proxy /blog  http://127.0.0.1:4569 {  #( <---- this part and the one below still do not work though)
                header_upstream X-Forwarded-Host {host}:4569
                header_upstream -Origin
                header_upstream -Referer
                websocket
                transparent
        }

        proxy /admin localhost:4570 {
                header_upstream X-Forwarded-Host {host}:4570
                header_upstream -Origin
                header_upstream -Referer
                websocket
                transparent
        }

                log /srv/mydomain.com/logs/access.log {  
                    rotate_size 1
                    rotate_age  7
                    rotate_keep 2
                  }

                  errors /srv/mydomain.com/logs/error.log { 
                    rotate_size 1
                    rotate_age  7
                    rotate_keep 2
                  }
}

Going to the root of the domain works, which I setup just to make sure it was doing anything at all, so I can view the file browser and a test text file I put in there. /blog is my go application, /admin is phpmyadmin. Neither work though, with or without the header_upstream stuff. I simply added those in because I came across them on a forum post and figured it was worth a try. I know I had something similar in my nginx configs on another server in which these worked, so I thought it might have been necessary.


More recently I have tried it with all of these different options with no success: (not all at once, of course)

proxy / localhost:4569 {
                transparent
                # fail_timeout 0s
                # header_upstream Host {host}
                # header_upstream X-Real-IP {remote}
                # header_upstream X-Forwarded-Ssl on
                # header_upstream X-Forwarded-Proto {scheme}
                # header_upstream X-Forwarded-Host {host}:4569
                
                # proxy_header Host {host}
                # proxy_header X-Real-IP {remote}
                # proxy_header X-Forwarded-Proto {scheme}
                # proxy_header X-Forwarded-For {remote}

                # websocket
                # header_upstream -Origin
                # header_upstream -Referer
                # transparent
        }

With my current test of simply:

domain.dev {
    tls {
        dns cloudflare
    }

    proxy / localhost:4569 {
        transparent
    }
}

It doesn’t come back with an actual 502 error this time, but it does seem to just loop over and over until eventually saying:

The page isn’t redirecting properly

An error occurred during a connection to domain.dev.

    This problem can sometimes be caused by disabling or refusing to accept cookies.

So, possible progress I suppose.

If anyone has any suggestions, I would definitely love to hear them!
Thanks,
-MH

(Matthew Fay) #2

Howdy @MostHated, welcome to the Caddy community.

Lets start by seeing if we can have a look at what Caddy sees when it tries to proxy upstream.

Run curl -kIL localhost:4569 from the Caddy host machine and let us know what you get.

(Most Hated) #3

Hey there,
Thanks for the reply. When I run that I just get a bunch of the following.

HTTP/1.1 301 Moved Permanently
Cache-Control: max-age=31536000
Etag: 159ebbc179e1299b
Location: ..//
Date: Wed, 15 May 2019 02:56:00 GMT

HTTP/1.1 301 Moved Permanently
Cache-Control: max-age=31536000
Etag: 159ebbc179e8868c
Location: ..//
Date: Wed, 15 May 2019 02:56:00 GMT

HTTP/1.1 301 Moved Permanently
Cache-Control: max-age=31536000
Etag: 159ebbc179ee8cea
Location: ..//
Date: Wed, 15 May 2019 02:56:00 GMT

I had seen on another thread that someone said to turn the Cloudflare forwarding grey so it was DNS only. I had done that a few hours ago to see what it would do, but so far the only thing I have seen is that do was move any error message I received from Cloudflares custom page to a plain one server side. With the current way I was trying it it just says “502 Bad Gateway”.

Just to check, I tried curl -kIL localhost:4570 (the phpmyadmin container), it came back with 200 OK but both do the exact same thing when trying to get to using a domain via Caddy.

(Matthew Fay) #4

Well, whatever’s running on port port 4569 is definitely broken! Giving out Location: ..// doesn’t make any sense at all when you request the web root. That’ll need to be fixed before anyone can use it, let alone Caddy.

If you’re getting Status 200 from localhost:4570, that’s a good sign for that app, then.

Try a simple Caddyfile just for testing this upstream:

:2015 {
  proxy / localhost:4570
}

Then curl -IL localhost:2015 and compare the result with the curl -kIL localhost:4570 results.

(Most Hated) #5

I will give that a try here shortly. I definitely agree that the 4569 seems quite broken, but the strange thing is, if I just go to the public IP xxx.xxx.xxx.xxx:4569 the app comes up just fine.

I am going to try taking the container and exporting and moving it over to my other server which uses Nginx proxy and point a domain to it just to see if it does anything differently than what Caddy is doing because it just seems so odd that it works fine with IP. I will report back my findings of each of these things.