Invalid options object. Dev Server has been initialized using an options object that does not match the API schema

Here is a workaround. Delete "proxy": "http://localhost:6000". Install package http-proxy-middleware with command npm install http-proxy-middleware --save. Create a file setupProxy.js inside your src folder or the root of your folder. Add these lines inside:

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

module.exports = function(app) {
  app.use(
    '/api',
    createProxyMiddleware({
      target: 'http://localhost:6000',
      changeOrigin: true,
    })
  );
};

Now, run your app. It should work.

A quick solution is to downgrade your webpack version using react-scripts

In the package.json file of your react-app, change the react-scripts version.

Replace

"react-scripts": "5.*", 

To

"react-scripts": "4.0.3",

Remove node_modules and install the packages again for your react app.

The other solutions did not work for me so here's what I found:

This seems to be a CRA bug (security feature?) where allowedHosts gets set to [undefined] because prepareUrls doesn't set lanUrlForConfig when both a host and a proxy are specified. The relevant CRA GitHub issue is here.

If appropriate in your use case (read here to learn more), this can be avoided by creating a .env file and adding DANGEROUSLY_DISABLE_HOST_CHECK=true to it or trying DANGEROUSLY_DISABLE_HOST_CHECK=true yarn start.

Run npm audit fix --force And while still connected to the internet Run npm start

Should work fine

Reverting back to an older version of node worked for me. First of all clear npm's cache and install older version of node.

    > sudo npm cache clean -f
    > sudo npm install -g n
    > sudo n <version>

Latest version 18 was not working for me; version 14.8.2 works for me as I was using this version previously. You can try with any version below 18

I just debugged the issue in JS Debugger.

Node v18 changed os.networkInterfaces() family:

v18.0.0
The family property now returns a number instead of a string.

This is throwing off address module used by react-scripts which checks family against "IPv4"

For me removing package-lock.json and node_modules folder - then running npm i solved the problem.

I solved the problem with the http-proxy-middleware solution as others. But to get it working properly, I had to close down my VPN. Same answer as Saeed Kolivand has above. =)

To overcome this problem what you should do is that You just have to be connected to internet when you run npm start

this error with Node version 18.0.0 , I try with version Node 16.15.0 it works fine

I had the same problem and josipat's answer worked for me, except I needed to install it as a development dependency. The solution where one saves the following code to src/setUpProxy.js originates from Create React App.

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

module.exports = function(app) {
  app.use(
    '/api',
    createProxyMiddleware({
      target: 'http://localhost:5000',
      changeOrigin: true,
    })
  );
};

reactjs create-react-app

I got this error only when switching to Node 18.0.0 with nvm. Getting rid of "proxy":"http://localhost:5000" fixes it, but it's not an option for me and I'd like to avoid the proxy middleware on server. If you switch to a previous Node version like 17.0.0 it works fine. I think that could be a better option until CRA team does not address the issue.

For 5.0.1 react-scripts the bug has not been reproduced, but error occurs in 5.0.0. I guess you could use 5.0.1 to solve this problem

So my team had the same issue, with the same error of options.allowedHosts[0] should be a non-empty string. The solution we outline below is a very specific error and most likely does not pertain to many people.

In our case, the allowedHosts[0] variable was undefined and we traced the allowedHosts[0] variable to be equal to allowedHost in node_modules\react-scripts\config\webpackDevServer.config.js.

module.exports = function (proxy, allowedHost) {
  const disableFirewall =
    !proxy || process.env.DANGEROUSLY_DISABLE_HOST_CHECK === 'true';
  return {
    // WebpackDevServer 2.4.3 introduced a security fix that prevents remote
    // websites from potentially accessing local content through DNS rebinding:
    // https://github.com/webpack/webpack-dev-server/issues/887
    // https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a
    // However, it made several existing use cases such as development in cloud
    // environment or subdomains in development significantly more complicated:
    // https://github.com/facebook/create-react-app/issues/2271
    // https://github.com/facebook/create-react-app/issues/2233
    // While we're investigating better solutions, for now we will take a
    // compromise. Since our WDS configuration only serves files in the `public`
    // folder we won't consider accessing them a vulnerability. However, if you
    // use the `proxy` feature, it gets more dangerous because it can expose
    // remote code execution vulnerabilities in backends like Django and Rails.
    // So we will disable the host check normally, but enable it if you have
    // specified the `proxy` setting. Finally, we let you override it if you
    // really know what you're doing with a special environment variable.
    // Note: ["localhost", ".localhost"] will support subdomains - but we might
    // want to allow setting the allowedHosts manually for more complex setups
    allowedHosts: disableFirewall ? 'all' : [allowedHost],

urls.lanUrlForConfig is passed in to the config file from node_modules\react-scripts\scripts\start.js to allowedHost.

const createDevServerConfig = require('../config/webpackDevServer.config');
...
createDevServerConfig(proxyConfig, urls.lanUrlForConfig)

urls.lanUrlForCofig is produced by the prepareUrls function in node_modules\react-dev-utils\WebpackDevServerUtils.js.

const urls = prepareUrls(
  protocol,
  HOST,
  port,
  paths.publicUrlOrPath.slice(0, -1)
);

In the prepareUrls function, urls.lanUrlForConfig is set as undefined in the case that the computer's IPv4 address is non-private as seen below:

try {
  // This can only return an IPv4 address
  lanUrlForConfig = address.ip();
  if (lanUrlForConfig) {
    // Check if the address is a private ip
    // https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces
    if (
      /^10[.]|^172[.](1[6-9]|2[0-9]|3[0-1])[.]|^192[.]168[.]/.test(
        lanUrlForConfig
      )
    ) {
      // Address is private, format it for later use
      lanUrlForTerminal = prettyPrintUrl(lanUrlForConfig);
    } else {
      // Address is not private, so we will discard it
      lanUrlForConfig = undefined;
    }
  }
} catch (_e) {
  // ignored
}

So in the end, we determined that the reason why we were having the error was because the ip address that we being pulled from the machine was non-private due to some ethernet cable configurations (We were getting a 169. address, an APIPA one, that was because the machine couldn't reach a DHCP server). This caused the urls.lanUrlForConfig to be undefined, which would ultimately get passed all the way down to the allowedHosts[0] variable and cause the error.

Fixing the inability of not being able to connect to the DHCP server is another issue itself, but as a hotfix for development purposes only, we added a DANGEROUSLY_DISABLE_HOST_CHECK=true into our .env file and it worked fine after restarting the development server. Setting "allowedHosts": "all" in our package.json was another solution.

If you add or remove "proxy": "http://localhost:6000" in package.json, then remove node_modules and reinstall it. This works for me.

Faced the same issue several times but finally I found a solution!!

I solved this problem by adding "allowedHosts": "all" to my package.json file

Example:

"allowedHosts": "all",
"proxy": "http://localhost:3001/api",
"name": "simple-blog",
"version": "0.1.0",
"private": true,
"dependencies": {
  "@testing-library/jest-dom": "^5.1

Another solution is by adding DANGEROUSLY_DISABLE_HOST_CHECK=true to your .env file it solves the problem too.

Setting "allowedHosts" as a property in package.json didn't work for me. I had to wrap it in an options property:

"options": {
    "allowedHosts": ["localhost", ".localhost"],
    "proxy": "https://localhost:3386/"
  }

After that, npm start did the trick without having to re-install modules.

I had the same issue, You can add "allowedHosts": "all" after "proxy": "https://yourdomain" in your package.json. hopefully it solves your problem.

update: the problem was with the company VPN. When I disconnect the VPN, it works normally.