Recently, I am getting the following message on chrome console;
WebSocket connection to 'ws://evo15:4008/?stream' failed: Unknown reason
It's getting more and more and it's somehow annoying and I have to open a new tab or restart chrome every time to get back to normal websocket connection. How can I debug it? Unfortunately, I cannot reproduce it yet. My chrome version is Version 77.0.3865.75 (Official Build) (64-bit)
Update 1: I think you could reproduce it by closing the connection for a long time (I don't know the exact time) from server side and then open it and try to connect to it (client trys to connect every 1 sec). Then it will happen. So I guess there is an expire time or a limited number of tries to connect somewhere.
Update 2: It happens after 256 tries of reconnection.
WebSocket connection to 'ws://evo15:4008/?stream' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
After seeing 255 of this error on console, you will see the first error and cannot reconnect. So I think there is a 8 bit limit somewhere that I am missing
Looks like someone just filed this as a Chromium (v77) bug. See issue tracking it here.
Update 1: As noted in the issue tracker and comments below, this should now be fixed in the latest stable release, which is being rolled out now (2019/10/11).
Update 2: Despite the bug being marked as fixed/closed in monorail, canary (80.0.3977.4) still appears to have this behavior. As others have noted there is a global limit of 255. However, the fact that connections opened by JS don't get closed/reset when the page is refreshed still seems like a bug to me.
For some very very very odd reason in my computer the websocket connection was considered as an ad by AdBlock.
Try to disable AdBlock and see if it works.
Related
I'm running a Server-sent Event (SSE) server over Ingress/Kubernetes/GoogleCloud and it works like a charm. I can run SSE clients over the web and they connect perfectly, start receiving events with no problem.
But there's one ugly bug I can't get it work right, on Chrome browsers after some time I get net::ERR_NETWORK_CHANGED error. No matter how many times I run it, I always get it after a few seconds/minutes.
If I run the same client over Firefox, nothing wrongs happens. If I run it using cURL over terminal, nothing wrong happens.
If I decide to run if over Chrome without HTTPS, it works! I'm only getting it when running it through HTTPS and on a Chrome browser.
Has anyone encountered this before? Seems like a ugly bug for me.
I'm having the same problem but it's sporadic.
From the Chromium project source code: OnNetworkChanged will be called when a change occurs to the host computer's hardware or software that affects the route network packets take to any network server. Some examples:
A network connection becoming available or going away. For example
plugging or unplugging an Ethernet cable, WiFi or cellular modem
connecting or disconnecting from a network, or a VPN tunnel being
established or taken down.
An active network connection's IP address changes.
A change to the local IP routing tables.
Hope it helps
For me using a mac system and chrome for a daily basis, I encounter this problem now and then and finally found it might be helpful to solve this problem by just turning off the virtual machines or dock containers whichever can adjust your network configuration.
Maybe not fit for your case but it could be a hint. I saw a lot of people having this kind of issue with chrome.
I recently deployed a node.js based site into load balanced servers(windows).
(Not sure if Node.js or load balancer matters in the case, but want to share the information)
When I hit the url in Chrome, I sometimes get ERR_Connection_Reset error:
For example: mysite.com/bower_components/jquery/dist/jquery.js net::ERR_CONNECTION_RESET
But if I try to hit mysite.com/bower_components/jquery/dist/jquery.js in browser, it works. Which means the path doesn't have problem.
When I hit the url in IE, I sometimes get XMLHttpRequest: Network Error 0x2eff, Could not complete the operation due to error 00002eff.
I've been scratching my head for days, any help will be appreciated!
What version of node are you using? This patch fixed a problem with idle sockets throwing ECONNRESET errors and it shipped in 4.4.0 and 5.4.0, upgrading fixed the issues for me.
I have a Chrome Extension, Requestly which allows you manipulate HTTP Requests. 3-4 Users have faced an issue where Searching in Omnibox is Crashing the Google Search Results Page while rest of the pages work fine.
Please have a look at this Gif for more understanding.
Issue seems to be resolved by couple of ways:
Export Rules, Delete Rules, Restart Browser, Import Rules
Simply Restart Browser
Clearing Cache
This issue is reproducible on Ubuntu 14, Windows 8.1 Chrome 42. I have Ubuntu 12.10 Chrome 42 and I never saw this issue.
Here is the background.js code on Github. I am just wondering the cause of issue. I have used the following in my code
chrome.storage.sync
chrome.webRequest.onBeforeRequest (Blocking Option)
chrome.webRequest.onBeforeSendHeaders (Blocking Option)
I have observed another Chrome Extension, Scritsafe is facing the same issue. Details mentioned in this thread but the users are still not able to completely get rid of this bug.
One of the kind and helpful user gave me this information by enable logging while launching Chrome but I am not sure if these logs are helpful. These are the logs:
[13753:13788:0515/203052:WARNING:spdy_session.cc(2373)] Received HEADERS for invalid stream 7
[13753:13788:0515/203052:WARNING:spdy_session.cc(2373)] Received HEADERS for invalid stream 11
[133,3746404608:17:30:52.858104] Native Client module will be loaded at base address 0x0000702d00000000
[13753:13788:0515/203058:WARNING:spdy_session.cc(2373)] Received HEADERS for invalid stream 17
[13753:13788:0515/203210:WARNING:spdy_session.cc(2373)] Received HEADERS for invalid stream 55
[13791:13791:0515/173212:WARNING:ipc_message_attachment_set.cc(37)] MessageAttachmentSet destroyed with unconsumed descriptors: 0/1
Main problem is I am not able to manifest this on my machine. If I am able to manifest this, I would certainly try some random things and figure this out.
I have done enough Google Research. Now How should I approach to fix this issue ?
Edit:
Clone of this question is also available in Google Chrome Extension Forum. Simon Knott has also faced the same problem/bug.
He mentioned to avoid blocking all requests (Avoid especially XHR).
I've installed the Yosemite preview and WebSockets don't work for me on Safari 8.
The echo test page works on Chrome (with the secure checkbox set) but when I try with Safari it fails silently.
I debugged the page and what happens is that the WebSocket is created but its onopen event is not fired and the socket's readyState status remains stuck on CONNECTING (0).
I couldn't find any references to this problem, is there any configuration I may have missed that causes/fixes this?
Safari has updated (to version 8.0.10600.1.22) and the problem is now resolved.
I have a weird error that I can not solve.
My implementation WebSocket works perfectly. The browser connects to the server, exchange their keys and the connection is fully established! The server starts sending messages to clients (visible in the network traffic).
But on my PC, all browsers (Chrome, Firefox, portable or not), the "onMessage ()" is correctly interpreted ... but only at the end when I turn off the server! In other words, if I put an alert () to each onMessage (), during exchange, I did absolutely nothing. But once I cut the server, I receive all alerts at once!
Yet on my MacBook everything works perfectly.
This ironic is it that behavior that affects all of my browsers on my PC. I run under Windows 7.
Thank you in advance ;)
I've finally found the issue !
If you have some troubles with Websockets, just disable the SSDP discover service on Windows.
net stop SSDPSRV
I ran into a similar issue recently. web server runs a separate SSDP discovery process to find uPnP devices on the network. When I had SSDP enabled, my websocket connection was always closed. Disabling SSDP solved it. But I haven't had a chance to investigate why.