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]: Websocket issue #2534

New Issue
Closed
opened 2026-04-25 00:08:06 +02:00 by adam · 12 comments
adam commented 2026-04-25 00:08:06 +02:00
Owner
Copy Link
Copy Source

Originally created by @alternativesurfer on GitHub (Jan 29, 2025).

What happened?

Issue #3868 was taken over by Synology users and the base problem was never reviewed.

I do not use Synology, just running Docker on an ubuntu server.
This seems unrelated to the Synology people since I never lost access to my front end.

This was working previously on 2.17.3 without error.
I was out of town so didn't patch between then and 2.18.0.

I am running through HAProxy. No config change on that end.
The only thing failing is the Socket error. I am able to load the GUI and playback items.

Direct to IP also works, but with the same socket error.

Something definitely changed, because previously there were no websocket issues when I used HAProxy (not Apache).

Now my console is filled with these errors:
Image

Timing wise, I suspect this is what broke it: https://github.com/advplyr/audiobookshelf/pull/3754
I added the env flag: EXP_PROXY_SUPPORT=1 to test, still not working.

So, I believe whatever fix was put into place for that issue broke proxy support for those of us it was already working for.

What did you expect to happen?

The websocket connects.

Steps to reproduce the issue

  1. Launch app.
  2. error exists

Audiobookshelf version

v2.18.0

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

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

Other (list in "Additional Notes" box)

Logs

The only thing I can see related to the websocket is: 
2025-01-20 20:52:05.099

DEBUG

[SocketAuthority] clientEmitter - no clients found for user 06835809-8b6a-47fe-81fd-1677b1ddf6c6

Additional Notes

UI errors:
Edge
Firefox (windows)
Fennec (Android)

as well as the Android Audiobookshelf App & Lissen app.

Originally created by @alternativesurfer on GitHub (Jan 29, 2025). ### What happened? Issue #3868 was taken over by Synology users and the base problem was never reviewed. I do not use Synology, just running Docker on an ubuntu server. This seems unrelated to the Synology people since I never lost access to my front end. This was working previously on 2.17.3 without error. I was out of town so didn't patch between then and 2.18.0. I am running through HAProxy. No config change on that end. The only thing failing is the Socket error. I am able to load the GUI and playback items. Direct to IP also works, but with the same socket error. Something definitely changed, because previously there were no websocket issues when I used HAProxy (not Apache). Now my console is filled with these errors: ![Image](https://github.com/user-attachments/assets/cbccb6c9-a09d-45bf-a989-516dc19b07a9) Timing wise, I suspect this is what broke it: https://github.com/advplyr/audiobookshelf/pull/3754 I added the env flag: EXP_PROXY_SUPPORT=1 to test, still not working. So, I believe whatever fix was put into place for that issue broke proxy support for those of us it was already working for. ### What did you expect to happen? The websocket connects. ### Steps to reproduce the issue 1. Launch app. 2. error exists ### Audiobookshelf version v2.18.0 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? Other (list in "Additional Notes" box) ### Logs ```shell The only thing I can see related to the websocket is: 2025-01-20 20:52:05.099 DEBUG [SocketAuthority] clientEmitter - no clients found for user 06835809-8b6a-47fe-81fd-1677b1ddf6c6 ``` ### Additional Notes UI errors: Edge Firefox (windows) Fennec (Android) as well as the Android Audiobookshelf App & Lissen app.
adam added the bug label 2026-04-25 00:08:06 +02:00
adam closed this issue 2026-04-25 00:08:06 +02:00
adam commented 2026-04-25 00:08:07 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jan 29, 2025):

2.18.0 added a forced subdirectory of audiobookshelf/. If you are already using a subdomain, the web client redirects to the subdirectory, but everything is still accessible using the subdomain paths. Does HAProxy handle subdirectories differently?

@nichwall commented on GitHub (Jan 29, 2025): 2.18.0 added a forced subdirectory of `audiobookshelf/`. If you are already using a subdomain, the web client redirects to the subdirectory, but everything is still accessible using the subdomain paths. Does HAProxy handle subdirectories differently?
adam commented 2026-04-25 00:08:07 +02:00
Author
Owner
Copy Link
Copy Source

