starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: Can not be run behind reverse proxy on Synology - port clash or routing issue #3137

New Issue
Closed
opened 2026-04-25 00:13:50 +02:00 by adam · 3 comments
adam commented 2026-04-25 00:13:50 +02:00
Owner
Copy Link
Copy Source

Originally created by @carsaig on GitHub (Dec 4, 2025).

What happened?

I don't quite know how to describe this best and I haven't dug into the network routing details yet - just no time.
The issue: I have multiple containers running on a Synology NAS, latest Firmware build and Hardware from 2024. I use the internal Synology NGINX Proxy for routing traffic to my containers. No issue whatsoever. THIS container however, ALWAYS routes to port 443 instead of the defined standard in the container settings! It plain ignores the setting. The UI works on the defined port - but only on http, not https.
And no, this has nothing to do with my setup, as ALL other containers can be run on http ports and the on-board Synology reverse proxy routes https traffic from port 443 to them without any issues. It's only this container miss-behaving.
The question is: why? It might be a bug or just a design decision, no idea.
I tried to set the port to some other than the suggested standard - without success. The UI expects port 13378 and no other. It's impossible to run this thing behind my reverse proxy. I haven't tried deploying it on my remote linux machines with ubuntu and Traefik yet - just to check what is going on in other environments - but I would like to run this locally.
So can anyone explain, why this behaviour exists and how to debug it?
Is this a routing issue or some weirdo headers that need altering on the reverse-proxy level? Or is the UI re-routing?
I have run out of ideas...

What did you expect to happen?

I would expect this containers UI to be available under the custom domain I configured on my reverse proxy on Synology, exposing the UI via https.

Steps to reproduce the issue

  1. Point a custom subdomain at my NAS as I do with dozens of other containers.
  2. Configure a certificate to match the domain and reverse proxy entry
  3. Configure a reverse proxy entry on a Synology NAS, pointing at this container and the pre-defined port in the docker-compose, diverting the 443 traffic to port 13378.
  4. Pull up the custom domain in the browser and it re-directs to the login-page of the NAS on port 443. This happens because Synology NGINX blocks this port for itself by default. Yeah, SUPER annoying - but that's the way it works. It looks as if the http traffic on port 13378 hits the UI and the UI then seems to re-direct to port 443 for some stupid reason I can't understand instead of letting the traffic proceed to the core application on the inbound port.

Audiobookshelf version

2.31.0

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Other (list in "Additional Notes" box)

If the issue is being seen in the UI, what browsers are you seeing the problem on?

Chrome

Logs

There are no specific logs that would help clarifying the issue:
Running in production mode.

Options: CONFIG_PATH=/config, METADATA_PATH=/metadata, PORT=8089, HOST=undefined, SOURCE=docker, ROUTER_BASE_PATH=/audiobookshelf

[2025-12-04 07:11:15.144] INFO: === Starting Server ===

[2025-12-04 07:11:15.161] INFO: [Server] Init v2.31.0

[2025-12-04 07:11:15.162] INFO: [Server] Node.js Version: v20.19.6

[2025-12-04 07:11:15.162] INFO: [Server] Platform: linux

[2025-12-04 07:11:15.163] INFO: [Server] Arch: x64

[2025-12-04 07:11:15.220] INFO: [Database] Initializing db at "/config/absdatabase.sqlite"

[2025-12-04 07:11:15.335] INFO: [Database] Loading extension /usr/local/lib/nusqlite3/libnusqlite3.so

[2025-12-04 07:11:15.338] INFO: [Database] Successfully loaded extension /usr/local/lib/nusqlite3/libnusqlite3.so

[2025-12-04 07:11:15.339] INFO: [Database] Db supports unaccent and unicode foldings

[2025-12-04 07:11:15.340] INFO: [Database] Db connection was successful

[2025-12-04 07:11:15.490] INFO: [MigrationManager] No migrations to run.

[2025-12-04 07:11:15.869] INFO: [Database] Db initialized with models: SequelizeMeta, user, session, apiKey, library, libraryFolder, book, podcast, podcastEpisode, libraryItem, mediaProgress, series, bookSeries, author, bookAuthor, collection, collectionBook, playlist, playlistMediaItem, device, playbackSession, feed, feedEpisode, setting, customMetadataProvider, mediaItemShare

[2025-12-04 07:11:15.976] WARN: Found series "audiobook_output" with no books - removing it

[2025-12-04 07:11:16.093] INFO: [Database] Server upgrade detected from 2.30.0 to 2.31.0

[2025-12-04 07:11:16.126] INFO: [Database] running ANALYZE

[2025-12-04 07:11:16.160] INFO: [Database] ANALYZE completed

[2025-12-04 07:11:16.162] INFO: [TokenManager] JWT secret key set from ENV variable

