react-scripts 3.3.0 - "The development server has disconnected. Refresh the page if necessary"

[elisciandrello]

So in development, just a standard create-react-app template, and I start receiving this console error right away.

I went through previous issues of this sort, followed all instructions but no matter what still ran into this error.

The only way I was able to prevent it from happening was downgrading to react-scripts-3.2.0

[noelstieglitz]

Did you also see an error related to websockets in the console? This could be related to #8075 . The fix is merged (#8079) and will be released with 3.3.1. If you don't want to downgrade to 3.2.0, you can hack up line 62 from:

protocol: 'ws', to protocol: window.location.protocol === 'https:' ? 'wss' : 'ws',

in the following file: node_modules/react-dev-utils/webpackHotDevClient.js

[websash]

Unfortunately window.location.protocol === 'https:' ? 'wss' : 'ws' doesn't help. I'm running it on http://localhost anyway in docker with node_modules mounted as named volume with nginx as reversed proxy. It disconnects after about 1 min. react-scripts-3.2.0 works properly with my setup though

[uncaught]

Same for me, nginx reverse proxy for ssl, I have the window.location.protocol === 'https:' ? 'wss' : 'ws' line hacked in because I need https for development. But after about a minute idle, it disconnects. with this The development server has disconnected. Refresh the page if necessary. message.

My nginx config:

server {
  listen        80;
  server_name   xxx;
  return 301 https://$host$request_uri;
}

server {
  listen        443;
  server_name   xxx;

  location / {
    proxy_pass  http://192.168.42.211:3333;
  }

  location /api {
    proxy_pass  http://192.168.42.211:3030;
  }

  add_header Strict-Transport-Security    "max-age=31536000; includeSubDomains" always;
  add_header X-Frame-Options              SAMEORIGIN;
  add_header X-Content-Type-Options       nosniff;
  add_header X-XSS-Protection             "1; mode=block";

  proxy_set_header X-Real-IP           $remote_addr;
  proxy_set_header X-Forwarded-For     $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto   $scheme;
  proxy_set_header Host                $host;
  proxy_set_header X-Forwarded-Host    $host;
  proxy_set_header X-Forwarded-Port    $server_port;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

  ssl on;
  ssl_certificate             /etc/ssl/private/fullchain1.pem;
  ssl_certificate_key         /etc/ssl/private/privkey1.pem;
}

[nazar]

After some digging I found that this is related to nginx's default proxy_read_timeout 60s rule. It seems that prior react-scripts versions would reload the websocket connection when it timed out after 60s.

Adding the following two rules to my location /sockjs-node fixed the disconnects for me when using an nginx reverse proxy - incidentally, CRA's built-in proxy does not have this disconnect issue.

    location /sockjs-node {
      proxy_pass http://client-web:3000;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;

      # the following two timeout rules fix CRA WDS disconnects after 60s
      proxy_read_timeout 86400s;
      proxy_send_timeout 86400s;
    }

HTH

[elisciandrello]

Did you also see an error related to websockets in the console? This could be related to #8075 . The fix is merged (#8079) and will be released with 3.3.1. If you don't want to downgrade to 3.2.0, you can hack up line 62 from:

protocol: 'ws', to protocol: window.location.protocol === 'https:' ? 'wss' : 'ws',

in the following file: node_modules/react-dev-utils/webpackHotDevClient.js

I did attempt this and it actually still didn't work. The only way was downgrading my react-scripts still.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[bklynate]

I am still experiencing this issue, I've also ejected... not sure if anyone else is experiencing post eject..

[michaeljota]

I can confirm this is still happening even in 3.3.1. Same as the comments above, I'm using a docker image to run the app in a reverse proxy with https enabled.

[omerfaran]

Hello It's happening for me as well

[omerfaran]

I looked at my package.json and it seems like my react-scripts version is 1.1.15, does it make sense? It's very old:

