Hướng dẫn và khắc phục sự cố cổng localhost 127.0.0.1:57573
Chạy một đoạn mã Flask nhỏ. Dán `http://127.0.0.1:57573` vào trình duyệt. Có hai kết quả. Trang web tải được, hoặc cửa sổ terminal hiện lên thông báo lỗi `ECONNREFUSED` màu đỏ và trình duyệt hiển thị biểu tượng phích cắm bị ngắt kết nối buồn bã.
Cả hai kết quả đều không có gì bí ẩn. Địa chỉ này có hai phần: 127.0.0.1 là địa chỉ loopback IPv4, và 57573 là một cổng mà hệ điều hành đã chọn gần như ngẫu nhiên từ nhóm cổng có nhiều địa chỉ. Hướng dẫn này sẽ giải mã cả hai phần đó. Chúng ta sẽ xem xét lý do tại sao rất nhiều máy chủ cục bộ lại sử dụng một cổng như vậy, và sẽ xem xét sáu vấn đề có thể xảy ra trước khi kết nối được thiết lập. Sau khi hoàn thành, bạn sẽ biết cách liên kết một dịch vụ với giao diện phù hợp, xem những gì thực sự đang lắng nghe trên một cổng, khắc phục xung đột cổng và chặn tường lửa, và bảo mật máy chủ cục bộ trước khi kết nối với internet công cộng.
Ý nghĩa của địa chỉ 127.0.0.1:57573 trong tiếng Anh đơn giản
Gồm ba phần. Địa chỉ IP 127.0.0.1 là địa chỉ loopback IPv4. Dấu hai chấm cho biết "và trên cổng này". 57573 là chính cổng đó, nằm trong dải số cao mà không có dịch vụ nào được triển khai rộng rãi sở hữu vĩnh viễn.
Kết nối với nó và nhân hệ điều hành sẽ định tuyến gói tin thẳng trở lại máy cục bộ của bạn. Không cần card mạng. Không cần bộ chuyển mạch. Không cần truyền tải dữ liệu khứ hồi qua bất kỳ dây dẫn nào. Địa chỉ này cho phép một tiến trình giao tiếp với các tiến trình khác trên cùng một máy chủ mà không để lộ bất cứ thông tin nào ra mạng bên ngoài. Đó chính là mục đích của giao thức loopback.
Việc đặt trước địa chỉ này còn lâu đời hơn cả hầu hết các nhà phát triển sử dụng nó. RFC 1122, mục 3.2.1.3, đã loại bỏ toàn bộ khối địa chỉ 127.0.0.0/8, bao gồm tất cả 16.777.216 địa chỉ, khỏi mạng vĩnh viễn từ năm 1989. Cơ quan đăng ký địa chỉ chuyên dụng IPv4 của IANA, được điều chỉnh bởi RFC 6890 và cập nhật bởi RFC 8190, đánh dấu cùng khối địa chỉ này là không thể chuyển tiếp, không thể định tuyến toàn cầu, được dành riêng theo giao thức. Bất kỳ tiến trình nào lắng nghe trên 127.0.0.1 chỉ thấy lưu lượng truy cập từ máy chủ của chính nó. Bất kỳ thứ gì đến từ bên ngoài mà tuyên bố có địa chỉ nguồn là 127 đều bị loại bỏ một cách lặng lẽ. Những người làm trong ngành mạng gọi những gói tin đó là "người ngoài hành tinh".
localhost, cái tên này, chỉ đơn giản là tên máy chủ thân thiện với người dùng hơn, thể hiện cùng một ý tưởng. Mở `/etc/hosts` trên macOS hoặc Linux, hoặc `C:\Windows\System32\drivers\etc\hosts` trên Windows, và bạn sẽ thấy dòng này ở gần đầu: `127.0.0.1 localhost`.
Địa chỉ Loopback: Cách localhost định tuyến đến máy tính của bạn
127.0.0.1 là địa chỉ nổi tiếng nhất. Nhưng đó không phải là địa chỉ duy nhất. Toàn bộ khối 127.0.0.0/8, với hơn mười sáu triệu địa chỉ, đều có vòng lặp ngược. Bạn có thể ping 127.42.42.42 trên Linux. Nó hoạt động. Hầu hết chúng ta đều sử dụng 127.0.0.1 theo phản xạ, nhưng khối địa chỉ rộng hơn này lại quan trọng khi bạn đọc các quy tắc iptables hoặc kiểm tra một ảnh hệ thống được tăng cường bảo mật. (Đã có một bản dự thảo được lưu hành trong IETF trong nhiều năm đề xuất thu hồi phần lớn khối 127/8 để sử dụng cho unicast. Bản dự thảo này đã không được thông qua.)
Về phía IPv6 thì gọn nhẹ hơn. Chỉ có một địa chỉ, `::1`, được định nghĩa trong RFC 4291. Không có /8. Không có địa chỉ dự phòng. Nếu dịch vụ của bạn chỉ liên kết với `::1`, bất cứ thứ gì cố gắng truy cập 127.0.0.1 đều không nhận được gì, và ngược lại. Trên một máy Linux hiện đại và trên macOS, `localhost` được phân giải thành cả hai, vì vậy trình duyệt thường thử `::1` trước, thất bại, rồi mới chuyển sang địa chỉ khác. Bạn sẽ thấy điều này như một độ trễ nhỏ nhưng có thể nhận thấy. Cố định địa chỉ vào một địa chỉ duy nhất bên trong tập lệnh và sự mơ hồ sẽ biến mất.
Nhân hệ điều hành xử lý các gói tin loopback trên một giao diện ảo. Linux gọi nó là `lo`. macOS gọi nó là `lo0`. Các lệnh `ip link show` và `ifconfig lo0` sẽ hiển thị thông tin này. Cùng một hệ thống tường lửa kiểm soát mọi thứ khác cũng kiểm soát cả loopback, đó là lý do tại sao cấu hình tường lửa quá mạnh có thể làm gián đoạn lưu lượng truy cập cục bộ. Chúng ta sẽ tìm hiểu thêm về điều này trong các phần tiếp theo.
Tóm lại, đối với việc phát triển phần mềm: 127.0.0.1 là giao diện an toàn nhất để kết nối. Không có gì bên ngoài máy của bạn có thể truy cập được nó. Container và máy ảo có giao diện loopback riêng, tách biệt với máy chủ, đó là lý do khiến hầu hết các nhà phát triển gặp khó khăn khi lần đầu tiên kỳ vọng rằng 127.0.0.1 bên trong container Docker có thể tự động truy cập được một dịch vụ trên máy tính xách tay của họ.
Tại sao lại là cổng 57573? Giải thích về phạm vi số cổng của IANA.
Cổng 57573 không có gì đặc biệt. Hệ điều hành hoặc khung phần mềm đã chiếm dụng nó vì nó còn trống. Để hiểu tại sao một con số lớn như vậy lại xuất hiện thường xuyên, bạn cần xem xét cách IANA phân bổ không gian cổng 16 bit. Toàn bộ sơ đồ nằm trong RFC 6335 và Sổ đăng ký Tên dịch vụ và Số cổng giao thức vận chuyển của IANA.
| Phạm vi | Tên IANA | Ví dụ |
|---|---|---|
| 0–1023 | Cổng hệ thống / cổng thông dụng | 22 SSH, 80 HTTP, 443 HTTPS, 53 DNS |
| 1024–49151 | Cổng người dùng / đã đăng ký | 3306 MySQL, 5432 Postgres, 8080 alt-HTTP |
| 49152–65535 | Năng động / riêng tư / tạm thời | Được hệ điều hành tự động gán, chưa bao giờ được IANA đăng ký. |
49152–65535 là phạm vi được IANA khuyến nghị cho các cổng tạm thời. Tuy nhiên, các nhân hệ điều hành thực tế thường không đồng ý. Linux mặc định sử dụng phạm vi 32768–60999 (`sysctl net.ipv4.ip_local_port_range`). Windows từ Vista trở đi sử dụng 49152–65535. Thời kỳ XP sử dụng 1025–5000, một phạm vi hẹp khiến các cổng bị quá tải và gây ra các sự cố ngừng hoạt động nổi tiếng. macOS tuân thủ theo tiêu chuẩn IANA. Cổng 57573 nằm trong mọi phạm vi mặc định hiện đại. Chính điều đó giải thích phần lớn lý do tại sao nó lại xuất hiện trong nhật ký của nhà phát triển.
Khi mã của bạn thực hiện `app.run(port=0)` trong Flask, hoặc `server.listen(0)` trong Node, hệ điều hành sẽ chọn bất kỳ cổng nào còn trống trong phạm vi động cục bộ của nó. Trên máy tính xách tay Linux, điều đó có nghĩa là bất kỳ cổng nào từ 32768 đến 60999. Cổng 57573 nằm trong phạm vi này. Tương tự đối với các công cụ tự động gán cổng: Vite (đã cố tình mặc định là 127.0.0.1 vào năm 2022 để ngăn các nhà phát triển rò rỉ máy chủ trên wifi quán cà phê), webpack-dev-server, VS Code Live Server, Jupyter, các cầu nối trình điều khiển Selenium, Playwright, trình gỡ lỗi `--inspect=0` của Node. Tất cả chúng đều chỉ yêu cầu kernel cấp một cổng cao còn trống và sử dụng bất kỳ cổng nào được cấp.
Vì vậy, nếu cổng 57573 xuất hiện trong dấu vết ngăn xếp, câu trả lời nhàm chán hầu như luôn đúng. Hoặc là một tiến trình nào đó đã cố tình liên kết với cổng đó, hoặc một framework đã yêu cầu "bất kỳ cổng nào còn trống" và kernel đã chọn cổng này. Không có gì sai với số cổng 57573 cả. Hầu hết các framework thử nghiệm và phát triển cục bộ đều coi toàn bộ dải cổng cao là một môi trường an toàn, biệt lập, bởi vì không có dịch vụ công cộng nào phụ thuộc vào nó.
Liên kết máy chủ với 127.0.0.1 so với 0.0.0.0 so với ::1
Chọn sai mục tiêu liên kết sẽ dẫn đến các lỗi kỳ lạ. Có ba định nghĩa cần phân biệt rõ.
127.0.0.1 chỉ liên kết với giao diện loopback IPv4. Có thể truy cập được từ cùng một máy trên bất kỳ máy khách IPv4 nào. Không bao giờ truy cập được từ bên ngoài.
::1 chỉ liên kết với địa chỉ loopback IPv6. Ý tưởng tương tự, nhưng chỉ dành cho các máy khách IPv6 trên cùng một máy.
Địa chỉ 0.0.0.0 liên kết mọi giao diện IPv4 trên máy. Bất kỳ ai định tuyến đến máy của bạn đều có thể truy cập được, bao gồm cả điện thoại trên cùng mạng Wi-Fi, các thiết bị kết nối VPN và (với tính năng chuyển tiếp cổng) internet công cộng.
Đối với công việc phát triển hàng ngày, hãy liên kết với 127.0.0.1. Đây là giao diện duy nhất mà tường lửa, chính sách VPN và việc vô tình bị lộ thông tin không còn là vấn đề của bạn nữa. Flask, FastAPI, Express đều mặc định sử dụng giao diện này.
Theo kinh nghiệm của tôi, mọi người thường chuyển hướng đến địa chỉ 0.0.0.0 từ ba nguồn khác nhau. Thứ nhất là kiểm tra trên điện thoại qua mạng LAN. Thứ hai là kiểm tra bên trong Docker. Thứ ba là làm theo hướng dẫn mà tác giả sao chép sai cài đặt mặc định. Mỗi trường hợp đều có cách xử lý an toàn hơn. Đối với kiểm tra qua mạng LAN, hãy liên kết với địa chỉ IP cụ thể của mạng LAN và thêm quy tắc tường lửa tạm thời. Đối với Docker, hãy liên kết 0.0.0.0 bên trong container nhưng công bố trên máy chủ bằng lệnh `docker run -p 127.0.0.1:8080:8080 …`. Đối với các hướng dẫn, hãy bỏ qua dòng 0.0.0.0 và ghim địa chỉ vào 127.0.0.1 trừ khi bạn có lý do thực sự.
Một đoạn mã Flask đơn giản minh họa cách thiết lập mặc định an toàn:
```
from flask import Flask
ứng dụng = Flask(__tên__)
@app.route("/")
def index():
Trả về "Xin chào, localhost!"
nếu __name__ == "__main__":
app.run(host="127.0.0.1", port=57573)
```
Kiểm tra cổng 57573 bằng các lệnh netstat, lsof và ss.
Có thứ gì đó đang lắng nghe trên cổng 57573 và bạn không hề biết đó là gì. Lệnh này phụ thuộc vào hệ điều hành của bạn. Hãy ghi nhớ danh sách ngắn này và bạn sẽ sử dụng nó trong nhiều năm tới.
| Hệ điều hành / shell | Yêu cầu | Ghi chú | |
|---|---|---|---|
| Linux (hiện đại) | `ss -tlnp \ | grep :57573` | Thay thế lệnh netstat. Hiển thị tiến trình nếu bạn chạy với quyền root. |
| Linux (phiên bản cũ) | `netstat -tlnp \ | grep :57573` | net-tools có thể không được cài đặt trên các ảnh đĩa có dung lượng nhỏ. |
| macOS | `lsof -i :57573` | Tương tự trên Linux. Bao gồm cả tiến trình và người dùng. | |
| Lệnh cmd của Windows | `netstat -ano \ | findstr :57573` | Cột PID tương ứng với Trình quản lý tác vụ |
| Windows PowerShell | `Get-NetTCPConnection -LocalPort 57573` | Sạch hơn, có thể lập trình |
Kết quả đầu ra điển hình của Linux:
```
$ ss -tlnp | grep 57573
LISTEN 0 4096 127.0.0.1:57573 0.0.0.0:* users:(("python3",pid=18432,fd=4))
```
Sáu trường, từ trái sang phải. Trạng thái. Hàng đợi gửi. Hàng đợi nhận. Địa chỉ cục bộ. Địa chỉ đối tác. Tiến trình. PID 18432 trong trường hợp này. `kill 18432` trên Unix. `Stop-Process -Id 18432` trong PowerShell. Xong. Nếu tất cả những gì bạn muốn là khôi phục lại cổng, thì đó là toàn bộ cách khắc phục.
Nếu không có gì hiển thị thì sao? Điều đó có nghĩa là không có gì đang lắng nghe, và đó chính là thông tin hữu ích. Lỗi trình duyệt mà bạn thường thấy, "Kết nối bị từ chối," thường có nghĩa là như vậy. Máy chủ của bạn đã biến mất. Nó bị lỗi khi khởi động, hoặc nó chưa bao giờ liên kết với địa chỉ bạn đã nhập.
Các lỗi kết nối thường gặp và ý nghĩa của chúng
Sáu điều. Đó là toàn bộ danh sách các lỗi bạn thấy tại 127.0.0.1:57573. Hãy đọc chuỗi lỗi và chọn một nhóm lỗi.
`EADDRINUSE`, "Địa chỉ đã được sử dụng" hoặc "cổng 57573 đã được cấp phát" đều có cùng nghĩa. Một ứng dụng khác đang sử dụng cổng đó. Các lệnh kiểm tra từ phần trước sẽ cho bạn biết đó là ứng dụng nào. Hãy tắt nó đi, hoặc chỉ cần sử dụng một cổng khác cho dịch vụ của bạn. Các công cụ như netstat hoặc lsof sẽ hoàn thành việc này chỉ trong một dòng lệnh.
Thông báo `ECONNREFUSED`, hay còn gọi là "Kết nối bị từ chối" một cách thân thiện hơn, cho biết: TCP đã vào được nhân hệ điều hành, nhưng không có ai nhận cuộc gọi. Máy chủ của bạn đã chết khi khởi động hoặc chưa bao giờ được liên kết. Hãy xem cửa sổ terminal nơi bạn đã khởi chạy nó. Thông tin chi tiết về lỗi nằm ngay đó.
Lỗi `ETIMEDOUT` và "Connection timed out" có nghĩa là các gói dữ liệu đang biến mất một cách âm thầm. Trên 127.0.0.1, điều đó hầu như không bao giờ xảy ra. Khi nó xảy ra, nguyên nhân có thể là do quy tắc tường lửa, tác nhân VPN hoặc một số công cụ bảo vệ điểm cuối. Hãy tắt chúng từng cái một, thử lại, và lặp lại quy trình.
Lỗi `EACCES` ("Quyền truy cập bị từ chối") xuất hiện khi bạn cố gắng liên kết với cổng dưới 1024 mà không có quyền root. Hãy sử dụng cổng cao hơn như 57573, hoặc chạy tệp nhị phân với quyền root. Tùy chọn thứ ba không tồn tại.
Lỗi `EAI_NONAME` và các lỗi DNS khác có nghĩa là tên máy chủ chưa bao giờ được phân giải. Tệp hosts được cho là ánh xạ `localhost` tới 127.0.0.1. Một ứng dụng VPN có thể đã ghi đè lên nó. Quản trị viên hệ thống có thể đã cung cấp một ảnh hệ thống bị lỗi. Hãy mở tệp hosts. Xác nhận rằng `127.0.0.1 localhost` là dòng không phải là dòng chú thích đầu tiên.
Vấn đề cuối cùng, vấn đề khó phát hiện nhất. Sau khi tắt máy đúng cách, nhân hệ điều hành sẽ giữ socket ở trạng thái TIME_WAIT trong khoảng hai phút. Khởi động lại máy chủ nhanh chóng và bạn sẽ thấy thông báo "Địa chỉ đã được sử dụng" mặc dù không có ai đang lắng nghe. Có ba cách giải quyết: chờ đợi, thiết lập `SO_REUSEADDR` trong cấu hình bind của bạn, hoặc chỉ cần chuyển sang một cổng khác. Hầu hết chúng ta đều chọn cách chuyển cổng.
Đọc chuỗi lỗi. Chọn nhóm lỗi. Áp dụng bản sửa lỗi. Toàn bộ quy trình thường hoàn tất trong vòng chưa đầy một phút.
Các thiết lập tường lửa chặn cổng 57573
Về lý thuyết, lưu lượng truy cập vòng lặp luôn được cho phép. Tuy nhiên, trên thực tế, các quy tắc tường lửa đôi khi lại vi phạm điều này. Những thủ phạm thường gặp trong năm 2026:
- Thiết lập Tường lửa ứng dụng macOS với tùy chọn "Chặn kết nối đến" ở chế độ nghiêm ngặt. Thêm tệp nhị phân sở hữu cổng 57573 vào danh sách cho phép trong Cài đặt hệ thống → Mạng → Tường lửa.
- Lỗi không khớp cấu hình tường lửa Windows Defender. Một công cụ dành cho nhà phát triển mới yêu cầu bạn cho phép truy cập. Bạn theo phản xạ nhấn Hủy. Nó âm thầm chặn. Mở `wf.msc`, xóa quy tắc từ chối, và chấp nhận lời nhắc vào lần sau.
- Linux ufw hoặc iptables với các chính sách mặc định được thắt chặt. `ufw status verbose` liệt kê các quy tắc. `ufw allow from 127.0.0.1` mở giao diện loopback một cách rõ ràng. Hầu hết các bản phân phối mặc định đã cho phép `lo`, nhưng một số ảnh hệ thống được tăng cường bảo mật thì không.
- Một VPN doanh nghiệp hoặc tác nhân không tin cậy (zero-trust agent) đang chặn lưu lượng truy cập. Một số tác nhân này chuyển tiếp các kết nối cục bộ thông qua trình lắng nghe trong không gian người dùng và âm thầm làm biến đổi vòng lặp loopback. Hãy tắt tác nhân này trong một phút để xác nhận.
- Phần mềm diệt virus hoặc bảo vệ điểm cuối. Các sản phẩm EDR đôi khi chặn các tệp nhị phân dành cho nhà phát triển liên kết với các cổng có mức độ ưu tiên cao cho đến khi bạn thêm chúng vào danh sách cho phép.
Trong bất kỳ môi trường doanh nghiệp nào được quản lý, ít nhất một trong những lỗi này sẽ xảy ra. Quy trình chẩn đoán cũng tương tự: kiểm tra cài đặt tường lửa của bạn, sau đó chạy lệnh `curl http://127.0.0.1:57573` từ cùng một cửa sổ dòng lệnh đã khởi động máy chủ. Nếu lệnh `curl` hoạt động nhưng trình duyệt lại không hoạt động? Bạn đang truy cập sai giao diện (thường là `::1` thay vì 127.0.0.1) hoặc chính sách Truy cập Mạng Riêng (Private Network Access) đang được áp dụng. Nếu lệnh `curl` cũng không hoạt động? Nhân hệ điều hành hoặc tường lửa đang chặn gói tin trước khi nó đến được mã của bạn. Các nhà phát triển web và quản trị viên mạng thường trao đổi những mẹo này trên các trang wiki nội bộ vì các triệu chứng trông giống hệt nhau cho đến khi bạn gặp phải chúng hai lần.
Máy chủ cục bộ trong Docker, WSL và GitHub Codespaces
Ba vị trí mà localhost ngừng hoạt động như bạn mong đợi.
Trước tiên là Docker. Bên trong container, 127.0.0.1 là địa chỉ loopback của container , chứ không phải của bạn. Vì vậy, nếu máy tính xách tay của bạn chạy một dịch vụ trên 127.0.0.1:57573, container không thể truy cập được dịch vụ đó bằng cùng địa chỉ này. Tuyệt đối không bao giờ. Cổng mặc định của máy chủ nằm ở nơi khác: `host.docker.internal` trên Mac và Windows, hoặc một địa chỉ IP cầu nối nào đó trên Linux. Chiều ngược lại (dịch vụ trong container, máy chủ gọi) cần một cờ `-p`. Ví dụ: `docker run -p 127.0.0.1:57573:57573 my-image`. Bỏ cờ `-p` đi thì cổng đó đơn giản là không tồn tại bên ngoài container.
WSL2 có những đặc điểm riêng. Chế độ mạng phản chiếu (tùy chọn trên Windows 11 22H2 trở lên, thông qua `[wsl2] networkingMode=mirrored`) chia sẻ ngăn xếp mạng của máy chủ với máy ảo WSL. Ở chế độ đó, một dịch vụ trên 127.0.0.1:57573 bên trong WSL sẽ trả lời trên Windows tại cùng một địa chỉ. Chế độ NAT mặc định vẫn chuyển tiếp cổng, nhưng chỉ cho chuỗi `localhost`, không phải lúc nào cũng cho địa chỉ thực 127.0.0.1. Ngoài ra còn có một lỗi nghiêm trọng đã biết ở đây, được theo dõi là Microsoft WSL #40169. Chế độ phản chiếu âm thầm khóa một lượng lớn các cổng có địa chỉ cao. Các nỗ lực liên kết trên 127.0.0.1 sau đó sẽ thất bại với `WinError 10013`, mà Python báo cáo một cách hữu ích là `PermissionError`. Khi một cổng từ chối liên kết trên Windows mà không có lý do rõ ràng, hãy kiểm tra điều này trước tiên.
GitHub Codespaces và VS Code Remote SSH hoạt động theo chiều ngược lại. Chúng tự động chuyển tiếp cổng của bạn. Khởi động một máy chủ bên trong Codespace trên 127.0.0.1:57573 và trình soạn thảo sẽ mở một đường hầm cho bạn, hiển thị cổng đó tại một URL github.dev duy nhất. Tab trình duyệt bạn mở trên máy tính xách tay sẽ giao tiếp với URL đó, chứ không phải 127.0.0.1, và yêu cầu sẽ đi qua đường hầm trở lại không gian làm việc.
Vì vậy, tên điểm cuối trông có vẻ giống nhau. Tuy nhiên, đường đi thực tế của gói tin lại hoàn toàn khác nhau trong mỗi môi trường. Chỉ cần dành năm phút để tìm hiểu bạn đang ở trong môi trường nào sẽ giúp bạn tiết kiệm được hai mươi phút nhìn chằm chằm vào thông báo "kết nối bị từ chối".
HTTPS trên máy chủ cục bộ: Các phương pháp tốt nhất để phát triển cục bộ an toàn
Các trình duyệt hiện đại và rất nhiều API yêu cầu HTTPS ngay cả khi phát triển cục bộ. Service worker. Định vị địa lý. API clipboard. Bất kỳ cookie nào được đánh dấu là `Secure`. Tất cả đều từ chối hoạt động trên HTTP thông thường. Có một ngoại lệ: 127.0.0.1, mà trình duyệt đã coi là một ngữ cảnh an toàn. Ngoại lệ này bao gồm hầu hết các nhà phát triển thông thường. Đối với mọi thứ khác, hãy chạy TLS cục bộ.
Công cụ sạch nhất, vượt trội hơn hẳn so với các công cụ khác, là mkcert, được viết bởi Filippo Valsorda. Chạy nó một lần với lệnh `mkcert -install`, sau đó `mkcert localhost 127.0.0.1 ::1`, và bạn sẽ nhận được chứng chỉ `localhost+2.pem` cùng với khóa. Trỏ máy chủ phát triển của bạn đến cặp này. Trình duyệt sẽ hiển thị biểu tượng khóa sạch mà không có cảnh báo nào, bởi vì mkcert đã cài đặt một CA gốc cục bộ vào hệ thống của bạn và kho lưu trữ tin cậy của Firefox. Let's Encrypt không thể cấp chứng chỉ thực sự cho `127.0.0.1`, vì không có tên miền nào để xác thực, vì vậy CA cục bộ là giải pháp tiêu chuẩn.
Một vài mô hình khác đáng chú ý:
- Đối với các bài kiểm tra tự động, hãy trỏ đến một dịch vụ DNS ảo (`nip.io`, `sslip.io`, `traefik.me`, `localhost.direct`) để chuyển đổi địa chỉ IP thành tên máy chủ thực sự như `127.0.0.1.nip.io`. Let's Encrypt hoặc ZeroSSL có thể cấp chứng chỉ cho các tên máy chủ này, và `localhost.direct` thậm chí còn cung cấp chứng chỉ ký tự đại diện được cấp trước.
- Hãy liên kết dịch vụ của bạn với 127.0.0.1, chứ không phải 0.0.0.0, để chứng chỉ (bao gồm `127.0.0.1`) thực sự khớp.
- Hãy giữ các chứng chỉ nhà phát triển (dev certs) tách biệt khỏi Git. Theo mặc định, mkcert sẽ lưu chúng vào thư mục làm việc của bạn. Hãy thêm cặp chứng chỉ này vào `.gitignore` ngay lập tức.
- Hãy xoay vòng chứng chỉ CA cục bộ vài tháng một lần. Lệnh `mkcert -uninstall` sẽ xóa nó đi.
- Nếu bạn đang sử dụng máy chủ proxy MITM của công ty, hãy chấp nhận rằng proxy sẽ thay đổi chứng chỉ của bạn. Vô hiệu hóa proxy trên `127.0.0.1` nếu công cụ của bạn hỗ trợ.
Trình duyệt cũng có một quy tắc đặc biệt đáng biết. Theo đặc tả W3C Secure Contexts, `http://127.0.0.1`, `http://localhost` và `http://[::1]` được coi là "có khả năng đáng tin cậy", cho phép trang HTTPS tải chúng mà không kích hoạt chặn nội dung hỗn hợp. Ngoại lệ này dành riêng cho việc phát triển cục bộ.
localhost không phải là ranh giới bảo mật theo cách mà các nhà phát triển thường giả định. Trình duyệt có thể bị đánh lừa để truy cập vào đó từ các trang web tùy ý thông qua việc tái liên kết DNS, trong đó một trang web độc hại phân giải lại tên máy chủ của nó thành 127.0.0.1 và cho phép JavaScript trên trang của kẻ tấn công giao tiếp với các dịch vụ cục bộ dưới nguồn gốc của trang web ban đầu. Lỗ hổng bảo mật Zoom năm 2019 (CVE-2019-13450) là trường hợp điển hình. Zoom đã cài đặt một máy chủ web ẩn trên `localhost:19421` trên macOS để các liên kết cuộc họp có thể khởi chạy ứng dụng máy tính để bàn và bất kỳ trang web nào cũng có thể truy cập từ đó để buộc người dùng tham gia cuộc họp với camera đang bật. Khoảng 4 triệu máy Mac đã bị ảnh hưởng, cộng thêm mười ba ứng dụng khách nhãn trắng được phân phối trên cùng một công cụ. Chrome 142, được phát hành vào cuối năm 2025, đã thay thế nỗ lực Truy cập Mạng Riêng tư cũ bằng Truy cập Mạng Cục bộ. Các trang công khai hiện cần một lời nhắc cấp quyền rõ ràng trước khi chúng có thể truy cập vào các địa chỉ loopback hoặc địa chỉ riêng tư, điều này loại bỏ hầu hết các thủ đoạn mà Singularity của NCC Group đã tự động hóa. Một báo cáo tư vấn của Straiker năm 2025 đã ghi nhận cùng một cuộc tấn công nhắm vào các máy chủ Giao thức Ngữ cảnh Mô hình (Model Context Protocol) chạy cục bộ, và đây đang trở thành một lỗ hổng bảo mật ngày càng gia tăng khi các nhà phát triển chạy nhiều tác nhân LLM hơn trên giao diện loopback. Hãy ràng buộc chặt chẽ với 127.0.0.1, yêu cầu xác thực, kiểm tra tiêu đề `Origin` và tránh sử dụng CORS ký tự đại diện trên các API dành cho nhà phát triển. Bốn thói quen này sẽ giúp ngăn chặn hầu hết các cuộc tấn công như vậy.
Mẹo khắc phục sự cố và danh sách kiểm tra chẩn đoán nhanh
Khi 127.0.0.1:57573 không trả lời, hãy kiểm tra danh sách ngắn này trước khi nghi ngờ có điều gì đó bí ẩn hơn.
1. Hãy xác nhận máy chủ đang thực sự hoạt động. Kiểm tra cửa sổ terminal nơi bạn khởi chạy nó. Nếu nó bị lỗi, dấu vết ngăn xếp sẽ hiển thị ngay đó.
2. Hãy xác nhận nó được liên kết với 127.0.0.1, chứ không phải 0.0.0.0 hoặc chỉ ::1. Hầu hết các framework đều in địa chỉ liên kết khi khởi động. Hãy đọc dòng đó.
3. Hãy thử lệnh `curl -v http://127.0.0.1:57573` từ cùng một cửa sổ dòng lệnh. Lệnh `curl` có hoạt động không? Vấn đề nằm ở trình duyệt, không phải ở máy chủ.
4. Tìm hiểu xem ai sở hữu cổng đó. Linux, dùng lệnh `ss -tlnp | grep :57573`. macOS, dùng lệnh `lsof -i :57573`. Windows, dùng lệnh `netstat -ano | findstr :57573`.
5. Có tiến trình không đúng đang sở hữu nó? Hãy kết thúc tiến trình đó, sau đó khởi động lại máy chủ.
6. Không có gì lắng nghe cả? Hãy xem nhật ký khởi động. `EACCES` nghĩa là cổng có quyền ưu tiên. `EADDRINUSE` thường có nghĩa là TIME_WAIT đã lỗi thời.
7. Hãy thử định dạng IPv6. `curl http://[::1]:57573`. Nếu một trong hai địa chỉ `127.0.0.1` hoặc `::1` hoạt động và địa chỉ còn lại không, thì dịch vụ của bạn chỉ hỗ trợ một ngăn xếp IPv6.
8. Thử một cổng khác: truyền tham số `--port 12345` (hoặc bất kỳ tham số nào khác) và tải lại. Cổng mới hoạt động? Có thể bạn đang gặp xung đột cổng cụ thể.
9. Tắt VPN, phần mềm diệt virus và các tác nhân bảo vệ điểm cuối trong một phút. Nếu cổng 57573 bắt đầu phản hồi, nghĩa là một trong số chúng đã chiếm dụng lưu lượng truy cập.
10. Khởi động lại, hoặc ít nhất là khởi động lại giao diện mạng. Gần như không bao giờ là giải pháp. Nó chỉ giúp xóa các socket cũ và trạng thái tường lửa bị kẹt khi không có cách nào khác hiệu quả.
Đối với hầu hết các sự cố phát triển phần mềm, bốn bước khắc phục sự cố đầu tiên sẽ giúp tìm ra nguyên nhân gây ra lỗi kết nối. Các bước còn lại sẽ giải quyết những trường hợp thực sự kỳ lạ, chẳng hạn như lỗi không tương thích IPv6, socket cũ hoặc lớp tường lửa độc hại đang che giấu lỗi thực sự. Hãy đọc thông báo lỗi, sau đó làm theo danh sách các bước.
Một lưu ý liên quan đến Plisio. Khi bạn tích hợp webhook của bộ xử lý thanh toán tiền điện tử, cổng thanh toán cần một URL công khai mà nó có thể gửi yêu cầu POST. Hóa đơn Plisio chấp nhận `callback_url` trong tải trọng API và hệ thống gửi các bản cập nhật trạng thái POST đến điểm cuối đó. Máy chủ cục bộ của bạn tại 127.0.0.1:57573 không thể truy cập được từ internet công cộng theo định nghĩa, vì vậy giải pháp thay thế thông thường là sử dụng đường hầm (tunnel). Vào năm 2026, các lựa chọn phổ biến là ngrok (Cá nhân $8/tháng, Pro $20/tháng), Cloudflare Tunnel (miễn phí cho tối đa 50 người dùng trên Zero Trust) và Tailscale Funnel (miễn phí cho sử dụng cá nhân, trả phí cho nhóm từ $6/người dùng/tháng). Mỗi dịch vụ đều sử dụng một tên máy chủ công khai và chuyển tiếp lưu lượng truy cập đến máy tính xách tay của bạn tại 127.0.0.1:57573. Các SDK Python, PHP và Node của Plisio đều tích hợp hàm hỗ trợ `validate_callback` để xác minh hàm băm HMAC-SHA1 `verify_hash` trên phần thân JSON đã được sắp xếp, vì vậy sau khi đường hầm được thiết lập, cùng một trình xử lý sẽ hoạt động giống hệt nhau trong môi trường phát triển và sản xuất.
