Server Proxy Urls Don't Respect changeOrigin Setting in Vite Config in Version 7.2.2

[mschaefer-gresham]

Describe the bug

After upgrading to 7.2.2 the redirect from our IDP no longer works. I'm getting a 404 after a POST request is made to https://localhost:8080

I can't provide a reproduction as it requires authenticating against an IDP.

Currently using 7.1.12. Switching to any 7.2 version results in this issue.

Reproduction

https://idonthaveone.com

Steps to reproduce

No response

System Info

System:
    OS: macOS 26.1
    CPU: (14) arm64 Apple M3 Max
    Memory: 1.20 GB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.17.0 - ~/.nvm/versions/node/v22.17.0/bin/node
    Yarn: 4.10.3 - ~/.nvm/versions/node/v22.17.0/bin/yarn
    npm: 10.9.2 - ~/.nvm/versions/node/v22.17.0/bin/npm
  Browsers:
    Edge: 142.0.3595.65
    Safari: 26.1
  npmPackages:
    @vitejs/plugin-react: 5.1.0 => 5.1.0 
    vite: 7.2.2 => 7.2.2

Used Package Manager

yarn

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sapphi-red]

We need more information to solve this on our side (sending a PR from you would be much easier). Would you provide more information?:

• Which commit caused the issue? (you can use pkg.pr.new for the prebuilt packages)
• How do you use the IDP with your Vite app? (e.g. proxy option, redirect via location.href =, reverse proxy in front of Vite server)
• What option / config are you using?
• What IDP are you using?
• What headers are set for the POST request to Vite?
• Are there any proxies between the browser and the Vite server?

[mschaefer-gresham]

I debugged the network flow and see the problem, but don't understand why it's happening. The login flow looks like this:

1. In the UI code we call an endpoint on the server to test if the user is logged in:

2. This call is proxied to our api gateway like so:

3. When this endpoint indicates the user is not logged in, we redirect to the login page like this:

The login url is: /auth/login, which is also proxied to our api gateway:

We get a response from the api gateway that redirects us to Azure B2C. This presents the user with a login page.

The Azure B2C url itself contains another redirect url for our application used to signin once the user successfully logs in. This is all standard B2C behavior (we don't control this).

4. In version 7.1.12, this redirect looks like this:

The redirect in the Azure B2C url uses port 8080:

https://localhost:8080/signin-oidc

5. But when using version 7.2.2, the redirect uses port 5005:

https://localhost:5005/signin-oidc

So the change in behavior is how this redirect url is established. I can reproduce this simply by changing the vite version from 7.1.12 to 7.2.2.

There is no code that explicitly sets this full url. It's inferred from the url in the api gateway. Here is an example of the url received in the api gateway when using 7.1.12:

And here is the same example when using 7.2.2:

You can see the ports are different. Can you explain this change in behavior?

[sapphi-red]

I guess it's related to #20869 (sagemathinc/http-proxy-3#33). Would you try setting server.https: false? If that works, then it's probably related to that PR.

[sapphi-red]

Here is an example of the url received in the api gateway when using 7.1.12:

How is that GET https://localhost:8080/api/app-user/me HTTP 1.1 200 OK generated? Does it use some headers to construct that value?

[mschaefer-gresham]

It's not that straightforward to set server.https: false. The api gateway is not configured to serve over http. All the proxy urls would have to change in addition. Not saying it's not possible, but it would require several changes, including the B2C configuration.

The call to https://localhost:8080/api/app-user/me is simply called in a React hook as part of a route guard. Nothing special.

[mschaefer-gresham]

I tried setting the changeOrigin setting for each proxy url and this had no effect in 7.2.2. The server always receives the proxy url https://localhost:5005/...

However when using 7.1.12, the setting is respected. This is a related change of behavior. Feels like a bug to me.

[mschaefer-gresham]

@sapphi-red I did not mean to close this.

[sapphi-red]

Ah, ok. I guess it's because this part of the code doesn't work with the new http2 support feature (sagemathinc/http-proxy-3#33).
https://github.com/sagemathinc/http-proxy-3/blob/ce8f922ebbbc8ab3c3c7252e3460b791b3a772eb/lib/http-proxy/common.ts#L140-L145

Hmm, but IIUC it's not possible to set a Host header with HTTP2 and the successor, the :Authority pseudo header, always matches the actual request host. I guess there's no way to achieve the same behavior.
Does the api gateway support X-Forwarded-Host header? If so, setting xfwd: true may work.

[mschaefer-gresham]

It's not currently implemented, but there is support for it. Before I head down this route, are you certain changeOrigin will no longer work going forward? Using the X-Forwarded-Host header is the only way deal with this now?

If so, at the very least you need to remove the changeOrigin property, no? Mention of this in the release notes would be useful too.

[sapphi-red]

Before I head down this route, are you certain changeOrigin will no longer work going forward? Using the X-Forwarded-Host header is the only way deal with this now?

As far as I can think of... I'm not an expert of HTTP spec so I don't have a strong confidence.

If so, at the very least you need to remove the changeOrigin property, no? Mention of this in the release notes would be useful too.

It still works if the Vite server is running in HTTP 1.x or the proxy target is listening on HTTP 1.x. Yeah, I think we should add it to the description of the option and in the related PR.