@mikiher commented on GitHub (Jan 30, 2025):

Can you please share your HAProxy setup?

@mikiher commented on GitHub (Jan 30, 2025): Can you please share your HAProxy setup?
adam commented 2026-04-25 00:08:07 +02:00
Author
Owner
Copy Link
Copy Source

@alternativesurfer commented on GitHub (Jan 30, 2025):

Can you please share your HAProxy setup?

Config attached:
haproxy (1).txt

Looks like it doesn't include my real servers info:
name: jc-audiobookshelf
type: static
IP: 192.168.20.56
port: 80

@alternativesurfer commented on GitHub (Jan 30, 2025): > Can you please share your HAProxy setup? Config attached: [haproxy (1).txt](https://github.com/user-attachments/files/18608059/haproxy.1.txt) Looks like it doesn't include my real servers info: name: jc-audiobookshelf type: static IP: 192.168.20.56 port: 80
adam commented 2026-04-25 00:08:07 +02:00
Author
Owner
Copy Link
Copy Source

@alternativesurfer commented on GitHub (Jan 30, 2025):

2.18.0 added a forced subdirectory of audiobookshelf/. If you are already using a subdomain, the web client redirects to the subdirectory, but everything is still accessible using the subdomain paths. Does HAProxy handle subdirectories differently?

Not to my knowledge.
It does properly route to the backend server with the client redirecting to the subdirectory:

Image

However, the websocket always fails to connect:

Image

@alternativesurfer commented on GitHub (Jan 30, 2025): > 2.18.0 added a forced subdirectory of `audiobookshelf/`. If you are already using a subdomain, the web client redirects to the subdirectory, but everything is still accessible using the subdomain paths. Does HAProxy handle subdirectories differently? Not to my knowledge. It does properly route to the backend server with the client redirecting to the subdirectory: ![Image](https://github.com/user-attachments/assets/ce3a1ab0-913b-4095-b43d-3ad04b344b6a) However, the websocket always fails to connect: ![Image](https://github.com/user-attachments/assets/60d04eb2-2732-465c-bfa0-b6336f240d2c)
adam commented 2026-04-25 00:08:08 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jan 30, 2025):

Throwing the config at chatgpt says there is an issue with the http-server-close because that closes connections instead of allowing the websocket to remain open. I am not familiar with HAProxy configuration, but I don't see anything in your config about upgrading to a websocket connection.

@nichwall commented on GitHub (Jan 30, 2025): Throwing the config at chatgpt says there is an issue with the `http-server-close` because that closes connections instead of allowing the websocket to remain open. I am not familiar with HAProxy configuration, but I don't see anything in your config about upgrading to a websocket connection.
adam commented 2026-04-25 00:08:08 +02:00
Author
Owner
Copy Link
Copy Source

@alternativesurfer commented on GitHub (Jan 30, 2025):

Yeah, I've been through many iterations trying to resolve this.
The original config did not have http-server-close, it only had:
option forwardfor

HAProxy does not require extra tooling to support websockets. It detects the initial header (or API) and switches from hhttp to websocket.

The only changes needed are to edit timeout rules to ensure the server doesn't cut them too soon.
timeout client 50000ms
timeout connect 5000ms
timeout server 50000ms

For the sake of troubleshooting this in my original working config, I have removed all additional backend options except for forwardfor.
Tested, same result.

@alternativesurfer commented on GitHub (Jan 30, 2025): Yeah, I've been through many iterations trying to resolve this. The original config did not have http-server-close, it only had: option forwardfor HAProxy does not require extra tooling to support websockets. It detects the initial header (or API) and switches from hhttp to websocket. The only changes needed are to edit timeout rules to ensure the server doesn't cut them too soon. timeout client 50000ms timeout connect 5000ms timeout server 50000ms For the sake of troubleshooting this in my original working config, I have removed all additional backend options except for forwardfor. Tested, same result.
adam commented 2026-04-25 00:08:08 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jan 30, 2025):

Can you share the original config that is not working?

@nichwall commented on GitHub (Jan 30, 2025): Can you share the original config that is not working?
adam commented 2026-04-25 00:08:08 +02:00
Author
Owner
Copy Link
Copy Source

