Have you read my post Tips to get 1.6.0 running after updating from 1.5.x ?
What you write is one of the problems I had. I solved adding two extra rules to nginx configuration.

Hi guys, here some tips for who experimented problems after 1.5.x -> 1.6.0 upgrade.

Symtoms client-side:

• .jst generated only after a page refresh
• .jst not generated at all
• "Uncaught SyntaxError: Unexpected token < " message in browser console.
• Various failures messages in browser console loading from /assets/... routes.
• General requirejs errors like "require.js:34 GET https://yourdomain.com/ net::ERR_ABORTED".
• JS modules loading errors like "tag_assistant_compiled.js:119 GET https://yourdomain.com/ 503 (Service Unavailable)".

After various attempts and settings, I've identified that problems comes from NGINX settings. Reading nginx logs, in particular the error.log file, I found a clue.

The settings suggested in documentation or here in the forum doesn't work for me, some modifications and adjustments are required.

The key change is the adding of this to rules:

 proxy_headers_hash_bucket_size  64;
 proxy_headers_hash_max_size  512;

and other little modification was the re-arrangement of configuration blocks that now looks like:

#
# HTTPS server
#

server {
	listen 80;

	root /path/to/NodeBB;
	index index.html index.htm;

	server_name    yourdomain.com;
	return         302 https://$server_name$request_uri;
}

server {
	listen 443 ssl spdy;
	server_name yourdomain.com;

	ssl_certificate /etc/nginx/ssl/cert_chain.crt;
	ssl_certificate_key /etc/nginx/ssl/server.key;

	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers 'AES128+EECDH:AES128+EDH';
	ssl_prefer_server_ciphers on;

	# This rules was moved here from location object 
	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 $scheme;
	proxy_set_header Host $http_host;
	proxy_set_header X-NginX-Proxy true;
	proxy_redirect off;

	# New fixes. Values are powers of 2, this works for me, you can increase.
	proxy_headers_hash_bucket_size  128;
	proxy_headers_hash_max_size  1024;

	# Socket.IO Support
	proxy_http_version 1.1;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection "upgrade";

	location @nodebb {
		proxy_pass http://127.0.0.1:4567;
	}

	location ~ ^/assets/(.*) {
		root /path/to/NodeBB/;
		try_files /build/public/$1 /public/$1 @nodebb;
	}

	location /plugins/ {
		root /path/to/NodeBB/build/public/;
		try_files $uri @nodebb;
	}

	location / {
                proxy_pass http://127.0.0.1:4567;
	}
}

Hopings this helps someone of you.

Pura Vida!

Mapping the Commons and fostering Civil Participation from Costa Rica to the world.

Look ÁgoraPIC webapp at https://agora.picapp.org

A NodeBB verticalization with full Civil Society GPS contextualization of political discussion and a WYSIWIG content editor.

Here some screenshots.

Hi guys, I'm writing this topic hoping this will help other user that like me encountered this frustrating issue when upgrading NodeBB.

First of all I have local development server, a Windows10 PC with NodeBB listening at http://192.168.1.100:4567, and a production server at Digital Ocean listening at a full qualified SSL domain at https://agora.picapp.org. (note that port is masked by Nginx server)

Well, for some reason, probably for my intervention, port number disappeared from url parameter, leaving only the IP in config.json looking like this:

{
    "url": "http://192.168.1.100",
    "port": 4567

So checking in various files in particular in line 123 of /src/controllers/index.js and in line of 97 of /src/start.js

//    /src/controllers/index.js 
.
var returnTo = (req.headers['x-return-to'] || '').replace(nconf.get('base_url'), '');
.

//    /src/start.js
.
nconf.set('base_url', urlObject.protocol + '//' + urlObject.host);
.

I discovered that trailing port is mandatory in url config parameter.

If you debug login.js you'll view that returnTo variable contains :4567/ value causing invalid csrf token server-side and forbidden client-side.

For me make sense to omit port value on url parameter line because the presence of a port parameter. But I was wrong.