Instant Reload 502 issue

Hello - there is another thread for the instant reload 502 issues here, but that thread is closed. The solution there does not work for me.

Thanks in advance for your support. Instant Reload is a massive help for my workflow, working without it feels slow motion.

OS: Ubuntu 24.04.

Similar to the other thread, I get the “Connection refused” error when enabling Instant Reload:

2024/10/18 00:42:04 [error] 11677#0: *1 connect() failed (111: Connection refused) while connecting to upstream, client: ::1, server: testing-instant-reload-issue.local, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "testing-instant-reload-issue.local"
2024/10/18 00:42:04 [error] 11677#0: *3 connect() failed (111: Connection refused) while connecting to upstream, client: ::1, server: testing-instant-reload-issue.local, request: "GET /favicon.ico HTTP/1.1", upstream: "http://127.0.0.1:3000/favicon.ico", host: "testing-instant-reload-issue.local", referrer: "http://testing-instant-reload-issue.local/"

At some point I also had this repeatedly in Local’s log, but it stopped appearing:

2024/10/18 00:08:25 [warn] 36515#0: the "listen ... http2" directive is deprecated, use the "http2" directive instead in /home/redacted/.config/Local/run/router/nginx/conf/server-block-ssl.conf:2

What I’ve tried:

  • Copying the site files, deleting, then importing does not fix the issue for me.
  • I have tested with a brand new site install, the 502 issue occurs there as well. Issue occurs on all existing sites I tested with.
  • I have tested with v9.1.0, v9.0.5, and v9.0.2 – same result with each version.
  • I have tested with nginx and apache.
  • Router mode seems buggy in general for me so no conclusive info for me there.
  • I have restarted my device.
  • Tried with SSL disabled and enabled.

Here are some testing scenarios:

  • Brand new site, no instant reload - the site loads.
  • Enable instant reload - doesn’t work.
  • Disable instant reload - still doesn’t work. Curiously, the Instant Reload label on the top right of Local remains green.
  • Close Local, reopen - the site loads (only works if Local was closed with Instant Reload set to off)

Some strange things that may or may not be clues:

  • This did not start happening for me immediately after an update. I was in the middle of making edits on a site (with Instant Reload working normally) when the 502 started suddenly. This part doesn’t make sense to me, I checked for any background system updates that could have caused something to knock loose and couldn’t find anything.
  • Under the Web Server dropdown, I see three options: nginx, nginx, and Apache (nginx appears twice). I’m not sure if this is new or has been that way for a while.

Hey @alvin

We do have an open bug for Instant Reload 502 errors below.

Our team is readying a patched release to be out soon that we will share and hopefully will resolve this.

@Nick-B Thanks. By chance would there happen to be a temporary workaround that you can suggest? Or an ETA for a permanent solution? My productivity has been impacted and I’m trying to determine if I should spend the time researching alternatives.

For now, @alvin, you should be able to use Instant Reload in Localhost Router Mode; the error seems to only appear when using Site Domains.

Preferences>Advanced>Router Mode will take you to where you can make that change.

If you have to use Site Domains mode you can remove these options from the NGINX config manually which should resolve the issue.

proxy_set_header Connection '';
proxy_http_version 1.1;

@Nick-B Thanks! I’ve got it working on Router Mode. When I tried earlier, I hadn’t realized that I needed to fix site URLs in order to get Router Mode to work.

I’d still like to try with Site Domains if possible, but I couldn’t locate where which nginx conf file contains proxy_set_header and proxy_http_version. I’m on Ubuntu 24.04 if that matters. I looked in local-specific places like /Local/run/router/nginx/conf/nginx.conf as well as site-specific places like /local/site-name/conf/nginx/nginx.conf.hbs but didn’t see it anywhere.

Let me check if that is different for your OS or not. As another option, you should be able to downgrade to the last release where this was working for you as well.

Those locations are good places to look, but if you are wanting to remove the lines from the router config, you’ll need to remove them from within the Local app.

Note that your changes will be overwritten when Local updates, but you should be able to look in this place on a debian system:

/opt/Local/resources/extraResources/router-config/nginx.conf

@Nick-B Perfect. Apparently I needed to rollback to 8.3.2, 9.0.2 wasn’t far back enough. I now have Instant Reload working again with site domains.

@ben.turner Even though I have a temporary workaround in place, I wanted to point out to you that I don’t have those lines in /opt/Local/resources/extraResources/router-config/nginx.conf. Seems to be unchanged after downgrade. Mentioning this in case it’s useful to you in producing a longer term solution.

error_log logs/error.log warn;

events {
	worker_connections  1024;
	multi_accept        on;
}

daemon off;

http {
    include         mime.types;
    default_type    application/octet-stream;

	server_names_hash_bucket_size 128;

	client_max_body_size 1000M;

    proxy_buffer_size         128k;
    proxy_buffers             4 256k;
    proxy_busy_buffers_size   256k;

	access_log         off;
	sendfile           off;
	tcp_nopush         on;
    tcp_nodelay        on;

    keepalive_timeout  3;

	map $http_x_forwarded_proto $protocol {
         default $scheme;
         https https;
    }

    server {
        listen 80 default_server;
        listen [::]:80 default_server;

		include includes/errors.conf;

        server_name _;

        try_files /router-error-404.html =404;
    }

    include route.*.conf;
}

You’re right, those lines are only present in the latest version of Local, which is why Instant Reload is broken in that release.

@ben.turner @Nick-B Thanks for your continued support on this.

I’m sharing this both with hopes of a new quick fix, and for your general awareness.

Instant Reload was working for me on 8.3.2 with Site Domains earlier today.