[2025-12-04 07:11:16.181] INFO: [LogManager] Removed daily log: 2025-11-12.txt

[2025-12-04 07:11:16.191] INFO: [LogManager] Removed daily log: 2025-11-13.txt

[2025-12-04 07:11:16.193] INFO: [LogManager] Removed daily log: 2025-11-14.txt

[2025-12-04 07:11:16.195] INFO: [LogManager] Removed daily log: 2025-11-18.txt

[2025-12-04 07:11:16.197] INFO: [LogManager] Removed daily log: 2025-11-19.txt

[2025-12-04 07:11:16.240] INFO: [LogManager] Removed daily log: 2025-11-20.txt

[2025-12-04 07:11:16.248] INFO: [LogManager] Removed daily log: 2025-11-21.txt

[2025-12-04 07:11:16.248] INFO: [LogManager] Init current daily log filename: 2025-12-04.txt

[2025-12-04 07:11:16.273] INFO: [BackupManager] 0 Backups Found

[2025-12-04 07:11:16.274] INFO: [BackupManager] Auto Backups are disabled

[2025-12-04 07:11:16.309] INFO: [Watcher] Initializing watcher for "audiobooks".

[2025-12-04 07:11:16.331] INFO: Listening on port :8089

[2025-12-04 07:11:17.443] INFO: [Watcher] "audiobooks" Ready

[2025-12-04 07:11:19.705] INFO: [SocketAuthority] Socket Connected to /audiobookshelf/socket.io GtTT7J-SWuvm5QGxAAAB

[2025-12-04 09:00:29.186] INFO: [SocketAuthority] Socket GtTT7J-SWuvm5QGxAAAB disconnected from client "julian" after 6549482ms (Reason: transport close)

[2025-12-04 09:00:29.572] INFO: [SocketAuthority] Socket Connected to /audiobookshelf/socket.io eSBIVYX6TCpIDpZxAAAD

[2025-12-04 15:47:17.892] INFO: [SocketAuthority] Socket eSBIVYX6TCpIDpZxAAAD disconnected from client "julian" after 24408321ms (Reason: transport close)

[2025-12-04 15:47:23.324] INFO: [SocketAuthority] Socket Connected to /audiobookshelf/socket.io cEf4bdgyq6s5VQ4DAAAF

Additional Notes

I tried targeting multiple different ports from the reverse proxy and configured the container accordingly - without success. It is hard-coded to 13378.
Just let me define whatever port I want to use on the container and don't interfere with hard-coded port settings or routing mechanisms. Let me do the routing. Just accept inbound traffic from the reverse proxy, I'll handle the rest.

