starred/panel
1
0
Fork 0
mirror of https://github.com/pelican-dev/panel.git synced 2026-02-24 03:12:01 +03:00
Code Issues 42 Packages Projects Releases 12 Wiki Activity

Docker image will not serve on HTTP if the site URL is https #257

New Issue
Closed
opened 2026-02-04 17:17:43 +03:00 by OVERLORD · 7 comments
OVERLORD commented 2026-02-04 17:17:43 +03:00
Owner
Copy Link

Originally created by @Morpheus636 on GitHub (Feb 12, 2025).

Originally assigned to: @parkervcp on GitHub.

Current Behavior

The Caddyfile uses the SITE_URL environment variable to set the route on which Caddy will serve the panel.

If you place the panel behind a reverse proxy that provides and terminates TLS (such as a different Caddy instance used to serve multiple sites), SITE_URL is supposed to start with https://.

With SITE_URL beginning https://, Caddy will redirect any traffic on port 80 (including from the reverse proxy server in front of it) to 443, causing too many redirects.

Expected Behavior

Caddy allow the site to be served on HTTP or HTTPS, regardless of the SITE_URL.

Steps to Reproduce

To reproduce the redirect behavior:

  1. Deploy the Docker image with SITE_URL beginning with https://
  2. Attempt to access the container over port 80 and notice a 308 redirect to HTTPS.

To reproduce the too many redirects error:

  1. Deploy the Docker image with a SITE_URL beginning with https://
  2. Point the DNS for the domain in SITE_URL to a different caddy instance, configured to reverse_proxy to port 80 on the panel.
  3. Access the second Caddy instance and observe the too many redirects error.

Panel Version

v1.0.0-beta17

Wings Version

N/A

Games and/or Eggs Affected

N/A

Docker Image

N/A

Error Logs

N/A

Is there an existing issue for this?

  • I have searched the existing issues before opening this issue.
  • I have provided all relevant details, including the specific game and Docker images I am using if this issue is related to running a server.
  • I have checked in the Discord server and believe this is a bug with the software, and not a configuration issue with my specific system.
Originally created by @Morpheus636 on GitHub (Feb 12, 2025). Originally assigned to: @parkervcp on GitHub. ### Current Behavior The Caddyfile uses the `SITE_URL` environment variable to set the route on which Caddy will serve the panel. If you place the panel behind a reverse proxy that provides and terminates TLS (such as a different Caddy instance used to serve multiple sites), `SITE_URL` is supposed to start with https://. With SITE_URL beginning https://, Caddy will redirect any traffic on port 80 (including from the reverse proxy server in front of it) to 443, causing too many redirects. ### Expected Behavior Caddy allow the site to be served on HTTP or HTTPS, regardless of the `SITE_URL`. ### Steps to Reproduce **To reproduce the redirect behavior:** 1. Deploy the Docker image with SITE_URL beginning with https:// 2. Attempt to access the container over port 80 and notice a 308 redirect to HTTPS. **To reproduce the too many redirects error:** 1. Deploy the Docker image with a SITE_URL beginning with https:// 2. Point the DNS for the domain in SITE_URL to a different caddy instance, configured to reverse_proxy to port 80 on the panel. 3. Access the second Caddy instance and observe the too many redirects error. ### Panel Version v1.0.0-beta17 ### Wings Version N/A ### Games and/or Eggs Affected N/A ### Docker Image N/A ### Error Logs ```bash N/A ``` ### Is there an existing issue for this? - [x] I have searched the existing issues before opening this issue. - [x] I have provided all relevant details, including the specific game and Docker images I am using if this issue is related to running a server. - [x] I have checked in the Discord server and believe this is a bug with the software, and not a configuration issue with my specific system.
OVERLORD added the 🟡 medium label 2026-02-04 17:17:43 +03:00
OVERLORD commented 2026-02-04 17:17:51 +03:00
Author
Owner
Copy Link

@Morpheus636 commented on GitHub (Feb 12, 2025):