{
  "name": "ecommerce-react-graphql-stripe",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "axios": "^0.18.0",
    "gestalt": "^0.79.1",
    "react": "^16.4.2",
    "react-bootstrap": "^0.32.4",
    "react-datepicker": "^2.7.0",
    "react-dom": "^16.4.2",
    "react-redux": "^6.0.0",
    "react-router-dom": "^4.3.1",
    "react-scripts": "1.1.5",
    "react-spinners": "^0.4.5",
    "react-stripe-elements": "^2.0.1",
    "redux": "^4.0.1",
    "resize-base64": "^1.0.12",
    "strapi-email-sendgrid": "^3.0.0-alpha.14.5",
    "strapi-sdk-javascript": "^0.2.1"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  }
}

Should I upgrade to 3.2.0 then? Thanks in advance

[linhnn]

Confirm that setting proxy_send_timeout will solve the problem.

[ArnaudBarre]

Is there a simple way to set it via a patch in react-dev-utils ?

[omerfaran]

Hey guys,

In case I'm not even using nginx could it be just related to using an old version of react-scripts?

From the answers here it seems that react-scripts 3.3.0 causes this, so I cannot understand the source of my problem.

The react web app is live, and a small percentage of users experience this disconnection problem.

Thanks in advance

[michaeljota]

The react web app is live, and a small percentage of users experience this disconnection problem.

Are you serving the application live in production with "react-scripts start"? That's a development script and should not be used for production. Try to update react-script in package.json or follow a guide like https://create-react-app.dev/docs/updating-to-new-releases.

In any case, you should stop serving your application with this. Run a build and upload it to your server.

[omerfaran]

Hello michaeljota thank you, yes, it's in production and I'm still serving it with "npm start". The reason is that I still implement changes and it's easier to update files without re-building the project. You think it might be the reason for this problem? Yes I will try to update react-scripts anyhow to see if it helps Thank you very much

[ianschmitz]

It would appear our setting to silence these messages stopped working in webpack some time recently: https://github.com/facebook/create-react-app/blob/8b0dd54c7a7488d46a43ff6d1c67a6b41c31feb1/packages/react-scripts/config/webpackDevServer.config.js#L49

Appears this is the same issue: https://github.com/webpack/webpack-dev-server/issues/2166. If someone could send a PR upstream to fix the issue, it'd be greatly appreciated!

[ArnaudBarre]

The problem is not the logging part, it's that after one minute you are disconnected from the dev server. It appears in 3.3, didn't try with 3.4 ATM

[ianschmitz]

Ah sorry i posted in the wrong issue. Meant to post in #8153. I was tired 😴

[rhyek]

Hi. I'm running npm start inside a kubernetes local development cluster behind a Kong ingress (which uses nginx under the hood) and have this problem with 3.3. Switched to 3.2 and problem is solved, but now don't have the lastest TS 3.7 features.

[omerfaran]

I upgraded my react-scripts to 3.2.0. The problem was "solved" in a sense that that I don't see the message "server was disconnected" in the console. Yet, the exact problems still persist, the web app functions in a somewhat random fashion for 5% of the users, while for others everything is working fine.

All users use the most recent version of Google chrome, I cannot tell what causes those problems to only some of them

[michaeljota]

@omerfaran Hi. I don't think your issue is related to this. You can look up for help in Stackoverflow, or places alike. I know for you it's easier to use the development server, but you need to set up a production environment. You may want to start with that. If your users keep having trouble, again, Stackoverflow and google are your friends. This is just advice, but issues in GitHub or anywhere else for what matters are not places to ask questions about your app, this is just to post about real issues with the project.

Good luck! Happy coding!

[ArnaudBarre]

The problem is not the logging part, it's that after one minute you are disconnected from the dev server. It appears in 3.3, didn't try with 3.4 ATM

Actually 3.4 solved the issue for me

[michaeljota]

It seems to be working for me as well after the update.

[Lrigh1]

3.4 didn't seem to work for me unfortunately.

[AntonioRedondo]

I see the same error on console with v3.4.1. Hot reloading works in the sense every time there is a code change the error will be thrown and the browser will do a full-page refresh but not a per-module reload.

[michaeljota]

@AntonioRedondo the original issue here was that the server disconnected, so no new updates were made. Maybe you have something to do with your HMR configuration?

[AntonioRedondo]

@michaeljota maybe it does, maybe it doesn't. As per discribed on this issue the HMR configuration is as it comes with Create React App, no ejection, no extra config files.

[virgolee2209]