Originally created by @carsaig on GitHub (Dec 4, 2025). ### What happened? I don't quite know how to describe this best and I haven't dug into the network routing details yet - just no time. The issue: I have multiple containers running on a Synology NAS, latest Firmware build and Hardware from 2024. I use the internal Synology NGINX Proxy for routing traffic to my containers. No issue whatsoever. THIS container however, ALWAYS routes to port 443 instead of the defined standard in the container settings! It plain ignores the setting. The UI works on the defined port - but only on http, not https. And no, this has nothing to do with my setup, as ALL other containers can be run on http ports and the on-board Synology reverse proxy routes https traffic from port 443 to them without any issues. It's only this container miss-behaving. The question is: why? It might be a bug or just a design decision, no idea. I tried to set the port to some other than the suggested standard - without success. The UI expects port 13378 and no other. It's impossible to run this thing behind my reverse proxy. I haven't tried deploying it on my remote linux machines with ubuntu and Traefik yet - just to check what is going on in other environments - but I would like to run this locally. So can anyone explain, why this behaviour exists and how to debug it? Is this a routing issue or some weirdo headers that need altering on the reverse-proxy level? Or is the UI re-routing? I have run out of ideas... ### What did you expect to happen? I would expect this containers UI to be available under the custom domain I configured on my reverse proxy on Synology, exposing the UI via https. ### Steps to reproduce the issue 1. Point a custom subdomain at my NAS as I do with dozens of other containers. 2. Configure a certificate to match the domain and reverse proxy entry 3. Configure a reverse proxy entry on a Synology NAS, pointing at this container and the pre-defined port in the docker-compose, diverting the 443 traffic to port 13378. 4. Pull up the custom domain in the browser and it re-directs to the login-page of the NAS on port 443. This happens because Synology NGINX blocks this port for itself by default. Yeah, SUPER annoying - but that's the way it works. It looks as if the http traffic on port 13378 hits the UI and the UI then seems to re-direct to port 443 for some stupid reason I can't understand instead of letting the traffic proceed to the core application on the inbound port. ### Audiobookshelf version 2.31.0 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Other (list in "Additional Notes" box) ### If the issue is being seen in the UI, what browsers are you seeing the problem on? Chrome ### Logs ```shell There are no specific logs that would help clarifying the issue: Running in production mode. Options: CONFIG_PATH=/config, METADATA_PATH=/metadata, PORT=8089, HOST=undefined, SOURCE=docker, ROUTER_BASE_PATH=/audiobookshelf [2025-12-04 07:11:15.144] INFO: === Starting Server === [2025-12-04 07:11:15.161] INFO: [Server] Init v2.31.0 [2025-12-04 07:11:15.162] INFO: [Server] Node.js Version: v20.19.6 [2025-12-04 07:11:15.162] INFO: [Server] Platform: linux [2025-12-04 07:11:15.163] INFO: [Server] Arch: x64 [2025-12-04 07:11:15.220] INFO: [Database] Initializing db at "/config/absdatabase.sqlite" [2025-12-04 07:11:15.335] INFO: [Database] Loading extension /usr/local/lib/nusqlite3/libnusqlite3.so [2025-12-04 07:11:15.338] INFO: [Database] Successfully loaded extension /usr/local/lib/nusqlite3/libnusqlite3.so [2025-12-04 07:11:15.339] INFO: [Database] Db supports unaccent and unicode foldings [2025-12-04 07:11:15.340] INFO: [Database] Db connection was successful [2025-12-04 07:11:15.490] INFO: [MigrationManager] No migrations to run. [2025-12-04 07:11:15.869] INFO: [Database] Db initialized with models: SequelizeMeta, user, session, apiKey, library, libraryFolder, book, podcast, podcastEpisode, libraryItem, mediaProgress, series, bookSeries, author, bookAuthor, collection, collectionBook, playlist, playlistMediaItem, device, playbackSession, feed, feedEpisode, setting, customMetadataProvider, mediaItemShare [2025-12-04 07:11:15.976] WARN: Found series "audiobook_output" with no books - removing it [2025-12-04 07:11:16.093] INFO: [Database] Server upgrade detected from 2.30.0 to 2.31.0 [2025-12-04 07:11:16.126] INFO: [Database] running ANALYZE [2025-12-04 07:11:16.160] INFO: [Database] ANALYZE completed [2025-12-04 07:11:16.162] INFO: [TokenManager] JWT secret key set from ENV variable [2025-12-04 07:11:16.181] INFO: [LogManager] Removed daily log: 2025-11-12.txt [2025-12-04 07:11:16.191] INFO: [LogManager] Removed daily log: 2025-11-13.txt [2025-12-04 07:11:16.193] INFO: [LogManager] Removed daily log: 2025-11-14.txt [2025-12-04 07:11:16.195] INFO: [LogManager] Removed daily log: 2025-11-18.txt [2025-12-04 07:11:16.197] INFO: [LogManager] Removed daily log: 2025-11-19.txt [2025-12-04 07:11:16.240] INFO: [LogManager] Removed daily log: 2025-11-20.txt [2025-12-04 07:11:16.248] INFO: [LogManager] Removed daily log: 2025-11-21.txt [2025-12-04 07:11:16.248] INFO: [LogManager] Init current daily log filename: 2025-12-04.txt [2025-12-04 07:11:16.273] INFO: [BackupManager] 0 Backups Found [2025-12-04 07:11:16.274] INFO: [BackupManager] Auto Backups are disabled [2025-12-04 07:11:16.309] INFO: [Watcher] Initializing watcher for "audiobooks". [2025-12-04 07:11:16.331] INFO: Listening on port :8089 [2025-12-04 07:11:17.443] INFO: [Watcher] "audiobooks" Ready [2025-12-04 07:11:19.705] INFO: [SocketAuthority] Socket Connected to /audiobookshelf/socket.io GtTT7J-SWuvm5QGxAAAB [2025-12-04 09:00:29.186] INFO: [SocketAuthority] Socket GtTT7J-SWuvm5QGxAAAB disconnected from client "julian" after 6549482ms (Reason: transport close) [2025-12-04 09:00:29.572] INFO: [SocketAuthority] Socket Connected to /audiobookshelf/socket.io eSBIVYX6TCpIDpZxAAAD [2025-12-04 15:47:17.892] INFO: [SocketAuthority] Socket eSBIVYX6TCpIDpZxAAAD disconnected from client "julian" after 24408321ms (Reason: transport close) [2025-12-04 15:47:23.324] INFO: [SocketAuthority] Socket Connected to /audiobookshelf/socket.io cEf4bdgyq6s5VQ4DAAAF ``` ### Additional Notes I tried targeting multiple different ports from the reverse proxy and configured the container accordingly - without success. It is hard-coded to 13378. Just let me define whatever port I want to use on the container and don't interfere with hard-coded port settings or routing mechanisms. Let me do the routing. Just accept inbound traffic from the reverse proxy, I'll handle the rest.
adam added the bug label 2026-04-25 00:13:50 +02:00
adam closed this issue 2026-04-25 00:13:50 +02:00
adam commented 2026-04-25 00:13:50 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Dec 4, 2025):

