Unexpected server response 503 using websocket endpoint

Hello. I am facing an issue when trying to connect to the /api/socket endpoint using a ws request.

The issue:

Attempt directly inside the server hosting traccar bypassing any apache proxies:

wscat -c ws://127.0.0.1:8082/api/socket -H "Cookie: JSESSIONID=REDACTED"
error: Unexpected server response: 503

Attempt from outside the server on associated domain:

websocat wss://REDACTED/api/socket -H "Cookie: JSESSIONID=REDACTED"
websocat: WebSocketError: WebSocketError: Received unexpected status code (503 Service Unavailable)
websocat: error running

My traccar.xml config:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM 'http://java.sun.com/dtd/properties.dtd'>
<properties>
    <!-- Documentation: https://www.traccar.org/configuration-file/ -->
    <entry key='database.driver'>com.mysql.cj.jdbc.Driver</entry>
    <entry key='database.url'>jdbc:mysql://REDACTED:3306/traccar?useSSL=false&amp;serverTimezone=UTC</entry>
    <entry key='database.user'>REDACTED</entry>
    <entry key='database.password'>REDACTED</entry>
    <entry key='logger.level'>all</entry>
</properties>

Web version of Traccar works as expected. I can see devices move around the map. I think it is a server related issue, but what bothers me is the fact that even the localhost ws request bypassing proxies throw the same error and produces the same log.
Traccar server log pastebin

cat /etc/apache2/sites-available/traccar.conf (used the example provided in the secure-connection document):

<VirtualHost *:80>
  ServerName REDACTED
  Redirect / https://REDACTED/
</VirtualHost>
<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerName REDACTED
                ServerAdmin webmaster@localhost

                DocumentRoot /var/www/html

                ProxyPass /api/socket ws://localhost:8082/api/socket
                ProxyPassReverse /api/socket ws://localhost:8082/api/socket

                ProxyPass / http://localhost:8082/
                ProxyPassReverse / http://localhost:8082/

                SSLEngine on
                SSLCertificateFile /etc/letsencrypt/live/REDACTED/fullchain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/REDACTED/privkey.pem
                Include /etc/letsencrypt/options-ssl-apache.conf
        </VirtualHost>
</IfModule>

ChatGPTs take on the traccar server logs:

Missing WebSocket Upgrade Factory:
The server logs indicate that there is no registered factory to handle the “Upgrade: websocket” request.
Absent Frame Handler:
Even after negotiating a WebSocket connection, no frame handler is provided, so the connection isn’t properly transitioned to a WebSocket session.
Incorrect Endpoint Mapping:
The /api/socket endpoint is being processed by a servlet (with Guice/Jersey), rather than a dedicated WebSocket handler, causing the request to fall back to standard HTTP processing.
Unconsumed Content Issue:
A StaticException: Unconsumed content error suggests leftover request data due to the failed upgrade process.
Session Handling Note:
Although sessions are mentioned (e.g., missing session from the cookie), this appears to be a secondary issue relative to the WebSocket upgrade failure.

Did you actually check the webbrowser developer console and check Network / WS. Refresh the page F5 on the map and then from WS window click on Socket in the dev console and check Headers and Messages

Yeah it works.

From the browser I see this request:

The only main difference I see in the requests, is that the cookie is a bit different on the web. Here's an old one for example from the /api/session/token endpoint that I use in my ws requests from websocat or insomnia:

SDBGAiEA6C********UodjMg2-41d0dMzNtHzpIYoMYcueRu6SICIQDKxzqc-iYq5L6q6r-vhFJq_G-4RB*****AGdSjeWss0HsidSI6ODAsImUiOiIyMDI1LTA0LTE4VDEyOjAw*****jUxOSswMDowMCJ9

It keeps updating under the messages tab ?

Yeah with about 1-3 seconds interval it seems

SOOOOO My coworker figured it out.

Apparently, it is not enough to fetch the user token, one has to CREATE a session using the /api/session?token=XXXX endpoint and only THEN you can call the /api/socket endpoint.

Yeah, it seems like you confused authentication token with session id.

The error happens when the Session Cookie expires, here is my step-by-step guide to replicate this issue:

1. You log in with a normal user, save the cookie somewhere.
2. Try to connect to the websocket using that cookie, it should work normally
3. Then, log out via web or close the session using the DELETE endpoint, or just wait for the expiration time of that session.
4. Finally if you try to connect to the websocket endpoint using the initial Session Cookie, it throws a 503 status code.

In my case, this obviously happens because I'm trying to use the websocket endpoint in my app, so I have to refresh the session cookie each certain time

In my opinion, I would like to expect a 400/401 for this scenario. What do you think guys?

It's probably better to return 401. Feel free to send a pull request for this.