Other notes:

  • Setting SITE_URL to http:// prevents the redirects, but causes errors when the site is served on HTTPS by the proxy, because the panel will attempt to access assets via HTTP.
  • Setting the second Caddy instance to access the panel via https causes 502 errors.

Possible solutions:

I'm happy to open a pull request for either of the first 2 options, if there's a consensus about which one to implement.

Option 1: HTTP Catch-all

Change the Caddyfile built into the image to include an http:// catch-all rule. This can be done fairly easily, but requires disabling the implicit http->https redirect, as Caddy processes the redirect before the catch-all rule. source

This could have security implications (in that users could access the panel without SSL) but administrators could solve them by not forwarding port 80. That would cause connection refused errors should someone explicitly specify http://, should not affect modern browsers that use HTTPS by default.

Example (this is what I've used in my test deployment):

{
    admin off
    email {$ADMIN_EMAIL}
    auto_https disable_redirects
}

{$APP_URL} http:// {
    root * /var/www/html/public
    encode gzip

    php_fastcgi 127.0.0.1:9000
    file_server
}

Option 2: New Environment Variable

Create a new environment variable, such as SERVE_ON, to use instead of APP_URL only in the Caddyfile. The new variable could default to APP_URL if not specified, to avoid requiring additional configuration for "normal" installs.

Option 3: Document SKIP_CADDY

Document that running the panel behind a proxy that terminates TLS will not work and that users who want to do so should use SKIP_CADDY. Personally, this is my last choice; the other two options are relatively simple to implement, require little to no ongoing work from maintainers, and give the user more flexibility.

@Morpheus636 commented on GitHub (Feb 12, 2025): Other notes: - Setting SITE_URL to `http://` prevents the redirects, but causes errors when the site is served on HTTPS by the proxy, because the panel will attempt to access assets via HTTP. - Setting the second Caddy instance to access the panel via https causes 502 errors. ## Possible solutions: I'm happy to open a pull request for either of the first 2 options, if there's a consensus about which one to implement. ### Option 1: HTTP Catch-all Change the Caddyfile built into the image to include an `http://` catch-all rule. This can be done fairly easily, but requires disabling the implicit http->https redirect, as Caddy processes the redirect before the catch-all rule. [source](https://caddy.community/t/catch-all-too-greedy/21991/3) This could have security implications (in that users could access the panel without SSL) but administrators could solve them by not forwarding port 80. That would cause connection refused errors should someone explicitly specify http://, should not affect modern browsers that use HTTPS by default. Example (this is what I've used in my test deployment): ``` { admin off email {$ADMIN_EMAIL} auto_https disable_redirects } {$APP_URL} http:// { root * /var/www/html/public encode gzip php_fastcgi 127.0.0.1:9000 file_server } ``` ### Option 2: New Environment Variable Create a new environment variable, such as `SERVE_ON`, to use instead of `APP_URL` only in the Caddyfile. The new variable could default to `APP_URL` if not specified, to avoid requiring additional configuration for "normal" installs. ### Option 3: Document SKIP_CADDY Document that running the panel behind a proxy that terminates TLS will not work and that users who want to do so should use `SKIP_CADDY`. Personally, this is my last choice; the other two options are relatively simple to implement, require little to no ongoing work from maintainers, and give the user more flexibility.
OVERLORD commented 2026-02-04 17:17:54 +03:00
Author
Owner
Copy Link

@SirEndii commented on GitHub (Feb 12, 2025):

I've enabled caddy and served container port 80 to host port 9001 with a custom caddy file
I am not an expert on this - this is just how I did it/how someone recommended to me to do it
See https://github.com/pelican-dev/panel/discussions/967 if you are interested (Or even maybe you see some issue with that deployment)

@SirEndii commented on GitHub (Feb 12, 2025): I've enabled caddy and served container port 80 to host port 9001 with a custom caddy file I am not an expert on this - this is just how I did it/how someone recommended to me to do it See https://github.com/pelican-dev/panel/discussions/967 if you are interested (Or even maybe you see some issue with that deployment)
OVERLORD commented 2026-02-04 17:18:01 +03:00
Author
Owner
Copy Link

@Morpheus636 commented on GitHub (Feb 12, 2025):

