[BUG] websocket with virtual direcotyr not work

[barto95100]

WebSocket connections fail when routed through VirtualDirectory path-based rules, even though HTTP requests work correctly.

the configuration for websocket endpoint :

if I check log on backendno request arrived from zoraxyto /socket.io

Backend logs (proving WebSocket requests never reach backend through Zoraxy)
  // Through Zoraxy - NO socket.io logs, only HTTP:
  {"message":"Incoming request","method":"GET","path":"/api/v1/sessions",...}
  {"message":"Incoming request","method":"GET","path":"/health",...}
  // ❌ No socket.io connection attempts

and i test access directly without zoraxy :

  {"message":"[WebSocket] Client connected","socketId":"abc123",...} ✅```

  Backend application using Socket.IO: https://xxxxxxxxx/socket.io/

I view in log whenconfigure virtual directory with PAth zoraxy delete the PAth on resquest to backend

user request:

/api/v1/sessions -> Zoraxy sendto backend -> /v1/sessions

Why ? 

[tobychui]

@barto95100

As you can see here, automatic websocket proxy is also implemented with the same logic no matter it is in virtual directory or ordinary host type reverse proxy. So this is likely a configuration issue on your setup.

https://github.com/tobychui/zoraxy/blob/86a87a9c4a656b870da286bfc0ef5a01edb5d254/src/mod/dynamicproxy/proxyRequestHandler.go#L273C1-L299C3

/api/v1/sessions -> Zoraxy sendto backend -> /v1/sessions

Yes this is how Virtual Directories works. If you are expecting the request to reach /api/v1/sessions on your upstream, I guess you have confused the settings between Zoraxy Virtual Directory and Nginx location, which are two different things.

This is a common confusion from people who switch from Nginx to Zoraxy. Zoraxy Virtual Directory is not Nginx Locations, it works more closely to Apache Alias or IIS Virtual Directory (which this design was referenced from).

For clarification:

# Virtual Directory Settings
/api -> 192.168.1.183/api

# Will resolves to
/api/v1/sessions -> /v1/sessions

# After remove /api from Virtual Directory Settings
/api/v1/sessions -> /api/v1/sessions

Here are a few more examples

Host: example.com -> 192.168.0.1
VDir: /foo/bar -> 192.168.0.100/resources

# For Virtual Directory, link in brackets are rewritten path prefix so it resolves correctly on your upstream if use properly
/foo/bar/image.png -> (192.168.0.100/resources)/image.png
/foo/bar/js/myscript.js -> (192.168.0.100/resources)/js/myscript.js
/foo -> (192.168.0.1)/foo

# For Location type logics, this will become
/foo/bar/image.png -> (192.168.0.100/resources)/foo/bar/image.png
/foo/bar/js/myscript.js -> (192.168.0.100/resources)/foo/bar/js/myscript.js
/foo -> (192.168.0.1)/foo

# this is why you need proxy_pass in Nginx, which is another story and I am not covering it here.

You see the difference? Try remove the /socket.io virtual directory rule and see if it will works automatically?

[barto95100]

yes thank's for explanation for my usecase I configure with your exemple : /api -> 192.168.1.183/api worked

but for socket no if I delete or add 192.168.1.183:3003/socket.io = problem

for work I need to change and add other domain exemple:

xs.test.domain.com -> 192.168.1.183:3003 = work

[tobychui]

You sure that is not an upstream setup issue? Usually if a system is not designed to be virtual directory proxied, it is common to see problems like this.

[tobychui]

Closing this as this is probably a upstream system setup issue.