Docker - Multiple containers with SSL

You’re right, that was a silly mistake.

After including the https, requests are no longer being duplicated from a 302 to a 200.
When running curl -v https://sub.domain.com I get a 200 success.
However, I’m afraid it gives the same response as posted earlier. It simply redirects to the default frontpage.

phpfpm        | 172.31.0.4 -  28/Dec/2020:18:49:35 +0000 "GET /index.php" 302
caddy         | {"level":"info","ts":1609181375.0495365,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_addr":"162.158.93.194:53918","proto":"HTTP/1.1","method":"GET","host":"php.domain.com","uri":"/servers","headers":{"Cf-Visitor":["{\"scheme\":\"https\"}"],"User-Agent":["curl/7.68.0"],"Connection":["Keep-Alive"],"Accept-Encoding":["gzip"],"Cf-Ipcountry":["DE"],"X-Forwarded-For":["2a01:4f8:221:2999::2"],"X-Forwarded-Proto":["https"],"Cf-Request-Id":["074c4841f70000c26d0e17b000000001"],"Cdn-Loop":["cloudflare"],"Cf-Ray":["608d76498da2c26d-FRA"],"Accept":["*/*"],"Cf-Connecting-Ip":["2a01:4f8:221:2999::2"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"","proto_mutual":true,"server_name":"php.domain.com"}},"common_log":"162.158.93.194 - - [28/Dec/2020:18:49:35 +0000] \"GET /servers HTTP/1.1\" 302 20","duration":0.022119267,"size":20,"status":302,"resp_headers":{"Pragma":["no-cache"],"Location":["https://php.domain.com"],"Content-Type":["text/html; charset=UTF-8"],"Set-Cookie":["PHPSESSID=0db27f910de917af44e0822210f27ee3; path=/"],"Expires":["Thu, 19 Nov 1981 08:52:00 GMT"],"Server":["Caddy"],"Status":["302 Found"],"Cache-Control":["no-store, no-cache, must-revalidate"],"Vary":["Accept-Encoding"],"X-Powered-By":["PHP/7.4.13"],"Content-Encoding":["gzip"]}}

Now, we’ve been at this for quite a while.
My initial question, in the start of the topic, has long since been answered, and I feel like this topic is being dragged out because of my framework, which is still not relevant to Caddy.

I appreciate your help a lot - it really means a lot to me.
But I also realize that you’re probably a busy person, and can’t dedicate so much of your time to an issue like this.

Therefore I’m hoping we can put this to rest soon, one way or another.
Do you want to continue helping me, the way we’ve been doing so far, back and forth?
Would giving you access to the source code help?
I can even pass on some SSH credentials, if you like to see the configuration for yourself - there’s nothing else running on the server.

If you don’t mind continuing, I’ll of course be happy, but I’m also in complete understandings if you’re not interested.
Like I said, my original question has already been answered, so it feels like we’re just dragging this out, which I’m not interested in doing to a knowledgeable person like you - I’m sure you could spend your time on way more important things, and I don’t want to hold you up.

Please let me know, and thanks for your help so far.

I don’t really understand what the problem is at this point honestly. That seems fine to me? What is it supposed to be doing otherwise? I don’t get it.

Possibly the simplest way to just get it working is to run that app with apache+php in a Docker image (i.e. php:7.4-apache) and use Caddy’s reverse_proxy directive instead of php_fastcgi. Basically Caddy would just terminate TLS then proxy the request to apache to deal with any custom behaviour of your app. Might not perform quite as well, but if this isn’t very high traffic, it’ll be just fine.

Scroll down to the bit about php:<version>-apache for instructions Docker

And if you do it that way, Caddy won’t need the volume mounted for that site cause all it’ll do is proxy every request basically as-is.

:slight_smile:

I’m glad to put a smile on people’s faces. Thanks again for the well-wishes, it put a smile on my face on Christmas eve :smiley: :christmas_tree:

It’s just a few minutes here and there so it’s not much of a bother.

Yep, that’s no problem.

Hello again, and happy new years.

I’ve actually thought about this solution too, and it would obviously work, but as my site does have a pretty high hit-rate, I’m not comfortable doing it this way.
I’d rather do it correctly this time around.

I’ve been going a bit back and forward with the issue though, and in the end I decided to try and install nginx, just to see if it was the site/server/database/anything else that was causing the issue.
After installing nginx, the same error occurred, where all URI’s redirect to 404, but then I added the little code (posted earlier) and suddenly everything was working flawlessly.

This leads me to believe that the root of the issue is with the Caddyfile, and the rewrites going on there.
Is there a chance you could take a look at this again, and make sure it’s correctly “translated”?
I think we might be able to put this to rest if this file is checked.

Here’s the site configuration where the rewrites are working:

server {
        index index.php;
        listen  443 ssl;
        server_tokens off;

        server_name php.domain.com;
        root /var/www/php.domain.com;

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass phpfpm:9000;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
        }

        location / {
                try_files $uri $uri/ =404;

                if (!-e $request_filename) {
                        rewrite ^/admin/(.*)?$ /admin/index.php?a=$1 last;
                        rewrite ^/(.*)$ /index.php?a=$1 last;
                        break;
                }
        }

}

As always, thank you in advance.

When I say very high, I mean like 50+ requests per second. I’m pretty certain it’ll be just fine.

I still don’t feel I understand what is supposed to be happening. Could you please enumerate a list of requests (with paths, etc) and their result (what rewrite should happen, what file they serve).

This topic was automatically closed after 30 days. New replies are no longer allowed.