I've enabled caddy and served container port 80 to host port 9001 with a custom caddy file

That's the Option 3 I listed (use SKIP_CADDY and host entirely with an external web server). It is a valid workaround, but I would much prefer to keep the panel container self-contained and reverse proxy to its built-in webserver.

@Morpheus636 commented on GitHub (Feb 12, 2025): > I've enabled caddy and served container port 80 to host port 9001 with a custom caddy file That's the Option 3 I listed (use SKIP_CADDY and host entirely with an external web server). It is a valid workaround, but I would much prefer to keep the panel container self-contained and reverse proxy to its built-in webserver.
OVERLORD commented 2026-02-04 17:18:02 +03:00
Author
Owner
Copy Link

@SirEndii commented on GitHub (Feb 12, 2025):

I agree at this point

@SirEndii commented on GitHub (Feb 12, 2025): I agree at this point
OVERLORD commented 2026-02-04 17:18:12 +03:00
Author
Owner
Copy Link

@kevinsnijder commented on GitHub (Feb 17, 2025):

I have the same problem, currently unable to make an NGINX reverse proxy to the pelican panel.
Edit: Fixed it with the caddyfile @Morpheus636 provided

@kevinsnijder commented on GitHub (Feb 17, 2025): I have the same problem, currently unable to make an NGINX reverse proxy to the pelican panel. Edit: Fixed it with the caddyfile @Morpheus636 provided
OVERLORD commented 2026-02-04 17:18:22 +03:00
Author
Owner
Copy Link

@redthirten commented on GitHub (Mar 13, 2025):

I just wanted to confirm this issue as well. Was trying to place the panel behind a Traefik reverse proxy that provides and terminates TLS for multiple sites, but ran into a slew of confusing issues:

  • I first naively set SKIP_CADDY: true thinking the container's internal Caddy instance was only providing a reverse proxy service. I had no idea it was also providing the webserver for php-fpm until I Googled php-fpm and learned it wasn't the webserver itself.
  • I then saw a support post in the Discord suggesting I try setting APP_URL to "https://mydomain.com, http://, https://". This got the panel working and connectable, but broke the SMTP Mail Driver because it was setting the HELO/EHLO argument to "mydomain.com, http", which my mail server denied.
  • I tried playing around with the TRUSTED_PROXIES environment variable, but I think it's broken? The panel expects this value to be an array, so setting it simply to "127.0.0.1" gives a 500 error on the admin settings page for providing a string when an array is expected. I'm not sure how to specify an array in my docker-compose file that would translate to a php-accepted array value.
  • Finally, I found this Issue thread which solved all my confusion (thank you @Morpheus636 !!!). I implemented Option 1, it worked like a charm, and I find it to be the path of least resistance in hindsight. My Traefik reverse proxy automatically forwards all HTTP traffic to HTTPS, so hopefully the previously mentioned security implications are thwarted by that, but please educate me if it doesn't.
@redthirten commented on GitHub (Mar 13, 2025): I just wanted to confirm this issue as well. Was trying to place the panel behind a Traefik reverse proxy that provides and terminates TLS for multiple sites, but ran into a slew of confusing issues: - I first naively set `SKIP_CADDY: true` thinking the container's internal Caddy instance was only providing a reverse proxy service. I had no idea it was also providing the webserver for php-fpm until I Googled php-fpm and learned it wasn't the webserver itself. - I then saw a support post in the Discord suggesting I try setting `APP_URL` to "https://mydomain.com, http://, https://". This got the panel working and connectable, but broke the SMTP Mail Driver because it was setting the HELO/EHLO argument to "mydomain.com, http", which my mail server denied. - I tried playing around with the `TRUSTED_PROXIES` environment variable, but I think it's broken? The panel expects this value to be an array, so setting it simply to "127.0.0.1" gives a 500 error on the admin settings page for providing a string when an array is expected. I'm not sure how to specify an array in my docker-compose file that would translate to a php-accepted array value. - Finally, I found this Issue thread which solved all my confusion (thank you @Morpheus636 !!!). I implemented Option 1, it worked like a charm, and I find it to be the path of least resistance in hindsight. My Traefik reverse proxy automatically forwards all HTTP traffic to HTTPS, so hopefully the previously mentioned security implications are thwarted by that, but please educate me if it doesn't.
OVERLORD commented 2026-02-04 17:18:30 +03:00
Author
Owner
Copy Link

