Getting Forced Redirect on Server URL After "yarn dev"

bud
1

I’m honestly not sure what happened, but suddenly my server url forces a redirect in all browsers to the secure proxy url after running “yarn dev”. To help troubleshoot this, I even spun up a new site and copied over the wp-content folder, changing the bud.config to the new url and it worked fine. I’ve tried changing the port number and that didn’t do it, clearing browser cache (but like I said, this happens in all browsers).

I also just tried to upgraded to the latest Bud 5.7, however upon running yarn dev, it stays stuck on [99%] [cache] begin idle and then the “q” command no longer works, I have to Control + C out of it.

I get a successful compile, however if I visit the server url, I’m immediately redirected to a secure https://beaconwind.local/

 server url:    http://beaconwind.local:3000/   
 proxy url:     http://beaconwind.local/

I’m really not sure how to troubleshoot this any longer. Here’s my bud.config. Any ideas?

/**
 * @typedef {import('@roots/bud').Bud} bud
 *
 * @param {bud} app
 */
module.exports = async (app) => {
  app
    /**
     * Application entrypoints
     *
     * Paths are relative to your resources directory
     */
    .entry({
      app: ["@scripts/app", "@styles/app"],
      editor: ["@scripts/editor", "@styles/editor"],
    })

    /**
     * These files should be processed as part of the build
     * even if they are not explicitly imported in application assets.
     */
    .assets("images")

    /**
     * These files will trigger a full page reload
     * when modified.
     */
    .watch("resources/views/**/*", "app/**/*")

    /**
     * Target URL to be proxied by the dev server.
     *
     * This is your local dev server.
     */
    .proxy("http://beaconwind.local")

    /**
     * Development URL
     */
    .serve("http://beaconwind.local:3000");
};
2

This is happening from your webserver, right? It’s configured to serve your site from https://beaconwind.local/? If so, you need to make sure you’re using the https protocol when passing your URLs in the Bud config

If your webserver isn’t supposed to be doing that, did you at one point have HTTPS enabled with HSTS and then disable it?

2 Likes
3

Thanks Ben, the site was configured to use https but that actually never worked in my bud config. I’d get an error message when visiting the server url so I kept it as http in my config and was good to go (until three hours ago lol).

I decided to push my site to a staging copy and delete my local, then pull it down again to a fresh install. I’m not using SSL for this new one, and everything is working. Thanks for your help!

1 Like
4

Same problem here. Suddenly from yesterday launching yarn dev it correctly launches serveUrl (http://localhost:3000 or http://192.168.1.X:XXXX) but after a second it redirects to proxyUrl (http://mysite.test). Always used http (no https) and never had problems. How can solve this situation? I’m stucked

5

What kind of computer are you running Trellis on? Do you have more than one Trellis instance up at a time?

6

Over here, having this same issue recently and kinda gave up on it. Now I am running into another issue.

Running MacOS and only have one Trellis instance running (for this particular project).

I am using Lima and have my bud config set as:

    .setUrl('https://localhost:1000')
    .setProxyUrl('https://redacted.test')
    .watch(['resources/views', 'app']);

Running yarn bud dev ouputs:

 Network

 › Proxy  ┄ https://redacted.test/
 › Dev    ┄ https://localhost:1000/
          ┄ https://192.168.0.217:1000/

I am able to open and run the proxy url but the localhost gives me:


Secure Connection Failed

An error occurred during a connection to localhost:1234. Cannot communicate securely with peer: no common encryption algorithm(s).

Error code: SSL_ERROR_NO_CYPHER_OVERLAP

A few weeks back when I was working on this project, the localhost would open the site but immediately redirect back to the proxy url.

I’ve tried a handful of other ports as well with no luck today.

7

This isn’t related to this topic though? Sounds like you need to be using http instead of https

I’m locking this topic since it’s two years old and already solved