TiddlyWiki on nginx works Here but not Out There

1

This is my first run on TiddlyWiki/nginx/Node.js. Hints on where to read would be great.

In my in-house machine, it’s working well. Mostly I followed this page:

Setting Up Tiddlywiki Behind Nginx · Brool

At home, I’ve had no issues.

Remotely though:

First, as a test, I ran it in http, not https. In that state, it works. There’s a long pause on the initial connection. My guess is the VM hosting service doing something to stop bad things. Very good. Carrying on.

When I switch to the https state, connections are immediate and fail.

The nginx session is running fine. Connections to its root are successful. Connection to a deliberate 404 fail appropriately.

When I try to connect to the wiki I get a 502, “Bad Gateway”.

On the server’s error log we see, one line:

2022/02/07 19:17:01 [error] 4508#0: *11 connect() failed (111: Connection refused) while connecting to upstream, client: 207.98.188.118, server: [web servers’s name], request: “GET /dm/ HTTP/1.1”, upstream: “http://127.0.0.1:8087/”, host: “[web server’s name]”

I’m guessing this is something obvious…?

Thanks.

2

I should have included the line from my nginx setup:

[…]
server {
listen 443 ssl;

            server_name [my.web.server];
            ssl_certificate /etc/ssl/nginx/bundle.crt;
            ssl_certificate_key /etc/ssl/nginx/nginx.key;

            access_log /var/log/nginx/multinational.ssl_access_log main;
            error_log /var/log/nginx/multinational.ssl_error_log info;

            root /var/www/localhost/htdocs/;

            location /dm/ {
                    proxy_pass http://127.0.0.1:8087/;
                    proxy_set_header        Host    $host;
                    proxy_set_header        X-Real-IP       $remote_addr;
                    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

            }

[…]

Thanks.

3

Did you only change the nginx configuration to not use TLS and that is all that changed between the working and not working state?

Good tests…that’s useful information.

“Connection refused” indicates there nothing listening at ip address 127.0.0.1 on TCP port 8087. That could happen if your nodejs is not running anymore. Is your nodejs still running? It could also happen if it is running, but listening on a different port or not listening at the 127.0.0.1 ip address.

If you have terminal/shell access to the box, you can run (I’m assuming unix/linux) netstat -nlt to display which TCP ports are listening.

If it isn’t something simple like your nodejs process not running anymore, then I recommend changing back to plain HTTP to see that it still works and then purposefully stop the nodejs process and try again. Expect to see the same “connection refused” message you get with https. If not the same message, then maybe it will give some clue.

4

No: monit isn’t running, and sure enough, when I now look at the home-based system… Looks like I lied when I said HTTPS on TiddlyWiki is fine here. I’ll spare us the details.

This is my first use of monit, and it hasn’t appeared in the doc I linked to. It is installed in both places; thanks for cluing me in that it needs to be running, not just present in the host.

I’ll go read. Further clues would be welcome but, I hope, won’t be necessary.

Much thanks.

5

…oh crikey. Also wow. This is a fourteen-pound hammer for a tissue issue.