@Lovinoes commented on GitHub (Mar 30, 2025):

I just wanted to confirm this issue as well. Was trying to place the panel behind a Traefik reverse proxy that provides and terminates TLS for multiple sites, but ran into a slew of confusing issues:

* I first naively set `SKIP_CADDY: true` thinking the container's internal Caddy instance was only providing a reverse proxy service. I had no idea it was also providing the webserver for php-fpm until I Googled php-fpm and learned it wasn't the webserver itself.

* I then saw a support post in the Discord suggesting I try setting `APP_URL` to "https://mydomain.com, http://, https://". This got the panel working and connectable, but broke the SMTP Mail Driver because it was setting the HELO/EHLO argument to "mydomain.com, http", which my mail server denied.

* I tried playing around with the `TRUSTED_PROXIES` environment variable, but I think it's broken? The panel expects this value to be an array, so setting it simply to "127.0.0.1" gives a 500 error on the admin settings page for providing a string when an array is expected. I'm not sure how to specify an array in my docker-compose file that would translate to a php-accepted array value.

* Finally, I found this Issue thread which solved all my confusion (thank you [@Morpheus636](https://github.com/Morpheus636) !!!). I implemented Option 1, it worked like a charm, and I find it to be the path of least resistance in hindsight. My Traefik reverse proxy automatically forwards all HTTP traffic to HTTPS, so hopefully the previously mentioned security implications are thwarted by that, but please educate me if it doesn't.

I want to confirm this issue as well. I experienced the same problems while using NGINX as a reverse proxy instead of Traefik. It only works when setting the APP_URL to HTTP instead of HTTPS, which seems counterintuitive. The same problems with SKIP_CADDY, TRUSTED_PROXIES, and SMTP also occurred in my setup

@Lovinoes commented on GitHub (Mar 30, 2025): > I just wanted to confirm this issue as well. Was trying to place the panel behind a Traefik reverse proxy that provides and terminates TLS for multiple sites, but ran into a slew of confusing issues: > > * I first naively set `SKIP_CADDY: true` thinking the container's internal Caddy instance was only providing a reverse proxy service. I had no idea it was also providing the webserver for php-fpm until I Googled php-fpm and learned it wasn't the webserver itself. > > * I then saw a support post in the Discord suggesting I try setting `APP_URL` to "https://mydomain.com, http://, https://". This got the panel working and connectable, but broke the SMTP Mail Driver because it was setting the HELO/EHLO argument to "mydomain.com, http", which my mail server denied. > > * I tried playing around with the `TRUSTED_PROXIES` environment variable, but I think it's broken? The panel expects this value to be an array, so setting it simply to "127.0.0.1" gives a 500 error on the admin settings page for providing a string when an array is expected. I'm not sure how to specify an array in my docker-compose file that would translate to a php-accepted array value. > > * Finally, I found this Issue thread which solved all my confusion (thank you [@Morpheus636](https://github.com/Morpheus636) !!!). I implemented Option 1, it worked like a charm, and I find it to be the path of least resistance in hindsight. My Traefik reverse proxy automatically forwards all HTTP traffic to HTTPS, so hopefully the previously mentioned security implications are thwarted by that, but please educate me if it doesn't. I want to confirm this issue as well. I experienced the same problems while using NGINX as a reverse proxy instead of Traefik. It only works when setting the APP_URL to HTTP instead of HTTPS, which seems counterintuitive. The same problems with SKIP_CADDY, TRUSTED_PROXIES, and SMTP also occurred in my setup
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
not confirmed
pull-request
Mirrored from GitHub Pull Request
 👑 sponsor
💰 fund
🔴 hard
🟡 medium
🟡 medium
🟡 medium
🟢 easy
🟢 easy
🟢 easy
No Label 🟡 medium
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/panel#257
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?