fix(server): use --host duplicate port number (#12205)

[kinfuy]

Description

fix #12205
fix #12144
superseds close #10651
close #10638

When localhost(vite dev) is listening on port 5173, it's possible for 127.0.0.1(vite dev --host) to listen on port 5173 again.

Additional context

Re: #12208

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[patak-dev]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
astro	✅ success
histoire	❌ failure
iles	✅ success
ladle	✅ success
laravel	✅ success
marko	✅ success
nuxt-framework	✅ success
previewjs	✅ success
qwik	✅ success
rakkas	✅ success
sveltekit	✅ success
vite-plugin-ssr	✅ success
vite-plugin-react	✅ success
vite-plugin-react-pages	❌ failure
vite-plugin-react-swc	✅ success
vite-plugin-svelte	✅ success
vite-plugin-vue	✅ success
vite-setup-catalogue	✅ success
vitepress	✅ success
vitest	✅ success
windicss	✅ success

[patak-dev]

Interesting approach. I'm a bit worried about the inverted logic here. Are we sure that connect only fails when the port is unused? Could a used port still reject the connection making this logic invalid?

[kinfuy]

I looked up a lot of data. It is only the IP or port number with invalid connection that fails.
Of course, I can't guarantee that this is correct.
I tested Node16 and Node18 in Windows and Mac, and they all work normally

[patak-dev]

Ecosystem CI is happy, including vite-setup-catalogue. I think we could merge this one to try it out during the beta period and revert later if it causes issues. @sapphi-red what do you think?

[sapphi-red]

Yeah, it's an interesting approach. I think it's a good idea to try this in beta.

[sapphi-red]

This fail might cause an issue. This PR's approach doesn't work well in a concurrent situation.
https://github.com/vitejs/vite/actions/runs/4292613465/jobs/7479273031#step:13:105

I guess this fail happened by the following steps:

1. playground A: net.connect checks port 5173 => success
2. playground B: net.connect checks port 5173 => success
3. playground A: listen port 5173
4. playground B: listen port 5173 => error

[sapphi-red]

Umm, it failed 3 out of 7 times.

[kinfuy]

In this way, concurrency seems to be inevitable, and better methods need to be found 🤔