Cannot access bookstack behind caddy reverse proxy when using a subdirectory #3502

Closed
opened 2026-02-05 06:55:10 +03:00 by OVERLORD · 3 comments
Owner

Originally created by @mlcampbe on GitHub (Feb 11, 2023).

Attempted Debugging

  • I have read the debugging page

Searched GitHub Issues

  • I have searched GitHub for the issue.

Describe the Scenario

This is similar to https://github.com/BookStackApp/BookStack/issues/801 but using a subdirectory andI am seeing the same http-404 when trying to access css/js/etc...

I can verify that using caddy does work if I make my TLD be the one serving the pages. For example, in the Caddyfile if I have this:

hostname.duckdns.org{
  reverse_proxy /* bookstack:80
}

And in by docker-compose.yaml for bookstack I have the APP_URL set to https://hostname.duckdns.org accessing https://hostname.duckdns.org works perfectly and I can login successfully.

But I am trying to serve bookstack from a sub-folder such as /notes and cannot get that to work. In this case I see the same large images and http header traces show http-404 errors. For example if I have the Caddyfile:

hostname.duckdns.org{
  reverse_proxy /notes/* bookstack:80
}

and in the bookstack docker-compose.yaml file I have APP_URL=https://hostname.duckdns.org/notes it is not working.

I suspect that we need to do something like described in https://www.bookstackapp.com/docs/admin/subdirectory-setup/ but not sure how to interpret the apache or nginx pieces mentioned there for caddy.

Any thoughts on how to configure caddy to do this?

Exact BookStack Version

23.01.1

Log Content

No errors from bookstack log nor from caddy log

PHP Version

No response

Hosting Environment

Using Docker running the lcsr.io/linuxserver/bookstack image and caddy:latest image.

Originally created by @mlcampbe on GitHub (Feb 11, 2023). ### Attempted Debugging - [X] I have read the debugging page ### Searched GitHub Issues - [X] I have searched GitHub for the issue. ### Describe the Scenario This is similar to https://github.com/BookStackApp/BookStack/issues/801 but using a subdirectory andI am seeing the same http-404 when trying to access css/js/etc... I can verify that using caddy does work if I make my TLD be the one serving the pages. For example, in the Caddyfile if I have this: ``` hostname.duckdns.org{ reverse_proxy /* bookstack:80 } ``` And in by docker-compose.yaml for bookstack I have the APP_URL set to https://hostname.duckdns.org accessing https://hostname.duckdns.org works perfectly and I can login successfully. But I am trying to serve bookstack from a sub-folder such as /notes and cannot get that to work. In this case I see the same large images and http header traces show http-404 errors. For example if I have the Caddyfile: ``` hostname.duckdns.org{ reverse_proxy /notes/* bookstack:80 } ``` and in the bookstack docker-compose.yaml file I have APP_URL=https://hostname.duckdns.org/notes it is not working. I suspect that we need to do something like described in https://www.bookstackapp.com/docs/admin/subdirectory-setup/ but not sure how to interpret the apache or nginx pieces mentioned there for caddy. Any thoughts on how to configure caddy to do this? ### Exact BookStack Version 23.01.1 ### Log Content No errors from bookstack log nor from caddy log ### PHP Version _No response_ ### Hosting Environment Using Docker running the lcsr.io/linuxserver/bookstack image and caddy:latest image.
OVERLORD added the 🐕 Support label 2026-02-05 06:55:10 +03:00
Author
Owner

@mlcampbe commented on GitHub (Feb 11, 2023):

Ok I have made this work but it still appears to be a config/bug with bookstack. In the Caddyfile I changed:

hostname.duckdns.org{
  reverse_proxy /* bookstack:80
}

to

hostname.duckdns.org{
  handle_path /notes* {
    reverse_proxy bookstack:80
  }
}

This forces caddy to strip off the /notes prefix before it sends the request to the bookstack docker container. This works but still seems like we should not have to force caddy to do that.

@mlcampbe commented on GitHub (Feb 11, 2023): Ok I have made this work but it still appears to be a config/bug with bookstack. In the Caddyfile I changed: ``` hostname.duckdns.org{ reverse_proxy /* bookstack:80 } ``` to ``` hostname.duckdns.org{ handle_path /notes* { reverse_proxy bookstack:80 } } ``` This forces caddy to strip off the /notes prefix before it sends the request to the bookstack docker container. This works but still seems like we should not have to force caddy to do that.
Author
Owner

@ssddanbrown commented on GitHub (Feb 11, 2023):

This works but still seems like we should not have to force caddy to do that.

Is there a reason for that? Are you getting issues? This generally aligns with the behavior of what we advise in the nginx subdir setup. Some apps may specifically handle path-prefixes app-side but bookstack will expect incoming paths to be prefix/sub-path free.

@ssddanbrown commented on GitHub (Feb 11, 2023): > This works but still seems like we should not have to force caddy to do that. Is there a reason for that? Are you getting issues? This generally aligns with the behavior of what we advise in the nginx subdir setup. Some apps may specifically handle path-prefixes app-side but bookstack will expect incoming paths to be prefix/sub-path free.
Author
Owner

@mlcampbe commented on GitHub (Feb 12, 2023):

I was not aware that bookstack expected the prefix to be based off of the webserver root. I was expecting a way to configure bookstack to be able to take the APP_URL to prefix all of its internal calls. But, it seems that is not the case and so it is working properly. Thanks for the reply.

@mlcampbe commented on GitHub (Feb 12, 2023): I was not aware that bookstack expected the prefix to be based off of the webserver root. I was expecting a way to configure bookstack to be able to take the APP_URL to prefix all of its internal calls. But, it seems that is not the case and so it is working properly. Thanks for the reply.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#3502