I run a few chat-servers that can clearly handle hundreds of clients each when non proxied. This works well but lacks security so I proxy to hide the IP.
Switching to proxied, everything works well but I don’t push the hundreds of clients yet. My chat-servers are on different sub-domains so wss1 - wss100.somesite.com. So with that said, how do the limits works?
Do the limits count against the entire domain (somesite.com and *.somesite.com) or does each domain/sub-domain get its own limits?
Beyond this how would quality differ going from FREE → Enterprise in time?
My Goals (future):
Open many sub-domains 10s to 100s that link my web-socket servers.
Keep high availability and less disconnection
Serve users no issue, if there’s a sudden rush of people I won’t be left looking silly cause I had the proxy servers on.
Serve more and more users but as stated not fall apart due to a third-party conflict
Not sure I asked any of that. I have already secured my servers and set them up correctly. There’s no issue with the usage of them proxied or un-proxied.
Question was of limitations and how they affect sub-domains hosting the sockets. Does a free-plan or better run the same in respects to quality as in would I experience less disconnects greatening my plan. (I know higher plan, more concurrent users but this was never explained if it was per sub-domain or the entire domain and its subs).
Seems it all comes down to just wait and see what happens, no problems yet but maybe someone with a business/enterprise plan could help me understand if there clients disconnect at all cause of resets/etc. Would be incentive to upgrade and not just use the LBs right now.
appreciate any information just cause my users get annoyed when CF is turned on, if a better plan would improve their networks they connect to (even PRO) I’ll take it.
The uncertainness after WebSockets is what made us discard using it as technology. We do not have actual “real-time,” but we mimick it reasonably well. I understand that not all projects can afford to do that, though.
There are other downsides; for example, CF acts as a transparent proxy after establishing a connection. So, if somebody goes through the initial requests and establishes a TCP connection, they are free to spam and abuse your WebSockets freely.
Granted that there are not many mitigations to this other than rate limiting connections based on numerous parameters, but I still found it a lack in the service (and in the industry in general, not many providers have this offering).
I guess it’s a matter of time until attackers realize that they have a “DDoS freeway” that nearly no provider out there can mitigate adequately.
Note, though, you still have the network-level protection of Cloudflare, so launching these attacks isn’t as easy as it might sound. I have not faced those attacks, but given that we have faced somewhat complex attacks in the past, we had to decide not to use WebSockets for now.
If you want some guarantee while using WebSockets, your best bet is to reach out to Cloudflare and ask for the enterprise package; I’m sure that the sales representative can sort out something for you.
Regarding this, the TL;DR is that Cloudflare has a fixed capacity on WebSockets; you are allowed to use as many resources as possible for as long as no other customer with more priority requires the resources.
100% understand software/app level attacks, the goal of a proxy is to keep and hide the listing of IPs to force users to BOT or utilize other measures that force them to have CPU on hand to do any damage and capabilities to spoof.
I’m just looking for quality if I proxy, otherwise I will throw up my own IPs, and mask off the real networks that way. Just for sockets though, I do appreciate the DNS routing CF has.