Gatsby: Socket errors with WSL2

[jordanlesich]

Description

I get CORS errors that look like this whenever I open up my locally hosted project in the browser.

Failed to load resource: net::ERR_CONNECTION_REFUSED
:42421/socket.io/?EIO=3&transport=polling&t=NCfY1_1:1 Failed to load resource: net::ERR_CONNECTION_REFUSED
:42421/socket.io/?EIO=3&transport=polling&t=NCfY2s7:1 Failed to load resource: net::ERR_CONNECTION_REFUSED
:42421/socket.io/?EIO=3&transport=polling&t=NCfY3_a:1 Failed to load resource: net::ERR_CONNECTION_REFUSED

I am not using Docker or Apache2.

I have no other servers open and running

Opening the browser in Incognito mode does not stop the errors (could have been caused by an extension)

Errors appear in Chrome, not firefox

Steps to reproduce

1. Create a new gatsby project using the default starter.
2. Open it in the browser.
3. Press f12 and go to the console.
4. Watch as the errors roll in,

Expected result

No CORS errors.

Actual result

CORS errors.

Environment

WSL2 on Windows 10. Note that I am using this service becuase of the recommendation on the Gatsby Windows page

https://www.gatsbyjs.org/docs/gatsby-on-windows/

System:
OS: Linux 4.19 Ubuntu 20.04 LTS (Focal Fossa)
CPU: (4) x64 Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
Shell: 5.0.16 - /bin/bash
Binaries:
Node: 12.18.2 - ~/.nvm/versions/node/v12.18.2/bin/node
Yarn: 1.22.4 - ~/.nvm/versions/node/v12.18.2/bin/yarn
npm: 6.14.5 - ~/.nvm/versions/node/v12.18.2/bin/npm
npmPackages:
gatsby: ^2.23.12 => 2.23.12
gatsby-image: ^2.4.9 => 2.4.9
gatsby-plugin-manifest: ^2.4.14 => 2.4.14
gatsby-plugin-offline: ^3.2.13 => 3.2.13
gatsby-plugin-react-helmet: ^3.3.6 => 3.3.6
gatsby-plugin-sharp: ^2.6.14 => 2.6.14
gatsby-source-filesystem: ^2.3.14 => 2.3.14
gatsby-transformer-sharp: ^2.5.7 => 2.5.7
npmGlobalPackages:
gatsby-cli: 2.12.56

I have read other issues
https://github.com/gatsbyjs/gatsby/issues/24864

But just becuase this is a CORS issue does not mean this is not a Gatsby issue. If booting up a Gatsby local development server causes all these errors, then it's a problem caused by Gatsby. (Probably socket.io) Especially, if I'm developing on an environment the Gatsby team has recommended. Especially if starting up other React related frameworks like NextJS or CRA doesn't cause these errors.

My guess is that since the WSL can interfere with web sockets, it's probably a conflict, but I have no idea. Which is why shutting issues without examining them is probably not a good idea.

[graysonhicks]

Attempted to recreate this with the provided steps. Screenshot below shows no console errors.

Gatsby clipboard info when attempting to reproduce:

  System:
    OS: macOS 10.15.3
    CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.18.2 - ~/.nvm/versions/node/v12.18.2/bin/node
    Yarn: 1.16.0 - /usr/local/bin/yarn
    npm: 6.14.5 - ~/.nvm/versions/node/v12.18.2/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Firefox: 61.0.1
    Safari: 13.0.5
  npmPackages:
    gatsby: ^2.23.12 => 2.23.12
    gatsby-image: ^2.4.9 => 2.4.9
    gatsby-plugin-manifest: ^2.4.14 => 2.4.14
    gatsby-plugin-offline: ^3.2.13 => 3.2.13
    gatsby-plugin-react-helmet: ^3.3.6 => 3.3.6
    gatsby-plugin-sharp: ^2.6.14 => 2.6.14
    gatsby-source-filesystem: ^2.3.14 => 2.3.14
    gatsby-transformer-sharp: ^2.5.7 => 2.5.7

Since I am using MacOS and you are using WSL, I think your assumption that it has to do with WSL is probably correct.

[jordanlesich]

@graysonhicks

Do you know if I can go on developing while the errors pile up in the console? Is it safe, or will this cause more problems down the line somehow?

[graysonhicks]

@jordanlesich CORS errors are generally a problem when they are preventing data that you need to get from being fetched. In this case, I am not sure what the socket set up provides in the develop environment. While having errors in the console is not ideal, if you are not prevented from developing as expected then I don't see it causing any problems.

That being said, most importantly, you should run a production build and visit your site. If there are still errors, I would be more concerned, as those are outside the develop environment and could cause issues for your users. I would say I doubt that those errors will persist in prod, but I would definitely check.

[jordanlesich]

@graysonhicks Thanks. So if I do a Gatsby build, then a Gatsby serve, it seems to run alright without the errors. However if I run the development server after that, the serve won't work when I run server 9000. I have to do a fresh build after running gatsby develop. It's been a while since I used Gatsby, I forget if that's standard behavior or not.

Either way, it's enough to go off while we try to get this thing figured out--I hope.