After restarting my device, it now doesn’t work again. It also stopped working on Router mode.

I tried upgrading to 9.0.5, no luck.

Back down to 8.3.2 which worked earlier today, no luck.

Up to 9.1.0 and I did see proxy_set_header and proxy_http_version in nginx.conf. I deleted those lines, no luck.

I tried with a downgrade I hadn’t previously tried, 8.3.1, no luck.

Now when I try to use Instant Reload on a downgraded version, I get this strange behaviour:

  • Instant reload is off, Site Host is localhost:11223. Site loads.
  • Instant reload is turned on, Site Host changes to localhost:3000. Site doesn’t load at that port (err_connection_refused), but still does at :11223. Instant reload not working though.
  • Sometimes Instant Reload icon stays at green even when turned off. Sometimes it stays at grey even when turned on.

Things seem funky all around for me now. I didn’t make any modifications other than deleting those two lines on nginx.conf, which has been overwritten anyway after my last downgrade. All I’ve been doing is upgrading/downgrading and toggling Instant Reload and router/domain mode.

You mentioned that your understanding is that Instant Reload is only not working on the latest version, but that doesn’t seem consistent with what I’m seeing here. It’s affecting me no matter what version is installed.

@ben.turner @Nick-B

Might you have any other ideas for a temporary solution? I continue to be unable to use Instant Reload across all versions, and across multiple devices.

I don’t have any ideas at the moment. Maybe there’s some more information about what’s going on within the Local log? You can get a zip of those logs by clicking the “Download Local Log” button from the “Support” tab of Local. See this help doc for more information:

1 Like

@ben.turner

Last night I enabled a site that hadn’t been worked on for a some months, and Instant Reload actually was functioning perfectly there for the few hours I was working on it.

The device (Ubuntu 24.04) was left on overnight, and when starting to work again today, Instant Reload was no longer functioning and I got the 502 again. Nothing had changed on the device between it working last night and it not working today - it was untouched. I’m not sure what this means but it would seem to me that it could have some relevance.

The error messages that were logged in ~/.config/Local/run/router/nginx/logs/error.log around the time it stopped working today are below:

2024/11/03 12:14:46 [error] 577719#0: *93622 upstream prematurely closed connection while reading response header from upstream, client: ::1, server: test.local, request: "GET /browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1PYY&sid=CYKgt92928bVIC3oAABM HTTP/1.1", upstream: "http://127.0.0.1:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1PYY&sid=CYKgt92928bVIC3oAABM", host: "test.local", referrer: "http://test.local/test-page-1/"
2024/11/03 12:14:46 [error] 577719#0: *93627 upstream prematurely closed connection while reading response header from upstream, client: ::1, server: test.local, request: "GET /browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1PQ8&sid=QksTx44LxK49kBkKAABJ HTTP/1.1", upstream: "http://127.0.0.1:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1PQ8&sid=QksTx44LxK49kBkKAABJ", host: "test.local", referrer: "http://test.local/test-page-2/"
2024/11/03 12:14:46 [error] 577719#0: *93627 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: ::1, server: test.local, request: "POST /browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1QMJ&sid=CYKgt92928bVIC3oAABM HTTP/1.1", upstream: "http://127.0.0.1:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1QMJ&sid=CYKgt92928bVIC3oAABM", host: "test.local", referrer: "http://test.local/test-page-1/"
2024/11/03 12:14:46 [error] 577719#0: *93622 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: ::1, server: test.local, request: "POST /browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1QMK&sid=QksTx44LxK49kBkKAABJ HTTP/1.1", upstream: "http://127.0.0.1:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1QMK&sid=QksTx44LxK49kBkKAABJ", host: "test.local", referrer: "http://test.local/test-page-2/"
2024/11/03 12:14:47 [error] 577719#0: *93622 connect() failed (111: Connection refused) while connecting to upstream, client: ::1, server: test.local, request: "GET /browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1Qe8 HTTP/1.1", upstream: "http://127.0.0.1:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=PBp1Qe8", host: "test.local", referrer: "http://test.local/test-page-2/"

In ~/.config/Local/local-lightning.log, there were no logged messages around the same time as what’s pasted above. A bit later I did try reinstalling and noticed this:

{"code":"ERR_IPC_CHANNEL_CLOSED","level":"error","message":"Channel closed","stack":"Error [ERR_IPC_CHANNEL_CLOSED]: Channel closed\n    at new NodeError (node:internal/errors:399:5)\n    at target.send (node:internal/child_process:740:16)\n    at Object.processMessageHelper (%%appPath%%/main/_helpers/childProcessMessagePromiseFactory.js:1:122)\n    at e.default.<anonymous> (%%userDataPath%%/addons/@getflywheel-local-addon-instant-reload/lib/main.js:1:3878)\n    at Generator.next (<anonymous>)\n    at %%userDataPath%%/addons/@getflywheel-local-addon-instant-reload/lib/main.js:1:2924\n    at new Promise (<anonymous>)\n    at a (%%userDataPath%%/addons/@getflywheel-local-addon-instant-reload/lib/main.js:1:2669)\n    at e.default.stopConnection (%%userDataPath%%/addons/@getflywheel-local-addon-instant-reload/lib/main.js:1:3750)\n    at e.default.<anonymous> (%%userDataPath%%/addons/@getflywheel-local-addon-instant-reload/lib/main.js:1:1518)","thread":"main","timestamp":"2024-11-03T17:51:41.054Z"}

The first occurrence of ERR_IPC_CHANNEL_CLOSED in this log is Oct 18, which corresponds to the day I started this thread.

Please let me know if this provides you any clues or new ideas of what can be attempted.