@mikiher commented on GitHub (Jan 30, 2025):

Just to make sure: you have redacted the config, replacing your domain with EXAMPLE, right?

Can you also share a screenshot of the status code, as well as the request and response headers for the wss request (in Edge developer tools, Network tab, select WS in the filter line, and click on the request line)

@mikiher commented on GitHub (Jan 30, 2025): Just to make sure: you have redacted the config, replacing your domain with EXAMPLE, right? Can you also share a screenshot of the status code, as well as the request and response headers for the wss request (in Edge developer tools, Network tab, select WS in the filter line, and click on the request line)
adam commented 2026-04-25 00:08:08 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Feb 5, 2025):

Are you still working on this?

@advplyr commented on GitHub (Feb 5, 2025): Are you still working on this?
adam commented 2026-04-25 00:08:08 +02:00
Author
Owner
Copy Link
Copy Source

@mikiher commented on GitHub (Feb 5, 2025):

I asked a question and am waiting for a response.

@mikiher commented on GitHub (Feb 5, 2025): I asked a question and am waiting for a response.
adam commented 2026-04-25 00:08:09 +02:00
Author
Owner
Copy Link
Copy Source

@simono41 commented on GitHub (May 2, 2025):

I had the same problem with WebSocket connections under Audiobookshelf despite using Caddy as a reverse proxy. Although Caddy supports WebSockets by default, explicit routing for the Socket.io path helped me:

podcasts.brothertec.eu {
 @ws {
 header Connection *Upgrade*
 header Upgrade websocket
 }
 route /audiobookshelf/socket.io/* {
 reverse_proxy @ws 10.201.1.57:80
 }
 route {
 reverse_proxy 10.201.1.57:80
 }
}
@simono41 commented on GitHub (May 2, 2025): I had the same problem with WebSocket connections under Audiobookshelf despite using Caddy as a reverse proxy. Although Caddy supports WebSockets by default, explicit routing for the Socket.io path helped me: ~~~ podcasts.brothertec.eu { @ws { header Connection *Upgrade* header Upgrade websocket } route /audiobookshelf/socket.io/* { reverse_proxy @ws 10.201.1.57:80 } route { reverse_proxy 10.201.1.57:80 } } ~~~
adam commented 2026-04-25 00:08:09 +02:00
Author
Owner
Copy Link
Copy Source

@tomorrow-nf commented on GitHub (May 22, 2025):

I had the same problem with WebSocket connections under Audiobookshelf despite using Caddy as a reverse proxy. Although Caddy supports WebSockets by default, explicit routing for the Socket.io path helped me:

podcasts.brothertec.eu {
 @ws {
 header Connection *Upgrade*
 header Upgrade websocket
 }
 route /audiobookshelf/socket.io/* {
 reverse_proxy @ws 10.201.1.57:80
 }
 route {
 reverse_proxy 10.201.1.57:80
 }
}

Unfortunately this didn't seem to resolve it for me. Seeing the same issue with a near identical Caddy config.

Image

EDIT: Weirdly enough my issue seems to be from changing the CSS with ThemePark (https://github.com/themepark-dev/theme.park). Removing the Filter clause resolves the issue on my end. Unfortunate, I liked the custom CSS.

@tomorrow-nf commented on GitHub (May 22, 2025): > I had the same problem with WebSocket connections under Audiobookshelf despite using Caddy as a reverse proxy. Although Caddy supports WebSockets by default, explicit routing for the Socket.io path helped me: > > ``` > podcasts.brothertec.eu { > @ws { > header Connection *Upgrade* > header Upgrade websocket > } > route /audiobookshelf/socket.io/* { > reverse_proxy @ws 10.201.1.57:80 > } > route { > reverse_proxy 10.201.1.57:80 > } > } > ``` Unfortunately this didn't seem to resolve it for me. Seeing the same issue with a near identical Caddy config. ![Image](https://github.com/user-attachments/assets/cabc7a68-ea6b-4247-a58b-49aa59061f4f) EDIT: Weirdly enough my issue seems to be from changing the CSS with ThemePark (https://github.com/themepark-dev/theme.park). Removing the Filter clause resolves the issue on my end. Unfortunate, I liked the custom CSS.
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#2534
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?