Preview in `v7.1.8` works differently in my environment

[Perdolique]

Describe the bug

I'm using the start-server-and-test command to run tests after the vite preview command. It was fine before Vite v7.1.8 release, but with v7.1.8 I'm getting a connection refused error in 100% cases. v7.1.7 works fine.

I can't reproduce it in StackBlitz, but in my local MacBook, it's reproducible in 100% cases, even with a minimal repo. Details are here: https://github.com/Perdolique/vite-7.1.8-bug

Reproduction

https://github.com/Perdolique/vite-7.1.8-bug

Steps to reproduce

• Clone https://github.com/Perdolique/vite-7.1.8-bug
• npm install
• npm run test

System Info

System:
    OS: macOS 15.6.1
    CPU: (12) arm64 Apple M2 Max
    Memory: 696.39 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.19.0 - ~/.local/state/fnm_multishells/6344_1759403054987/bin/node
    npm: 10.9.3 - ~/.local/state/fnm_multishells/6344_1759403054987/bin/npm
  Browsers:
    Brave Browser: 140.1.82.173
    Chrome: 140.0.7339.215
    Safari: 18.6
  npmPackages:
    vite: 7.1.8 => 7.1.8

Used Package Manager

npm

Logs

Click to expand!

> vite-bug-2@0.0.0 test
> npm run build && start-server-and-test preview http://127.0.0.1:5050/ ls


> vite-bug-2@0.0.0 build
> tsc && vite build

vite v7.1.8 building for production...
✓ 7 modules transformed.
dist/index.html                 0.46 kB │ gzip: 0.29 kB
dist/assets/index-BaiKPFAq.css  1.20 kB │ gzip: 0.62 kB
dist/assets/index-CW01TaJj.js   3.05 kB │ gzip: 1.64 kB
✓ built in 70ms
  start-server-and-test initial parsed arguments { _: [ 'preview', 'http://127.0.0.1:5050/', 'ls' ] } +0ms
  start-server-and-test named arguments: { expect: undefined, proxyHost: undefined, proxyUser: undefined, proxyPassword: undefined, proxyPort: undefined, proxyProtocol: undefined, '--expected': '--expect' } +0ms
  start-server-and-test initial parsed arguments { _: [ 'preview', 'http://127.0.0.1:5050/', 'ls' ] } +0ms
  start-server-and-test parsing CLI arguments: [ 'preview', 'http://127.0.0.1:5050/', 'ls' ] +0ms
  start-server-and-test parsed args: { services: [ { start: 'npm run preview', url: [Array] } ], test: 'ls' } +1ms
1: starting server using command "npm run preview"
and when url "[ 'http://127.0.0.1:5050/' ]" is responding with HTTP status code 200
running tests using command "ls"

  start-server-and-test single service "npm run preview" to run and test +0ms
  start-server-and-test starting server with command "npm run preview", verbose mode? true +0ms
  start-server-and-test starting waitOn [ 'http://127.0.0.1:5050/' ] +2ms
  start-server-and-test wait-on options { resources: [ 'http://127.0.0.1:5050/' ], interval: 2000, window: 1000, timeout: 300000, verbose: true, strictSSL: true, log: true, headers: { Accept: 'text/html, application/json, text/plain, */*' }, validateStatus: [Function (anonymous)], proxy: undefined } +0ms
waiting for 1 resources: http://127.0.0.1:5050/
making HTTP(S) head request to  url:http://127.0.0.1:5050/ ...
  HTTP(S) error for http://127.0.0.1:5050/ Error: connect ECONNREFUSED 127.0.0.1:5050

> vite-bug-2@0.0.0 preview
> vite preview --port 5050 --host 127.0.0.1 --strictPort

  ➜  Local:   http://127.0.0.1:5050/
  start-server-and-test getting child processes +175ms
  start-server-and-test stopping child processes +30ms
  start-server-and-test stopping server +0ms
  start-server-and-test getting child processes +1ms
Error: server closed unexpectedly
    at ChildProcess.onClose (/private/tmp/vite-bug-2/node_modules/start-server-and-test/src/index.js:83:14)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1101:16)
    at ChildProcess._handle.onexit (node:internal/child_process:304:5)

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]

Would you try the preleases between the two versions to find out which commit broke it? You can find it from this link:

My guess is #20837, so maybe good to start with the versions around that commit.

[anthonyhagi]

I can vouch that it's messing with React Router docker builds. Not sure what's changed, but I had to revert back to v7.1.7 to get it working again.

[bluwy]

cc @thatguystone. seems like it could possibly be a breaking change or we're missing additional guards

[SherifAshraf98]

I encountered a similar issue with the latest version v7.1.8 in a React application built with Vite.
While the server commands (Dev or Preview) ran correctly on my local machine, the Docker container exited immediately without any errors or crashes.
Pinning Vite to a previous version resolved the issue, as v7.1.8 appears to behave inconsistently across different environments.

[czue]

I ran into this with Docker as well, and was able to fix it on version 7.1.8 by adding tty: true to my docker-compose file:

vite:
    build:
      context: .
      dockerfile: Dockerfile.vite
    # added this line
    tty: true
    command: npm run dev -- --host
    ports:
      - "5173:5173"

H/T @markwallman

[Perdolique]

Would you try the preleases between the two versions to find out which commit broke it? My guess is #20837, so maybe good to start with the versions around that commit.

Yes, that's it. 302f809 works when bb950e9 does not,

[kbarnesMCC]

Confirming this is also a problem in my Dockerized NuxtJS ecosystem, Vite Client starts but Vite Server crashed the docker container.

Pinning to "7.1.7" fixes things for us.

[thatguystone]

cc @thatguystone. seems like it could possibly be a breaking change or we're missing additional guards

I'm not sure there are any other guards: for docker, unless run -i is used, the pipe is closed before the process starts, and there's no way to differentiate that from any other type of close.

bb950e9 should be reverted.

[bluwy]

Yeah I think we should revert it too. I'll get to it as soon as possible tmr unless someone else from the team does.