Hosting rocket chat in subdirectory nearly works


I’m trying to host rocket chat in a subfolder using nginx as a reverse proxy server. I set up the rocketchat.service file so that it works properly with ROOT_URL=http://localhost

Then I changed that to ROOT_URL=http://localhost/chat and added these rules to the nginx configuration file.

location ~* “^/[a-z0-9]{40}.(css|js)$” {
root /opt/rocket/Rocket.Chat/programs/web.browser;
access_log off;
expires max;

location ~ ^/packages {
root /opt/rocket/Rocket.Chat/programs/web.browser;
access_log off;

location ~ ^/(images|sounds|assets|sockjs|fonts|theme|__meteor__) {
rewrite ^ /chat$uri;

location /chat {
proxy_http_version 1.1;

  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_set_header Host $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forward-Proto http;
  proxy_set_header X-Nginx-Proxy true;

  proxy_pass http://localhost:3000/chat;
  proxy_redirect off;


There are no 404 errors, but I’m getting what looks like an ajax error from the server. How can I debug this?

Update: Apparently this occurs when the client is expecting a json response but receives html.

  • Version of Rocket.Chat Server: 3.0.4
  • Operating System: Ubuntu 18.04 TLS
  • Deployment Method: tar
  • Number of Running Instances: 1
  • DB Replicaset Oplog: rs01
  • NodeJS Version: 12.14.0
  • MongoDB Version: 4.2.6
  • Proxy: nginx
  • Firewalls involved: ubuntu

There’s a serious problem here in Meteor.startup()

ROOT_URL_PATH_PREFIX is never set because of a code change 4 years ago.

So I will test this patch when I get a machine setup to build this project.

I don’t know if I would attempt this. Hosting Rocket.Chat in a subdirectory was deprecated about a month or two ago.

It seems ROOT_URL_PATH_PREFIX is setup when meteor parses ROOT_URL.

So I upgraded rocket chat from 3.0.4 to 3.2.2 and I’m pleased to say it now works properly when hosted on a sub directory. There was no need to add any special handling to nginx.