react script 3.4.1 and all of the sudden it happens to me as well. Any fix would be much appreciated

[elisciandrello]

I'm still using 3.2.0 to fix this issue.

[virgolee2209]

Had to revert to base branch and it is working again. I suspect this issue happen when I have some conflicts with some modules that I am using.

[synth3]

I had similar problems when using setupProxy.js with HPM and it turned out that the proxy also affected requests to /sockjs-node which then caused: WebSocket connection to 'wss://localhost:3000/sockjs-node' failed: Invalid frame header and made a connection with the development server impossible.

It turned out that I had to specify the base path for the requests I want to proxy as first argument for createProxyMiddleware:

const { createProxyMiddleware } = require('http-proxy-middleware');

[...]

module.exports = function(app) {
  app.use(apiProxyPath, createProxyMiddleware(apiProxyPath /*only proxy request to that path */, options));
};

[steelx]

facing this issue even in 3.4.0

[SoundSpinning]

Same problem here with "react-scripts": "^3.4.1", and after trying all the above in this thread...

[bigblobby]

I hope this helps someone.

I added this to my config as @nazar said:

location /sockjs-node {
      proxy_pass http://client-web:3000;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;

      # the following two timeout rules fix CRA WDS disconnects after 60s
      proxy_read_timeout 86400s;
      proxy_send_timeout 86400s;
    }

But i was getting errors about $connection_upgrade not being recognised. So i had to add this to my conf file

map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

It now works. Im using react-scripts 3.4.1.

[hiramhibbard]

Still seeing this issue in 3.4.1.

[ghost]

I have two issues when using react-scripts 3.4.1:

The development server has disconnected. Refresh the page if necessary. webpackHotDevClient.js:76 [HMR] Waiting for update signal from WDS... log.js:24

However The development server has disconnected. Refresh the page if necessary. webpackHotDevClient.js:76 only occurs when refreshing the page.

Downgrading to 3.2.0 solved [HMR] Waiting for update signal from WDS... log.js:24 issue but the the other still exists.

I run everything locally.

[michaeljota]

I was seeing this again using the same setup of a reverse proxy. And it was because the reverse proxy was blocking the request (Because of someone updating it).

After updating the reverse proxy, this started worked again (It's working since 3.4.0).

So maybe this can be tested against the described scenario, and because it's working now, this should be close.

This is because since I'm following this issue, several end up here, but with a different scenario, just the same error. And that's not helpful, because with a proper reproducible scenario its unlikely anyone could help them.

[davidtaboas]

I solved this issue adding the following package resolution on my package.json:

  "resolutions": {
    "react-dev-utils": "^10.2.1"
  }

[LuConcanas]

react-scripts 3.4.3, the issue still persists.

[mogba888]

I solved this issue adding the following package resolution on my package.json:

  "resolutions": {
    "react-dev-utils": "^10.2.1"
  }

That's yarn only, no? Or will it work with npm? Where did you add this specifically?

[MarkusBansky]

@macmicke-se add resolutions in the parent scope of package.json file, alongside with dependencies. This worked for me for the npm solution

[aftabnack1]

Facing this issue in 4.0.3.

I had similar problems when using setupProxy.js with HPM and it turned out that the proxy also affected requests to /sockjs-node which then caused: WebSocket connection to 'wss://localhost:3000/sockjs-node' failed: Invalid frame header and made a connection with the development server impossible.

It turned out that I had to specify the base path for the requests I want to proxy as first argument for createProxyMiddleware:

const { createProxyMiddleware } = require('http-proxy-middleware');

[...]

module.exports = function(app) {
  app.use(apiProxyPath, createProxyMiddleware(apiProxyPath /*only proxy request to that path */, options));
};

This solved the issue for me. We need to document this in our setupProxy documentation on CRA website.

[outdoteth]

Changing the nginx conf to this did it for me:

map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;
}

server {
  location /sockjs-node {
    proxy_pass http://somehosthere:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_redirect off;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header   Host $host;
    proxy_set_header   X-Real-IP $remote_addr;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Host $server_name;

    # the following two timeout rules fix CRA WDS disconnects after 60s
    proxy_read_timeout 86400s;
    proxy_send_timeout 86400s;
  }
}