Getting 404 for bundle.js when behind reverse proxy with non-root path about audioserve

[izderadicka]

bundle.js is only for Web client.
Most probable guess is that it's missing from the client/dist directory - have you checked direct connection - without proxy?
What deployment are you using? Docker, static files, own build? Have you build the web client? audioserve is serving client files by default for ./client/dist where two files should reside index.html and bundle.js. What about access rights to bundle.js - if audioserve process will not have read access I think it will also lead to 404 error.

Any more logs?

[izderadicka]

Or it's purely proxy problem - URL mapping - if rev. proxy should present audioserve on https://my.dns.name/audioserve the bundle.js URL should be https://my.dns.name/audioserve/bundle.js not https://my.dns.name/bundle.js

[zais]

Yes it works just ok locally, will try to search what can caddy to do 'rewrite' urls

[izderadicka]

This is my configuration for nginx, if it helps:

location /audioserve/ {
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Host  $http_host;
        proxy_set_header Host              $http_host;
        proxy_max_temp_file_size           0;
        proxy_pass                         http://127.0.0.1:3000/;
        proxy_redirect                     http:// https://;
        proxy_read_timeout 1200s;
        send_timeout 1200s;
        }

[zais]

Below works for me, but only if accessed like https://my.dns.name/audioserver/

  proxy /audioserve http://127.0.0.1:3001 {
    without /audioserve/
    transparent
    websocket
  }

Anyway a valid workaround :)

[izderadicka]

Thanks for update - I'm closing now as it looks like solely proxy configuration issue

[mattlev]

This is my configuration for nginx

Where do you have this configuration? Is it in a server bracket or listening on certain ports? depending on where I put said configuration (I'm using the one from reverse_proxy.md) I can either have nothing happen, or take down my reverse proxy, but haven't gotten it to work yet. Non-reverse proxy on my local network works perfectly though so it's definitely some kind of reverse proxy websocket problem since the websocket is giving a 400 bad request when using the reverse proxy.

[izderadicka]

Yes websocket is specific for nginx - this is what I set for websocket URL:

 location /audioserve/position {
      proxy_pass http://localhost:3000/position;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
      proxy_set_header Host              $http_host;
      proxy_read_timeout 3600s;
        }

main are - HTTP has to be 1.1 and Upgrade: websocket, Connection: upgrade - this is not default by nginx so that why I had special entry for this.

[izderadicka]

Another possibility is to have mapping definition for Upgrade and then you can have simpler nginx config, which handles both regular http requests and websocket requests:

map 	$http_upgrade $proxy_connection {
	default upgrade;
  	'' close;
	}


server {
	server_name localhost;
	listen 3000;

	
	location / {
		proxy_pass 	http://localhost:3003;
		proxy_http_version	1.1;
		proxy_buffering 	off;
		proxy_set_header 	Host $http_host;
		proxy_set_header 	Upgrade $http_upgrade;
		proxy_set_header 	Connection $proxy_connection;
		proxy_set_header 	Forwarded         "for=$remote_addr;port=$remote_port;host=$http_host;proto=https";
		proxy_set_header 	X-Forwarded-For   $proxy_add_x_forwarded_for;
        	proxy_max_temp_file_size           0;
		proxy_read_timeout 	1200s;
        	send_timeout 	1200s;
	}
		

	}

[mattlev]

If I try putting anything not in a server block (like the map section) it seems to stop my reverse proxy in its tracks and none of the pages behind it ever can be connected to. I've tried putting the whole most recent thing, the two sections from reverse_proxy.md, and just the earlier websocket part here (all at different times of course) in the server block with listening on 3000 and that doesn't take down the proxy, but doesn't fix the websocket problems. I'm looking at the networking requests and in Request Headers it is saying the origin is https://domain and the connection field does have "Upgrade" but the Response Headers don't have that info or anything about the websocket if that's helpful info. I'm not sure what isn't getting redirected/upgraded correctly.