Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a problem related to the vite server port #5241

Closed
7 tasks done
classmatewu opened this issue Oct 9, 2021 · 4 comments · Fixed by #8543
Closed
7 tasks done

a problem related to the vite server port #5241

classmatewu opened this issue Oct 9, 2021 · 4 comments · Fixed by #8543
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)

Comments

@classmatewu
Copy link

classmatewu commented Oct 9, 2021

Describe the bug

  1. a new vite app: default port is 3000
    image

  2. my koa server: this port is also 3000
    image

when I start vite app and then start koa server OR start koa server and then start vite app, no indication of port conflict.

And I use Google Chrome to access the page 127.0.0.1:3000, the page display content about the latter server content.

Reproduction

This question reminds me of PM2——master-slave mode, but vite didn't handle it well. I try to read the vite's source code, but I am worried about misunderstanding, so come here to issue. If this is a problem, can you provide solutions or fix it as soon as possible?

thanks.

System Info

@vite:   2.6.4,
@node:   14.16.0,
@koa:    2.13.3,
@Google: Chrome: 94.0.4606.71 (official version) (x86_64),
@OS: 	 macOS Catalina 10.15.7,
@JavaScript:	V8 9.4.146.18,

Used Package Manager

npm

Logs

null

Validations

@sodatea
Copy link
Member

sodatea commented Oct 24, 2021

Not necessarily a critical bug.
Your koa server listens to 0.0.0.0 or :: by default, not 127.0.0.1 (which is the Vite default).
As Node.js sets all sockets with the SO_REUSEADDR flag (explanation: https://medium.com/@eplawless/node-js-is-a-liar-sometimes-8a28196d56b6), it allows other sockets to reuse the same port as long as it doesn't listen to the exact same address.

The problem here is that Vite chooses to display localhost while the actually bound address is 127.0.0.1; this could be misleading in some rare edge cases, like this one.

Take my network environment as an example (may not be very accurate, I'm not a network expert):

  • In my /etc/hosts, I have localhost bound to both 127.0.0.1 and ::1, meaning that localhost resolves to ::1 when IPv6 is available;
  • My ISP and router have IPv6 configured;
  • When I start a Vite server, it listens to 127.0.0.1:3000 by default;
  • When I start the koa server, it listens to the unspecified IPv6 address ::, which also accepts connections from ::1;
  • So, when I visit localhost:3000, it's equivalent to ::1:3000 as I'm in an IPv6 environment. So I end up hitting the koa server;
  • When I visit 127.0.0.1:3000, I can still visit the Vite server.

@sodatea sodatea added p2-nice-to-have Not breaking anything but nice to have (priority) p3-minor-bug An edge case that only affects very specific usage (priority) and removed pending triage p2-nice-to-have Not breaking anything but nice to have (priority) labels Oct 24, 2021
@sodatea
Copy link
Member

sodatea commented Oct 24, 2021

So the solution could be either of the following:

  • Let the server host default to:
    • Both 127.0.0.1 and ::1 (most intuitive, but I don't know how to implement that)
    • Or ::1 when IPv6 is available, and 127.0.0.1 otherwise (most conventional, but would still surprise people sometimes)
  • Or, we don't prettify the output to display localhost when it's actually 127.0.0.1

@smithyj
Copy link

smithyj commented Jun 3, 2022

This problem is solved,set server.host = 0.0.0.0,example config:

server: {
    host: '0.0.0.0',
  },

@smithyj
Copy link

smithyj commented Jun 3, 2022

@sodatea This issues should closed

@github-actions github-actions bot locked and limited conversation to collaborators Jun 29, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants