Just because the destination IP address is not a LAN address? That’s not misconfiguration, that’s a legitimate use of NAT reflection/loopback. If that’s how it determines who is streaming remotely then just run it behind nginx that forgets to set the correct headers.

Edit: Apparently Plex centrally relays all the traffic? Self-hosted my 🍑, it’s not self-hosted if you need to rely on their server.

I never had any issues with npm. Moved to bun nowadays and still going strong. If I want to install something, I install it, and then it works.

Setting up anything with pip however…

Been there done that. Closed as duplicate.

Glad to still have you here with us.

Thread closed because that’s a stupid question and you should feel bad about yourself.

I only believe in Bun.

I get a bit frustrated at it trying to replicate everyone else’s code in my code base. Once my project became large enough, I felt it necessary to implement my own error handling instead of go’s standard, which was not sufficient for me anymore. Copilot will respect that for a while, until I switch to a different file. At that point it will try to force standard go errors everywhere.

Perhaps 5 LOC. Maybe 3. And even then I’ll analyze every single character in wrote. And then I will in fact find bugs. Most often it hallucinates some functions that would be fantastic to use - if they existed.

Not funny because you’re afraid the AI will take your job away right? Right?

Why did my Internet stop working? I DoSed OP’s IP address.

I explained why. Misconfiguration and caching.

You would also need to clear your device’s DNS cache.

Not two A records. From what I understand, OP has an A record pointing to their public IP address (which Nginx is listening on behind a NAT). Then, on the local network, OP uses their own DNS server to ignore that entry and instead always serve the local IP when a host on the LAN queries it.

Aside from OP’s devices potentially using a different DNS server (I was only able to solve it for my stock Android by dropping outgoing DNS in my firewall), this solution is a nightmare for roaming devices like mobile phones. Such a device might cache the DNS answer while on LAN or WAN respectively and then try to continue using that address when the device moves to the other network segment.

These are the most likely scenarios in my opinion - OP’s devices are ignoring the hacky DNS rewrite (either due to using a different DNS server or due to caching) and try to access the server via the public IP. This is supported by the connection timeout, which is exactly what you would see when your gateway doesn’t do loopback.

Never point your DNS at two different IP addresses like this. It will only cause you pain and unexpected behaviour.

What you are experiencing is solved by so-called “NAT reflection” or “NAT loopback”. It’s a setting that - in the optimal case - you should just be able to activate on the appropriate interface on your gateway.

If you do not have that setting or do not have access to the edge router, but only some intermediate router, you can do a nasty hack. You can point static routes to your public IP address to point at your local IP address instead. In that case, you also need to tell your server to accept packets with your public IP address as the destination.

Same here. I did not think twice about this picture or a few other posts in the past and yet there are pitchforks in the comments and I think to myself “What are you all on about?”. I rue how unrecognizable AI “slop” has gotten.

It just means they are lazy and have no respect for other people’s intellectual property.

It’s not open source by choice. In fact, they tried breaching the license to keep it closed source.

I pay for the whole VPS, I use the whole VPS.

Great details! I know the difference personally, but this is a really nice explanation for other readers.

About the last point though: I’m not sure Go always uses the maximum amount of kernel threads it is allowed to use. I read it spawns one on blocking syscalls, but I can’t confirm that. I could imagine it would make sense for it to spawn them lazily and then keep around to lessen the overhead of creating it in case it’s needed later again, but that is speculation.

Edit: I dove a bit deeper. It seems that nowadays it spawns as many kernel threads as CPU cores available plus additional ones for blocking syscalls. https://go.dev/doc/go1.5 https://docs.google.com/document/u/0/d/1At2Ls5_fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/mobilebasic

Well, they’re userspace threads. That’s still concurrency just like kernel threads.

Also, it still uses kernel threads, just not for every single goroutine.