Here's a couple other things I found interesting.

Develop works fine on firefox, but I get this warning that is probably related:
_The script from “http://localhost:8000/socket.io/socket.io.js” was loaded even though its MIME type (“”) is not a valid JavaScript MIME type._

I would try to fix that, but I don't know where to go.

The browser automatically opens the window on 8001 and 9001

Gatsby develop window opens on 8001, even though the link I click on in the cli clearly says localhost 8000. I don't have any other projects running, let alone projects on that port. I get the same behavior on port 9000 when I do Gatsby serve.

[graysonhicks]

if I run the development server after that, the serve won't work when I run server 9000

This behavior is normal.

The script from “http://localhost:8000/socket.io/socket.io.js” was loaded even though its MIME type (“”) is not a valid JavaScript MIME type.

Sorry, also not sure where to go with that, though I do see an identical (unresolved, but closed) issue here.

The browser automatically opens the window on 8001 and 9001

Can you scan your ports to confirm nothing else is running? Normally when I see this, Gatsby prompts to run on another port and it is very apparent.

[jordanlesich]

@graysonhicks So I found a fix and a good explanation of both why the problem was happening and why the fix worked. I had posted the issue on a WSL2 subbreddit called r/bashonubuntuonwindows. A user @superlinkx gave me a detailed beakdown about how the LinuxVM I'm running has it's own version of local host. While Windows does some automatic port forwarding, which is different than the loopback adapter Gatsby is listening on.

By switching the development host on Gatsby to 0.0.0.0 (gatsby develop --host=0.0.0.0.), we can get Gatsby to listen to all adapters, so we can see requests coming in from the Windows side.

TLDR Fix; gatsby develop --host=0.0.0.0. + type localhost:[address] in the browser window. This stops the errors for me.

When you first use the fix, it will direct the user to 0.0.0.0. The user who provided the fix expressed that this might be a mistake on Gatsby's part, as 0.0.0.0 is a 'magic' IP that tells gatsby to bind all available IP's together.

This is obviously all a little bit beyond my skill level, so I'll post a link to the reddit. superlinkx does a much better job explaining it in the comments than I can. For anyone interested in why/how, this is definitely recommended reading.

https://www.reddit.com/r/bashonubuntuonwindows/comments/hmz2yd/does_anyone_here_use_gatsby_having_websocket_cors/

Also, another user on the Gatsby reddit pointed out that this probably wasn't a CORS error. With only my limited understanding, I'm inclined to agree--which means that I labled this issue incorrectly. I just changed the title to more accurately reflect the issue. As far as going forward, I am unsure of how to make gatsby more in line with other services that provide socketed hosts. That will probably be a discussion for people who are much more experienced than I am, but I am happy to help in whatever way I can.

Here's a link to the Gatsby subreddit post. I recieved a lot useful insights on there as well.
https://www.reddit.com/r/gatsbyjs/comments/hmwlyd/does_anybody_here_know_how_to_deal_with_these/

[jordanlesich]

Also, I can still scan the ports and try to reproduce the issue if you think that will help clear anything up. I do know that I checked to make sure that it was the only open instance of VScode or a terminal window or anything like that. This was definitely the most commonly asked question on the Gatsby reddit.

[graysonhicks]

Ah okay. Yea I do have my start command typically set as "start": "gatsby develop -H 0.0.0.0", but don't remember where or why I picked up that pattern.

Agreed that I don't know if this is something Gatsby needs to change anywhere, but I think it is good we have a well documented fix here now for other WSL2 users and I don't think scanning your ports will provide anything useful at this point.

[lukasilestam]

I have this same error on remote linux server.
polling-xhr.js:268 GET http://domain.com:34415/socket.io/?EIO=3&transport=polling&t=NDJkuMQ net::ERR_CONNECTION_REFUSED
when I open the port 34415 everything is ok... but port is randomized every time when I start gatsby develop

gatsby version: 2.23.12
starter: gatsby-starter-default

edit: 2.15.31 - works perfectly

[narthur]

Same error, trying to run gatsby develop --host 0.0.0.0 in a Docker container. The randomized port prevents me from opening the right one.

[krystonen]

I have the same issue as @narthur.

[pleky]

I have the same issue as @narthur. :(

[bingalls]

I added some steps to reproduce in #24373 HTH

[clieee]

Anyone have updates on this issue?

[LuisOsta]

Same issue here, it seems to be some issue with the way that Gatsby interacts with WSL 2. The same issue shows up with and without Docker and with a variety of v2.* versions of Gatsby. (The issue persists even with the -H 0.0.0.0)

Has anyone been able to find a solution or workaround?

[rafaelbm9126]

some update on this issue?

[abohannon]

I run into this issue as well a handful of times per week.

[TimFung93]

I am also running into this issue, the -H 0.0.0.0 does not get rid of the errors.

[jdpaterson]

Same error, trying to run gatsby develop --host 0.0.0.0 in a Docker container. The randomized port prevents me from opening the right one.

Looks like INTERNAL_STATUS_PORT is the env variable to use.

Running export INTERNAL_STATUS_PORT=1234 from within the container, and having port 1234 open in the container, fixes it for me.