Hello. I have some HTTP and WebSocket APIs. I realized a few days ago that my APIs that have the cloudflare proxy active respond with the status 101 normally (websocket), so far ok, a sign that I managed to briefly open the communication with the socket, but soon after I received the status 400 bad request and the connection is closed. I disabled the proxy and the api works normally again. What would that be? The error is apparently coming from cloudflare
3 Likes
For me this started at august 24, i started to get “HTTP 400 bad request” for some requests, at august 25 all my requests get “HTTP 400 bad request”. Cloudflare team please explain what happened and how do i fix it because disabling proxy is not a solution for my use case
1 Like
a lot, very lot people in https://radar.cloudflare.com/traffic/tm use websockets and you can see a huge traffic reduction after this change
We are in the same situation. I just confirmed that my web sockets started to work again when the proxy was disabled.
it seems that cloudflare made changes and now only standard http methods like GET work (i used nonexistent methods and it worked before aug 25) and now you need to provide connection, upgrade and Sec-WebSocket headers on client and server side. This is very unfortunate for me because GET and other http methods are banned in my country by the DPI system, i can’t connect to cloudflare now
ANSWER: Cloudflare intentionally removed the proxy support for web socket on their free plan. They now want you to purchase their Pro plan which costs $25 monthly. If you purchase it, then the 400 bad request error when the proxy is enabled will stop showing, though it’s currently unstable as of the time this was written.
It’s unfortunate that the support team kept quiet and let their users complain, instead of letting us know this is a new development. Seems they’re scared of backlash if they come out clean by letting everyone know their service is no longer free.
Well, they’ve tried for several years to give everyone free access to their service. So this development, though sudden with no prior announcement, is welcomed.
There’s been issues in the past few days with Cloudflare returning wrong status codes:
400x isn’t specifically included, but I wouldn’t be surprised if it was related.
I have a free site behind using Websockets with no issues.
If it’s still unstable even after paying, it’s probably related to the issue above.
What is your source for that information as well?
You may be right or wrong with the error being related, however, I purchased the Cloudflare Pro plan and noticed the 400 bad request error that occurs immediately after a connection is requested previously on the free plan has now been reduced by a lot.
On the Pro plan, I’m currently on, it connects immediately, while as in the case of (being unstable) I mentioned, it may require you to try more than once, at most twice to get connected. The chance of the unstable connection occurring is about 40% of 100%.
Not sure if this will reduce on the Cloudflare Business Plan, but that’s a no-go area for me.
1 Like
@wisdome400 please provide source. Websocket still works on my free plan with proxy enabled and its stable
If you’d like to see partially broken websockets install meshcentral, it’s free.
It has an admin login to dashboard websocket, and an agent running on a pc websocket.
I think we’ve narrowed it down to the agent side of the connection being the problem…so it must be certain kinds of websocket connections that are the problem. You can see the issue and where we’ve gotten to here:
I’ve answered your question already. I should be asking you for the source of your claim that it works. Many are facing this issue, and they purchased a Pro plan which fixed the issue. I’ve spoken from experience, how about you? What is your source? You’re the only one defending what is obvious here.
is it still partially broken or completely broken now? please check by yourself because here https://github.com/Ylianst/MeshCentral/issues/5302#issuecomment-1694491182 it doesn’t connect at all in this post (aug 25, the same day it completely broke for me) and i suspect meshcentral doesn’t follow websocket rfc https://www.rfc-editor.org/rfc/rfc6455#section-1.2
my own websocket works fine after i adjusted my client and server (400 Bad Request when cloudflare proxy enabled - #7 by its.oka)
This is a possibility, which we’re trying to track down. Our implementation has two websocket clients interconnecting with a server.
(mesh agent) <websocket1> (Mesh server) <websocket2> (Mesh admin login to web page)
Based on traffic we’re pretty sure the websocket2 connection is working.
It’s the websocket1 connection that connects then immediately disconnects.
What we do know is:
- It was working fine before.
- No changes on mesh codebase
- Started not working 1-3 weeks ago.
- So we know CF changed something in relation to handling websocket traffic.
What changed at CF, would be nice to know to help us find the problem with the mesh agent connection.
1 Like
Hi,
I also facing websocket issue with cloudflare pass 3 weeks. Before that it work perfectly. To overcome my websocket issue i have to upgrade the plan from free to Pro version, but the connection still on and off. 10 out of 4 customers connect successful. This really affect my business, so we upgrade to another level which is business plan. But the issue still same. So we have no choice to by-pass the cloudflare now. Now waiting the contract finish then we will stop cloudflare service. May i know what adjustment u do for your client and server to make the websocket work?
2 Likes
Did anyone get a resolution? We have the business plan and are experiencing similar issues but no response from cloudflare yet. We have had previous issues where they have had to disable “features” at the edge locations related to web sockets. One of the comments above about the software being rfc compliant I think is the key factor as we also think one of ours that is broken isnt fully compliant.
Aren’t you supposed to get an answer after 24hrs on their business plan ?
Certainly didnt. The vendor fixed the product to be websocket rfc compliant. Then it was resolved. So guess is cloudflare just started to enforce rfc compliance. Applications that are non compliant having traffic dropped. Didnt apply to all edge locations we noticed.
I have exactly same problem like you. Before, my Websocket API worked normally, but a month ago, it’s unstable. I have origin server connected through proxy cloudflare with free plan. I have checked log in origin server, it seems to work normally with http code 101 but my app can connect to origin server. I have free plan, 2/10 request successful, I try upgrade to Pro plan, but unstable, it only improved a little, about 6/10 request successful
That affected our plan business a lot.
@vmg.ita if its your own code i’d check its compliant but if a 3rd party try to use a packet capture tool with ssl decryption. For example if the upgrade in the handshake is standard thats probably ok. But check its GET requests with a full hostname for example being sent. I noticed post handshake if its anything other than a GET or the host is missing you will start to get failures.
We developed server and client ourselves. We have run it and server have no update for many year, but have problems about a month ago. We use free plan, almost request fail. Then we try to upgrade to Pro plan. It has improved a bit but we try connect by our client app, sometime ok, sometime not ok alternately.