dioxus
dioxus copied to clipboard
[Bug] dx serve fails with "Address already in use" while port is actually free (MacOS)
Environment
- OS: MacOS
- Dioxus Version: 0.6.3
- dx CLI Version: 0.6.3
- Rust Version: rustc 1.84.1 (e71f9a9a9 2025-01-27)
Issue Description
When running dx serve in a fullstack project, the server fails to start with an "Address already in use" error, even though the port is actually free and can be used by other servers.
Steps to Reproduce
- Create a new fullstack Dioxus project
- Run
dx serve - Get error:
Failed to bind to 127.0.0.1:8080: Address already in use (os error 48)
Verification
I verified the port is actually free by:
- Running
lsof -i :8080shows no process using the port - Successfully running
simple-http-server -i -p 8080on the same port - The error persists even after:
- Killing all related processes
- Using different ports
- Cleaning project (
cargo clean)
Error Output
10:38:30 [server] listening on http://127.0.0.1:8081
10:38:29 [dev] Build completed successfully in 327ms, launching app! 💫
10:38:30 [server] thread 'main' panicked at crates/dx/src/main.rs:21:10:
10:38:30 [server] Failed to build server: Os { code: 48, kind: AddrInUse, message: "Address already in use" }
Additional Context
- The issue occurs consistently across project restarts
- Other web servers can successfully bind to the same port
- No other processes are visibly using the port
- System permissions appear correct (user owns all relevant directories)
- The problem persists even with elevated permissions
Attempted Solutions
- Used different ports
- Cleaned project and cargo cache
- Checked and fixed file permissions
- Verified network access permissions
- Tested with
simple-http-serverto confirm port availability
Would appreciate any guidance on resolving this issue or what additional information might be helpful.
If you are targeting dioxus desktop with fullstack, this might be the same issue as https://github.com/DioxusLabs/dioxus/issues/3689 which should be fixed by https://github.com/DioxusLabs/dioxus/pull/3693
same bug, wait to resolve it