BrowserSync (dev mode) stuck loading – no error or timeout

After creating a fresh theme I’m realising I can build ok but the dev mode doesn’t load. No errors, no timeout, nothing. I’m up against two crazy deadlines so any help super appreciated. Not sure where to start.

Here’s my config.json.

  "entry": {
    "main": [
    "customizer": [
  "publicPath": "/wp-content/themes/warehouserentals",
  "devUrl": "http://localhost:8080/warehouse/wordpress",
  "proxyUrl": "http://localhost:3000",
  "cacheBusting": "[name]_[hash:8]",
  "watch": [

The only thing that has changed from previous projects is that I switched to running the built in Apache installation on MacOS, previously I was running Mampstack. Don’t know if there could be a quirk that is messing this up.

Frequently these kinds of errors have to do with misconfiguring the publicPath, devUrl, or proxyUrl in your config.json. Your devUrl And proxyUrl both use localhost, which seems potentially problematic. Your devUrl should probably use a normal domain.

1 Like

You are right, which is why I posted my config.json above in case there was something up.

But I have always used this type of configuration and I also just started a new site which looks the same, and works fine.

  "publicPath": "/wp-content/themes/mills",
  "devUrl": "http://localhost/mills/wordpress",
  "proxyUrl": "http://localhost:3000",

Are there any other areas where I should be looking?

All the background compilation stuff seems to be working fine, the issue is really just that nothing is served to the browser.

The only other fix I can think of is copying over the code from a working installation.

You’ve changed your webserver, so it seems reasonable that the new server handles certain things (such as domain and port mapping) differently. What was the reason for this change? Using MacOS’s built-in Apache server seems risky to me.

The example you posted from your other site isn’t the same:

"devUrl": "http://localhost:8080/warehouse/wordpress",
"devUrl": "http://localhost/mills/wordpress",

One specifies a port, the other does not.

Oh damn! Thanks so much for spotting. I was just staring at the proxyUrl.

The issue was that the previous server was running on 8080.