THIS container however, ALWAYS routes to port 443 instead of the defined standard in the container settings! It plain ignores the setting. The UI works on the defined port - but only on http, not https.

This container uses port 13378 as per the fault config (running inside the container on 80)
It does not support Https, that's why you need to use an RP and why it does not work on https.

If your port clash, just do not bind it to 443?
In the logs you shared it successfully started on 8089.

Maybe can you explain your problem with less text and more context.
Your steps don't really make sense.

Your RP would run on 443, which would resolve the 13378. If you redirect to 13378, you do not use the RP. If ABS does loose its context where to redirect, the RP does not provide the headers

@Vito0912 commented on GitHub (Dec 4, 2025): > THIS container however, ALWAYS routes to port 443 instead of the defined standard in the container settings! It plain ignores the setting. The UI works on the defined port - but only on http, not https. This container uses port 13378 as per the fault config (running inside the container on 80) It does not support Https, that's why you need to use an RP and why it does not work on https. If your port clash, just do not bind it to 443? In the logs you shared it successfully started on 8089. Maybe can you explain your problem with less text and more context. Your steps don't really make sense. Your RP would run on 443, which would resolve the 13378. If you redirect to 13378, you do not use the RP. If ABS does loose its context where to redirect, the RP does not provide the headers
adam commented 2026-04-25 00:13:51 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Dec 4, 2025):

This is a user configuration issue. The internal port of the container is set to 80, but you can configure the external port to anything you want using the port mapping in your container definition (such as in docker compose), the default is just 13378. We do not support SSL in the container, this must be handled by your reverse proxy or external to the ABS instance before going to port 80 inside of the container.

You can also change the port the ABS port uses inside of the container using the PORT environment variable as described in https://www.audiobookshelf.org/docs#network, but note this will not work with SSL.

Edit to add: The readme tells you how to configure using the built-in Synology reverse proxy. https://github.com/advplyr/audiobookshelf?tab=readme-ov-file#synology-nas-reverse-proxy-setup-dsm-7quickconnect

@nichwall commented on GitHub (Dec 4, 2025): This is a user configuration issue. The internal port of the container is set to 80, but you can configure the external port to anything you want using the port mapping in your container definition (such as in docker compose), the default is just 13378. We do not support SSL in the container, this must be handled by your reverse proxy or external to the ABS instance before going to port 80 inside of the container. You can also change the port the ABS port uses inside of the container using the PORT environment variable as described in https://www.audiobookshelf.org/docs#network, but note this will not work with SSL. Edit to add: The readme tells you how to configure using the built-in Synology reverse proxy. https://github.com/advplyr/audiobookshelf?tab=readme-ov-file#synology-nas-reverse-proxy-setup-dsm-7quickconnect
adam commented 2026-04-25 00:13:51 +02:00
Author
Owner
Copy Link
Copy Source

@carsaig commented on GitHub (Dec 25, 2025):

I must confess, this was indeed on my side. Synology tricked me. Again. The reverse proxy had crippled itself with the last Synology update. Looking at the core system nginx config file revealed malformed URL entries in the reverse proxy entry for audiobookshelf. I corrected them right there at the root of the issue and the reverse proxy came back up as it should. How did this happen? The reverse proxy entry for audiobookshelf was the latest one added to the list of long existing (stable) entries. The reverse proxy however, had obviously undergone a minor change with the latest Synology update which crippled the URL to a .local annotation. Weird but that was the problem, resulting in an internal redirect. So please forgive me for opening this issue. I dug deep but failed. I was too fast to claim an issue although I rarely ever do that. Damn me.
Issue solved.

@carsaig commented on GitHub (Dec 25, 2025): I must confess, this was indeed on my side. Synology tricked me. Again. The reverse proxy had crippled itself with the last Synology update. Looking at the core system nginx config file revealed malformed URL entries in the reverse proxy entry for audiobookshelf. I corrected them right there at the root of the issue and the reverse proxy came back up as it should. How did this happen? The reverse proxy entry for audiobookshelf was the latest one added to the list of long existing (stable) entries. The reverse proxy however, had obviously undergone a minor change with the latest Synology update which crippled the URL to a .local annotation. Weird but that was the problem, resulting in an internal redirect. So please forgive me for opening this issue. I dug deep but failed. I was too fast to claim an issue although I rarely ever do that. Damn me. Issue solved.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#3137
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?