Sửa lỗi 'An attempt was made to access a socket in a way forbidden by its access permissions' trên Windows

Lỗi Gặp Phải

Bạn khởi động ứng dụng và ngay lập tức gặp phải:

SocketException: An attempt was made to access a socket in a way forbidden by its access permissions 0.0.0.0:5000

Không có tiến trình nào khác đang dùng cổng 5000. Tường lửa không chặn nó. Bạn đang chạy với quyền Administrator. Không có gì rõ ràng giải thích tại sao Windows từ chối cho phép ứng dụng của bạn bind cổng đó.

Nguyên Nhân

Windows duy trì một dải cổng động (ephemeral) — một tập hợp các cổng được dành riêng cho các kết nối đi. Bất kỳ cổng nào nằm trong dải này đều không được phép bind thủ công, dù hiện tại không có gì đang lắng nghe trên đó.

Hyper-V, WSL2 và Docker Desktop đã làm tình trạng này tồi tệ hơn nhiều. Khi bất kỳ tính năng nào trong số này đang hoạt động, Windows sẽ tích cực đặt trước các khối cổng lớn khi khởi động. Các đặt trước này xuất hiện trong danh sách excluded port range và chặn ứng dụng của bạn một cách thầm lặng — không có lỗi "port in use", chỉ là thông báo quyền truy cập khó hiểu đó.

Cổng 5000 thường xuyên bị ảnh hưởng. Nó nằm trong dải động mặc định trên nhiều phiên bản Windows, và Hyper-V thường chiếm toàn bộ dải 5000–5059 khi khởi động.

Bước 1 — Xác Nhận Cổng Đã Bị Đặt Trước

Chạy lệnh này trong Command Prompt với quyền Administrator (Run as Administrator):

netsh interface ipv4 show excludedportrange protocol=tcp

Ví dụ kết quả:

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
      5000        5059
      5985        5985
     49673       49772
     49773       49872

4 exclusion ranges present

Nếu cổng của bạn nằm trong bất kỳ dải nào trong số đó, đây chính là thủ phạm. Windows đã đặt trước nó và sẽ không cho phép ứng dụng của bạn bind — bất kể có thực sự có gì đang lắng nghe hay không.

Cách Sửa 1 — Dùng Cổng Khác (Nhanh Nhất)

Cách sửa nhanh nhất: chọn một cổng nằm ngoài các dải bị loại trừ. Các cổng như 3000, 8080, 8000 và 8888 hầu như không bao giờ bị Hyper-V đặt trước và hoạt động ổn định cho môi trường phát triển cục bộ. Tránh các cổng tùy ý trong dải 5000–7000 — đó là lãnh địa của Hyper-V.

Với ứng dụng .NET, cập nhật launchSettings.json:

{
  "profiles": {
    "MyApp": {
      "applicationUrl": "http://localhost:8080"
    }
  }
}

Với Node.js:

PORT=8080 node server.js

Với Python (Flask):

flask run --port=8080

Cách Sửa 2 — Đặt Trước Cổng Trước Khi Hyper-V Làm Điều Đó

Hãy đi trước Hyper-V. Đăng ký exclusion của riêng bạn trước khi Windows khởi động và Hyper-V sẽ không động vào cổng đó. Từ Command Prompt với quyền Administrator:

netsh int ipv4 add excludedportrange protocol=tcp startport=5000 numberofports=1

Chờ đã — lệnh này thêm một exclusion, nghe có vẻ ngược đời. Nhưng đây là mẹo: các exclusion do người dùng định nghĩa được xử lý trước khi Hyper-V chiếm khối động của nó. Đăng ký cổng 5000 một cách tường minh và Hyper-V sẽ bỏ qua nó trong quá trình đặt trước của chính nó.

Khởi động lại, rồi xác nhận:

netsh interface ipv4 show excludedportrange protocol=tcp

Cổng 5000 bây giờ sẽ xuất hiện như một mục riêng biệt, tách khỏi khối Hyper-V lớn.

