Hiya, just got NPM installed and working, very happy to finally have SSL certs on all of my serivces and proper URLs to navigate to them, what a breeze! However, as I am still in the learning process: I am curious to know when to enable these three toggles and for what services. I assume the “Block Common Exploits”, can always be turned on. But unsure about the two others. Some applications have not worked until I turned on the Websockets Support, but I dont really know what it does, nor do I know what applications need this in order to fully work. Are there any thumb rules for these things?
Appriciate any pointers! 🌻
You must log in or register to comment.
That’s not NPM, that’s Nginx proxy manager. They are very much not the same thing.
I’ve seen others calm this npm, so went along and did the same 🙃
It’s even abbreviated that way in the official documentation: https://nginxproxymanager.com/advanced-config/
Two wrongs don’t make a right. I was scratching my head for a few seconds looking at the thumbnail and the title. And even the post body didn’t clarify things. 🤷🏻
Multiple things have the same abbreviation, it’s really all about the context it’s used it imo. Considering Ngninx Proxy Manager being a very well known tool in the selfhosters toolbelt, I figured it would be familiar enough to use.
You also have a screenshot from proxy manager so any confusion should have been short lived
Is it wrong to abbreviate your own product in your documentation?
Their own doc, sure why not.
Any other context where there’s a giant with the same name. No, please at least write it out expanded once.
I don’t use nginx proxy manager but websocket has to be enabled for apps that use websockets (duh) - you would have to dive into docs or example infra configs to check if the service uses it.
Rule of thumb here would be to enable it for everything. Optionally you could check if the service works with/without it.E: Websockets are used when a website needs to talk in “real-time” with the servers - live views and graphs will usually use it also notifications, generally if the website does not reload/redraw fully but data seems to change then there is a high chance it uses websockets under the hood (but there are ways to do it without ws, ex. SSE).
Example: Grafana uses websockets but qbittorrent web ui uses other means (SSE) and does not require ws.
I see, thanks for the clarification!
Since others have answered this already I just wanted to take a moment to appreciate someone posting about npm. It works so great and helps make selfhosting quite easy. Have a good one.
Well thank you! And 2Y2 🌻
Probably not best practice, but I automatically check Block Common Exploits and Web Sockets every time because I’m lazy. Works every time.
Not sure what Cache Asset does, but I can guess from the name. I leave this one off because my NPM runs on a VM with not much storage
I don’t use NPM but if “Cache Assets” means what it means in the traditional sense, it wouldn’t affect most home deployments.
Historically, resources are limited and getting Apache to load images/javascript/CSS files from disk each time they’re requested, even if the OS kernel eventually caches them to RAM, was a resources intensive process. Reverse proxies stepped up and identifies assets (images, JS and CSS), and stores them in memory for subsequent requests. This reduces the load on the Apache web server and reduces the hops required to serve the request. Thereby making everything faster.
For homelabs, and single user systems, this is essentially irrelevant, as you’re not going to be putting so much load on the back end system to notice the difference. May be good to still turn it on, but if you’re noticing odd behaviors (ie updates to CSS or images not taking), it may be a good idea to turn it off to see if that’s the culprit.
As others said, “Websocket Support” enables support for them and is required for some applications. “Cache Assets” caches (likely static) assets in the proxy so they don’t have to be loaded from the backend service - I’d leave this disabled unless the backend service is hosted on another network entirely, and even then only enable it if you know the implications. “Block Common Exploits” is a very primitive filter against SQL injection (and similar) attacks. It also blocks some user agents. I wouldn’t enable it as it won’t do much to block a dedicated attacker and some filters may falsely trigger in edge cases, causing errors.
Thanks for this, I guess it would matter much for me to have the BCE on or not, as my services are only hosted over my own VPN and not exposed at all.
Then yeah, that option is worthless to you. For me, having networked solutions over a domain I have that enabled. But if its just internally I’d also disable it
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters HTTP Hypertext Transfer Protocol, the Web VPN Virtual Private Network nginx Popular HTTP server
2 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.
[Thread #667 for this sub, first seen 9th Apr 2024, 13:15] [FAQ] [Full list] [Contact] [Source code]
I usually just turn on WebSocket support and turn off Block Common Exploits and Cache Assets for everything.