Cách Sửa 3 — Dịch Chuyển Dải Cổng Động

Một hướng khác: đẩy toàn bộ dải cổng động ra khỏi tầm với của bạn. Trên một cài đặt Windows sạch, nó bắt đầu từ 49152, nhưng Hyper-V có thói quen kéo nó xuống thấp hơn — đôi khi xuống tận vùng 5000.

Kiểm tra dải hiện tại:

netsh int ipv4 show dynamicport tcp

Đặt lại về dải IANA khuyến nghị (49152–65535):

netsh int ipv4 set dynamicport tcp start=49152 num=16384
netsh int ipv6 set dynamicport tcp start=49152 num=16384

Khởi động lại Windows sau cả hai lệnh. Đây thường là cách sửa sạch sẽ nhất khi cả một dải cổng bị chặn — không chỉ 5000 mà tất cả các cổng trong dải 5000–10000.

Cách Sửa 4 — Vô Hiệu Hóa Rồi Bật Lại Hyper-V Để Xóa Reservations

Vẫn thấy cổng bị chặn sau Cách Sửa 3? Hyper-V có thể đã khóa chúng từ một lần khởi động trước. Tắt bật nó buộc Windows phải xây dựng lại bảng reservation từ đầu:

dism.exe /Online /Disable-Feature:Microsoft-Hyper-V

Sau khi khởi động lại, bật lại:

dism.exe /Online /Enable-Feature:Microsoft-Hyper-V-All

Khởi động lại thêm một lần nữa. Khi Windows khởi động xong, kiểm tra dải bị loại trừ — các khối reservation tích cực của Hyper-V thường đã biến mất hoặc chỉ còn lại một vài mục.

Lưu ý: Thao tác này tạm thời vô hiệu hóa WSL2 và Docker Desktop (cả hai đều phụ thuộc vào Hyper-V). Chúng sẽ hoạt động trở lại khi bạn bật lại Hyper-V.

Xác Nhận Đã Sửa Thành Công

Kiểm tra nhanh trước khi khởi động lại ứng dụng — xác nhận cổng đã được giải phóng:

netsh interface ipv4 show excludedportrange protocol=tcp | findstr "5000"

Không có kết quả đầu ra có nghĩa là cổng đã tự do. Khởi động ứng dụng và nó sẽ bind mà không có vấn đề gì.

Muốn kiểm tra trực tiếp hơn? Chạy lệnh này trong PowerShell:

$listener = [System.Net.Sockets.TcpListener]::new([System.Net.IPAddress]::Any, 5000)
try {
    $listener.Start()
    Write-Host "Port 5000 bound successfully"
    $listener.Stop()
} catch {
    Write-Host "Failed: $_"
}

Nếu script thành công, ứng dụng của bạn cũng sẽ thành công.

Phòng Ngừa

Tránh dùng cổng tùy ý trong dải 5000–7000 trên Windows + Hyper-V. Đó là nơi Hyper-V thường để lại các khối reservation lớn khi khởi động. Các cổng dev phổ biến như 3000, 8080 và 8888 hầu như không bao giờ bị đặt trước.
Thiết lập port exclusion trong script khởi động. Nếu nhóm của bạn luôn dùng cổng 5000, hãy tích hợp lệnh netsh int ipv4 add excludedportrange vào script thiết lập môi trường dev. Máy mới sẽ được bảo vệ trước khi Hyper-V có cơ hội can thiệp.
Ghi lại lựa chọn cổng của bạn. Đặt cổng đã chọn vào .env.example hoặc README.md để đồng đội không gặp phải vấn đề tương tự khi thiết lập máy của họ.
Kiểm tra reservations sau khi nâng cấp Windows. Các bản cập nhật tính năng — đặc biệt là những bản ảnh hưởng đến Hyper-V hoặc WSL2 — có thể đặt lại hoặc mở rộng port reservations. Chạy show excludedportrange sau bất kỳ bản cập nhật Windows lớn nào.