127.0.0.1:49342: Hướng dẫn gỡ lỗi và địa chỉ IP, cổng và máy chủ cục bộ

Có thể bạn đã nhấp chuột vào thứ gì đó. Có thể một cửa sổ terminal đã lướt qua. Có thể một tệp nhật ký nào đó đã thu hút sự chú ý của bạn. Dù là trường hợp nào, chuỗi ký tự này đã xuất hiện: `127.0.0.1:49342`. Trình duyệt của bạn đã nhảy đến một trang không tồn tại trên internet. Công cụ dành cho nhà phát triển đã cảnh báo về điều này. Một cửa sổ đăng nhập bật lên rồi biến mất. Không có gì bị lỗi rõ ràng. Tuy nhiên, vẫn có điều gì đó không ổn.

Đừng lo, không có gì hỏng cả. Chuỗi ký tự nhỏ đó thực ra là một trong những thứ phổ biến nhất mà bạn sẽ thấy khi sử dụng máy tính, và ngay khi bạn hiểu được hai phần của nó, mọi chuỗi `127.0.0.1:` trong tương lai sẽ đọc như một câu bình thường. Địa chỉ IP bên trái là địa chỉ loopback phổ quát, giống nhau trên mọi máy tính bạn sử dụng. Cổng bên phải chỉ là một cổng cụ thể mà hệ điều hành cấp cho một dịch vụ cục bộ, một ứng dụng web hoặc một số dịch vụ mạng để giao tiếp ngắn gọn giữa các chương trình chạy trên phần cứng của bạn. Không có gì trong số đó kết nối với mạng bên ngoài. Tất cả đều nằm trên chiếc máy tính trước mặt bạn.

Vậy đây là kế hoạch. Một bài giải thích kèm theo một hướng dẫn khắc phục sự cố, được ghép lại với nhau. Địa chỉ này xuất phát từ lịch sử. Số cổng thực sự đại diện cho điều gì. Tại sao cổng 49342, cụ thể, lại không có gì đặc biệt cả. Khi nào người dùng Windows nhìn thấy nó so với người dùng Linux hoặc macOS. Tình hình bảo mật sẽ như thế nào vào năm 2026. Cách các nhà phát triển mật mã sử dụng cùng một mẫu trong môi trường phát triển Web3 với Hardhat, Anvil, Ganache và Bitcoin Core. Hãy đọc từ đầu đến cuối, hoặc nhảy thẳng đến bất kỳ phần nào phù hợp với nội dung bạn đang tìm kiếm.

Địa chỉ 127.0.0.1 là gì: Giải thích về địa chỉ Loopback

Hãy xem xét phần địa chỉ IP trước. 127.0.0.1 còn lâu đời hơn hầu hết các địa chỉ IP bạn sử dụng trực tuyến hiện nay. Vào tháng 10 năm 1989, rất lâu trước khi có bất kỳ dịch vụ web thương mại nào, IETF đã ban hành RFC 1122. Nằm trong Mục 3.2.1.3 là một trong những quy tắc rõ ràng nhất về mạng máy tính từng được ghi lại: "Các địa chỉ có dạng này KHÔNG ĐƯỢC xuất hiện bên ngoài máy chủ." Hệ điều hành trên điện thoại của bạn vẫn thực thi quy tắc này. Bộ định tuyến tại nhà của bạn cũng vậy. Mọi hệ điều hành được phát hành kể từ đó đều âm thầm tuân thủ nó.

Vấn đề về quy mô khiến mọi người bối rối. Quy tắc đó áp dụng cho 16.777.216 địa chỉ. Tất cả chúng. Mười sáu triệu địa chỉ được giữ lại để một trong số đó, 127.0.0.1, có thể được hiểu một cách đáng tin cậy là "máy này, ngay tại đây" ở bất cứ đâu trên Trái đất. Có hơi lãng phí không? Đúng vậy, những lời phàn nàn đã vang lên trong nhiều thập kỷ. Kho địa chỉ IPv4 toàn cầu của IANA đã cạn kiệt vào ngày 3 tháng 2 năm 2011. ARIN cũng cạn kiệt vào ngày 24 tháng 9 năm 2015. RIPE NCC đã phân phối khối /22 cuối cùng của mình vào ngày 25 tháng 11 năm 2019. Một bản dự thảo của IETF có tên `draft-schoen-intarea-unicast-127` đã được đưa ra, đề xuất rằng phần lớn không gian 127 thực sự có thể được quay trở lại sử dụng unicast. Không ai muốn động đến điều đó. Quá nhiều phần mềm hiện có giả định rằng 127 sẽ không bao giờ thay đổi.

Một điều luôn khiến người mới ngạc nhiên: gói dữ liệu thực sự không bao giờ đến được card mạng vật lý. Thậm chí còn không đến gần. Một gói dữ liệu hướng đến bất kỳ đích nào có địa chỉ 127.xxx sẽ được ngăn xếp TCP/IP của hệ điều hành bắt giữ ở lớp 3 và đẩy qua một giao diện ảo (Linux và macOS gọi nó là `lo`). Nhân hệ điều hành vẫn thực hiện công việc thực sự — xây dựng phân đoạn TCP, chạy kiểm tra tổng, duyệt đường dẫn nhận. Có chi phí thực tế, không phải bằng không. Nhưng không có bộ chuyển mạch nào trên mạng LAN của bạn nhìn thấy lưu lượng truy cập đó. Không có bộ định tuyến nào nhìn thấy nó. Không có đường trục internet nào nhìn thấy nó.

Từ "localhost" chỉ là một bí danh thân thiện với người dùng được ánh xạ trong một tệp văn bản thuần túy mà bạn có thể mở ngay bây giờ. Trên Linux và macOS: `/etc/hosts`. Trên Windows: `C:\Windows\System32\drivers\etc\hosts`. Trình phân giải sẽ truy cập tệp đó trước khi hỏi bất kỳ máy chủ DNS nào, đó là lý do tại sao `localhost` được phân giải tốt trên máy bay khi tắt wifi. IPv6 có phiên bản riêng của nó, `::1/128`, được định nghĩa bởi RFC 4291 vào tháng 2 năm 2006. Một vấn đề đau đầu kinh điển vào thứ Sáu: một trình duyệt hiện đại phân giải `localhost` thành `::1` trước, nhưng ứng dụng Python chỉ liên kết với 127.0.0.1. Các socket khác nhau, không có giao điểm, lỗi âm thầm. Làm gián đoạn công việc của ai đó mỗi tuần ở đâu đó.

Tại sao bạn thấy Cổng 49342: Các cổng tạm thời và phạm vi IANA

Giờ đến phần thứ hai. Số cổng gây nhầm lẫn cho mọi người nhiều hơn địa chỉ IP, và điều đó cũng dễ hiểu. Sổ đăng ký cổng giao thức vận chuyển và tên dịch vụ của IANA chia toàn bộ không gian 16 bit (từ 0 đến 65535) thành ba nhóm, và việc cổng 49342 thuộc nhóm nào mới là điều quan trọng nhất.

Cổng 49342 nằm trong phạm vi cổng động. Không có gì được "đăng ký" cho cổng này, và sẽ không bao giờ có, bởi vì IANA từ chối gán các dịch vụ trong phạm vi này chính xác là để các hệ điều hành có thể tự do cấp phát số cổng ở đây để sử dụng tạm thời. Cổng tạm thời là một cổng được gán động mà ứng dụng không yêu cầu bằng một số cổng cụ thể. Nó nói với hệ điều hành, "hãy cho tôi bất kỳ cổng nào còn trống, tôi chỉ cần nó cho phiên này." Hệ điều hành trả về 49342, ứng dụng liên kết một socket lắng nghe, và bất kỳ luồng nào cần một địa chỉ và cổng có thời gian tồn tại ngắn đều được cấp. Cổng 49342 thường được sử dụng cho máy chủ cục bộ tạm thời bằng cách sử dụng liên kết ad-hoc kiểu này.

Phạm vi thời gian tạm thời mặc định thực tế có thể khác nhau tùy thuộc vào hệ điều hành.

Trên Windows hoặc macOS, địa chỉ 49342 nằm gọn trong phạm vi mặc định. Trình cấp phát của hệ điều hành gần như chắc chắn đã cấp phát nó. Trên Linux thì khác — 49342 nằm trên phạm vi mặc định từ 32768 đến 60999, vì vậy nó được chọn bởi một ứng dụng yêu cầu kernel `bind(('127.0.0.1', 0))` và nhận được bất kỳ địa chỉ nào còn trống. RFC 6056, được IETF thông qua vào tháng 1 năm 2011, hướng dẫn các ngăn xếp lựa chọn ngẫu nhiên các cổng tạm thời trên toàn bộ phạm vi từ 1024 đến 65535 vì lý do bảo mật. Các cổng có thể dự đoán được khiến việc chiếm quyền điều khiển luồng dễ dàng hơn. Đó là lý do tại sao cùng một máy chủ phát triển có thể sử dụng cổng 49342 hôm nay, 54871 ngày mai và 33200 ngày kia.

Vị trí hiển thị của 127.0.0.1:49342 trên máy tính của bạn

Vậy trường hợp này thường xuất hiện trong cuộc sống hàng ngày như thế nào? Một máy chủ cục bộ chạy trên cổng 49342 có thể là bất cứ thứ gì, thuộc danh mục dài các công cụ dành cho nhà phát triển, nơi họ kiểm tra ứng dụng với một socket loopback cục bộ. Bảng dưới đây bao gồm các trường hợp thường gặp khi các cổng như 49342 xuất hiện, với các dịch vụ đang chạy và chấp nhận kết nối trên cổng được chỉ định mỗi lần.

Trường hợp duy nhất khiến địa chỉ `127.0.0.1:49342` xuất hiện trực tiếp trên thanh địa chỉ trình duyệt? Hầu như luôn là do OAuth. Tài liệu RFC 8252 của IETF, có tiêu đề "OAuth 2.0 cho ứng dụng gốc", được ban hành vào tháng 10 năm 2017, hướng dẫn các ứng dụng gốc sử dụng luồng chuyển hướng loopback, với một quy tắc bất di bất dịch: máy chủ ủy quyền "PHẢI cho phép bất kỳ số cổng nào". Hãy chạy lệnh `gh auth login` hoặc `gcloud auth login`. Giao diện dòng lệnh (CLI) sẽ khởi tạo một máy chủ HTTP nhỏ trên một cổng tạm thời ngẫu nhiên, gửi yêu cầu đến nhà cung cấp danh tính thông qua trình duyệt, bắt phản hồi trên địa chỉ loopback đó và tự tắt. Bạn sẽ thấy một trong các địa chỉ localhost như 127.0.0.1:49342 nhấp nháy trong khoảng hai giây trước khi biến mất. Không phải lỗi. Không phải trình theo dõi. Không phải lừa đảo. Chỉ là một quá trình bắt tay rất ngắn, hoàn toàn cục bộ, không bao giờ kết nối với mạng bên ngoài.

Khắc phục sự cố lỗi 127.0.0.1:49342 và xung đột cổng

Theo kinh nghiệm của tôi, nỗi khổ khi sử dụng localhost có năm loại. Nói một cách đơn giản, bất cứ điều gì khiến bạn phải tìm kiếm giải pháp lúc 11 giờ đêm đều thuộc một trong năm loại này.

Cổng đã được sử dụng. Node báo lỗi `EADDRINUSE`. Python trả về `OSError: [Errno 98] Address already in use`, trông khá khó coi. Windows chỉ nhấp nháy `WinSock 10048` rồi biến mất. Thực tế cơ bản trong mọi trường hợp đều giống nhau: một tiến trình khác trên máy của bạn đã chiếm cổng 49342 trước. Nhiệm vụ của bạn là tìm ra nó, kết thúc nó và giành lại cổng đó.

• Trên Linux: `ss -tulpn | grep :49342`, hoặc sử dụng lệnh cũ `sudo lsof -i :49342`.
• Trên máy Mac: `lsof -nP -iTCP:49342 -sTCP:LISTEN`
• Trên Windows trong PowerShell: `netstat -ano | findstr :49342`, sau đó `tasklist /fi "PID eq "` để chuyển PID đó thành tên chương trình.

Máy chủ đang chạy, nhưng không thể kết nối. Bạn gặp lỗi này nhiều hơn bạn nhớ. IPv4 và IPv6 đã âm thầm xung đột với nhau. Máy chủ của bạn tự liên kết với 127.0.0.1. Trình duyệt của bạn phân giải `localhost` thành `::1` mà không có lý do gì cả. Chúng là hai socket khác nhau, vì vậy tất nhiên là không thể kết nối. Khắc phục bằng cách liên kết cả hai họ địa chỉ cùng một lúc (lắng nghe trên `::` thường bắt được các địa chỉ được ánh xạ IPv4 trên hầu hết các ngăn xếp) hoặc chỉ cần viết trực tiếp 127.0.0.1 vào URL.

VPN thường xuyên gây ra hiện tượng nghẽn đường truyền loopback. Cloudflare WARP là thủ phạm hàng đầu. Chính Cloudflare cũng thừa nhận điều này trên trang tài liệu về các hạn chế đã biết của họ: cụ thể trên macOS, việc ngắt kết nối WARP có thể xóa thẳng tuyến đường 127.0.0.1. Nếu localhost của bạn bị mất kết nối ngay sau khi bạn bật/tắt VPN, thì gần như chắc chắn đó là lý do. Hãy kết nối lại WARP, hoặc khôi phục tuyến đường bằng tay với lệnh `sudo ifconfig lo0 127.0.0.1 alias`. Proton VPN, Mullvad và NordVPN hầu như không bao giờ gây ra hiện tượng này, dù điều đó có ý nghĩa gì đi nữa. Các sản phẩm chống virus và EDR dành cho doanh nghiệp lại là một câu chuyện khác; một số trong số chúng chặn và chuyển tiếp lưu lượng loopback theo những cách rất kỳ lạ.

HSTS vẫn ghi nhớ các bài kiểm tra HTTPS mà bạn đã quên. Vài tháng trước, bạn đã kiểm tra chứng chỉ tự ký trên `localhost`. Chrome đã làm điều mà Chrome vẫn thường làm và lưu trữ tiêu đề HSTS. Giờ đây, mọi yêu cầu `http://localhost` thông thường đều tự động chuyển hướng sang https. Thật thú vị khi gỡ lỗi. Cách khắc phục chỉ mất hai phút: mở `chrome://net-internals/#hsts` và xóa mục đó đi.

Các quy tắc tường lửa. Theo mặc định, kết nối vòng lặp (loopback) thường vượt qua hầu hết các tường lửa. Hầu hết thôi. Một số ảnh hệ điều hành dành cho máy tính xách tay của doanh nghiệp cố tình lọc localhost như một phần của biện pháp ngăn chặn phần mềm độc hại, và bạn chỉ phát hiện ra điều này vào cuối một ngày thứ Năm dài. Kiểm tra các quy tắc đến nâng cao của tường lửa Windows Defender là nơi cần thiết. Trên Linux, sử dụng lệnh `sudo ufw status verbose`. Nếu thực sự cần mở một cổng nào đó, chỉ cho phép cổng cụ thể đó; đừng đóng toàn bộ tường lửa.

Tuy nhiên, có một thói quen luôn cứu nguy cho tôi. Trước khi thay đổi bất kỳ quy tắc tường lửa hay tuyến đường nào, tôi luôn chạy lệnh `lsof` hoặc `netstat`. Một nửa số lần gặp phải vấn đề là do một tiến trình "ma" đang cố giữ cổng từ một lần chạy thử nghiệm bị lỗi trước đó trong ngày. Hãy dùng lệnh `kill -9` để tiêu diệt tiến trình đó. Vấn đề sẽ được giải quyết trong vài giây.

Thiết lập cấu hình máy chủ và localhost cho mục đích phát triển

Thay vì tập trung vào gỡ lỗi, bạn nên xây dựng hệ thống? Hãy học một vài thói quen cấu hình máy chủ và bạn sẽ tiết kiệm được rất nhiều thời gian. Tất cả những điều này không hề phức tạp. Chúng ta đang hướng đến một mục tiêu đơn giản: kiểm thử và gỡ lỗi đáng tin cậy trên nhiều dịch vụ mạng và các dịch vụ khác nhau trên cùng một máy tính xách tay, chỉ vậy thôi.

Quy tắc đầu tiên, quy tắc nhàm chán nhất: hãy liên kết với `127.0.0.1`, chứ không phải `0.0.0.0`. Nếu bạn lắng nghe trên `0.0.0.0`, máy chủ web nhỏ của bạn đột nhiên sẽ tự quảng cáo trên mọi giao diện mạng mà bạn sở hữu. Điều đó có nghĩa là: người ngẫu nhiên ở bàn bên cạnh trên wifi quán cà phê sẽ tìm thấy nó. Liên kết với 127.0.0.1 và chỉ những thứ đã có sẵn trên máy của bạn mới được truy cập. `http.server` của Python, `express.listen()` của Node, `http.ListenAndServe` của Go — tất cả đều chấp nhận địa chỉ IP trực tiếp. Chỉ cần gõ nó vào là được.

Quy tắc thứ hai: khi bạn thực sự không quan tâm đến cổng nào, đừng chọn. Truyền cổng 0 cho trình lắng nghe (`server.listen(0)` trên Node, `bind(('127.0.0.1', 0))` trên Python) và kernel sẽ trả về bất kỳ cổng nào đang rảnh tại thời điểm đó. Sau đó gọi `getsockname()` để biết bạn thực sự nhận được gì và chuyển nó cho bất kỳ thành phần nào cần URL. Về cơ bản, mọi CLI OAuth và mọi bộ điều hợp gỡ lỗi mà bạn từng sử dụng đều làm chính xác điều này.

Quy tắc thứ ba: sử dụng biến môi trường, không phải mã hóa cứng cổng. Lấy `PORT` từ biến môi trường, nếu thiếu thì dùng một giá trị hợp lý. Cùng một tập tin nhị phân chạy trên môi trường phát triển tại 127.0.0.1:5173 và môi trường sản xuất phía sau máy chủ proxy ngược tại cổng 443. Áp dụng cùng một mẫu cho chuỗi cơ sở dữ liệu, khóa API, và tất cả mọi thứ khác. Tài liệu về Ứng dụng Mười Hai Yếu Tố (Twelve-Factor App) còn lâu đời hơn cả một số đồng nghiệp của bạn, nhưng nó vẫn là cách tiết kiệm nhất để tránh sự cố ngừng hoạt động.

Quy tắc thứ tư: HTTPS trên localhost không còn là vấn đề khó khăn nữa. Cả Chrome và Firefox hiện đều cấp trạng thái Ngữ cảnh Bảo mật cho `localhost` và `127.0.0.1` đối với hầu hết các tính năng, ngay cả khi không có chứng chỉ thực. Thư viện nào đó vẫn từ chối chứng chỉ tự ký? Hãy sử dụng `mkcert`, vẫn là CA cục bộ ít gây khó chịu nhất hiện nay. Các công cụ tích hợp sẵn như `http.server` của Python và mô-đun `net` của Node cho phép bạn thiết lập máy chủ cục bộ chỉ với khoảng năm dòng mã trong quá trình phát triển cục bộ, điều này cho phép các nhà phát triển kiểm tra ứng dụng web dưới tải thực tế bằng cách tái sử dụng các tập lệnh tương tự cho các bài kiểm tra tích hợp, nơi chỉ cần các dịch vụ giao tiếp qua vòng lặp là đủ.

Quy tắc cuối cùng, và thực sự là quy tắc quan trọng nhất. Môi trường sản xuất không phải là cục bộ. Chấm hết. Máy tính cục bộ của bạn là ranh giới tin cậy; container sản xuất thì không. Không bao giờ để các điểm cuối gỡ lỗi chạy trên 127.0.0.1 bên trong container sản xuất, bởi vì các tiến trình khác trong cùng container đó sẽ truy cập chúng ngay từ ngày đầu tiên, và chỉ cần một lỗi đột phá trong quá trình chạy, kẻ tấn công cũng có thể xâm nhập. Chỉ sử dụng lưu lượng truy cập localhost ở nơi thực sự phù hợp, được sử dụng trong môi trường phát triển và không ở nơi nào khác, và ngay khi bất kỳ API nội bộ nào sử dụng cổng đó được chuyển sang môi trường dùng chung hoặc môi trường sản xuất, hãy đặt xác thực thực sự ngay lập tức. Không có chuyện "chúng tôi sẽ sửa lỗi sau khi ra mắt". Đó là cách làm của công ty trước đây.

Sử dụng cổng 49342 một cách an toàn: Bảo mật trên địa chỉ Loopback

Localhost mang lại cảm giác riêng tư. Và đúng là như vậy, phần lớn thời gian. Cho đến khi đột nhiên nó không còn riêng tư nữa.

Đây là điểm yếu mà ai cũng gặp phải. Kẻ tấn công bên ngoài không thể gọi trực tiếp đến 127.0.0.1, điều đó đúng. Nhưng chúng hoàn toàn có thể đánh lừa trình duyệt của bạn , hoặc một ứng dụng nào đó trên máy tính mà bạn đã tin tưởng, để thực hiện cuộc gọi thay mặt chúng. Toàn bộ kiểu tấn công này được gọi là DNS rebinding. Nó đã gây ra nhiều vấn đề cho các dịch vụ localhost từ trước khi hầu hết những người đọc bài viết này bắt đầu viết mã.

Ví dụ mà giới tiền điện tử vẫn thường nhắc đến là vụ MyEtherWallet ngày 24 tháng 4 năm 2018. Kẻ tấn công đã thực hiện một vụ chiếm quyền điều khiển BGP chống lại Route 53 của Amazon, chuyển hướng DNS cho myetherwallet.com và tạo ra một bản sao giả mạo hoạt động đủ lâu để lấy đi khoảng 215 ETH (khoảng 152.000 đến 160.000 đô la tùy thuộc vào mốc thời gian bạn xác định, theo báo cáo từ The Register và Internet Society). Tôi biết rằng đây không hoàn toàn là một vụ tấn công localhost. Nhưng đó là bước ngoặt mà cộng đồng tiền điện tử ngừng giả vờ rằng mô hình nguồn gốc của trình duyệt là một ranh giới bảo mật thực sự. Mọi cầu nối ví cục bộ đang âm thầm lắng nghe trên cổng loopback đột nhiên cảm thấy bị phơi bày.

Giải pháp của Chrome xuất hiện dưới dạng Truy cập Mạng Riêng tư, ban đầu được gọi là CORS-RFC1918 trong các bản nháp. Kể từ tháng 3 năm 2024, trình duyệt hiện gửi yêu cầu kiểm tra trước CORS mang theo `Access-Control-Request-Private-Network: true` trước khi cho phép bất kỳ trang web công cộng nào truy cập vào địa chỉ riêng tư hoặc địa chỉ loopback. Dịch vụ cục bộ của bạn phải trả lời lại với `Access-Control-Allow-Private-Network: true` để được chấp nhận. Việc thực thi đầy đủ được triển khai qua các bản phát hành Chrome từ 123 đến 130. Vì vậy, nếu bạn triển khai máy chủ phát triển trên 127.0.0.1:49342 và mong đợi một trang công cộng truy cập vào đó trong quá trình kiểm thử tích hợp, hãy đặt tiêu đề đó. Nếu không, yêu cầu sẽ bị từ chối một cách im lặng.

Nhân đây, chúng ta cần nhắc đến một vài lỗ hổng bảo mật CVE của Electron năm 2025. CVE-2025-10585 là lỗi nhầm lẫn kiểu dữ liệu V8, được thêm vào danh mục Lỗ hổng đã khai thác của CISA vào ngày 23 tháng 9 năm 2025. CVE-2025-55305 là lỗ hổng bỏ qua tính toàn vẹn mã, can thiệp vào ảnh chụp nhanh bộ nhớ heap của V8, được công bố cùng thời điểm đó. Electron sử dụng Chromium làm lớp bao bọc, và máy tính xách tay của bạn có rất nhiều ứng dụng Electron (Slack, VS Code, Discord, Notion, Teams, và có thể nhiều hơn nữa). Nhiều ứng dụng trong số đó để lộ các dịch vụ cục bộ trên giao diện loopback. Hãy vá lỗi nhanh chóng. Và xin lưu ý, đừng bao giờ thiết lập điểm cuối RPC trên 127.0.0.1 mà không có mã thông báo xác thực nếu điểm cuối đó có thể đọc khóa, ký giao dịch hoặc xử lý tiền dưới bất kỳ hình thức nào.

Cách các nhà phát triển tiền điện tử sử dụng Localhost trong Hardhat, Anvil, Ganache

Phát triển Web3 về cơ bản là một chuỗi vô tận các tham chiếu địa chỉ mạng 127.0.0.1 — cho dù trọng tâm của bạn là triển khai hợp đồng, kiểm thử lỗi giao thức, hay chỉ là phát triển web hàng ngày trên một chuỗi cục bộ. Hiện tại, trên máy tính xách tay của bạn đang có một cụm nhỏ các node cục bộ đang chạy trên localhost (ngay cả khi bạn quên mất một nửa trong số chúng). Mỗi node có máy chủ riêng với các quy tắc cổng. Mỗi node đều cung cấp một địa chỉ IP và cổng riêng biệt để máy khách kết nối, thường sử dụng một cổng cụ thể mà công cụ đã mặc định.

Tóm tắt nhanh. Mạng Hardhat của Nomic Foundation chọn `http://127.0.0.1:8545` với ID chuỗi 31337 làm mặc định. Anvil của Foundry cũng sử dụng cùng địa chỉ và cổng này, có thể cấu hình thông qua `--port` trong trường hợp bạn mở hai bộ kiểm thử và chúng xung đột. Giao diện người dùng đồ họa (GUI) của Ganache chọn `127.0.0.1:7545` với ID mạng 5777, mặc dù phiên bản dòng lệnh (CLI) của nó dùng chung 8545 với Hardhat. Trong khi đó, chế độ regtest của Bitcoin Core chạy JSON-RPC trên `127.0.0.1:18443` — một thay đổi đã được đưa trở lại phiên bản v0.16 thông qua yêu cầu kéo #10825, sau khi ai đó chỉ ra xung đột với 18332 của mạng kiểm thử.

MetaMask kết nối với hầu hết mọi máy chủ. Thêm một mạng tùy chỉnh với URL RPC cục bộ và bạn đã có thể truy cập. Địa chỉ IP 127.0.0.1 chỉ đóng vai trò như một cầu nối mỏng giữa giao diện ví dựa trên trình duyệt của bạn và bất kỳ chuỗi khối mô phỏng nào đang hoạt động trên máy tính xách tay của bạn vào thời điểm đó. Khi bạn thấy `127.0.0.1:` trong dấu vết ngăn xếp Web3, hầu như luôn có hai khả năng: bộ điều hợp gỡ lỗi của IDE đang can thiệp vào máy chủ, hoặc chính máy chủ đó đang khởi tạo một điểm cuối WebSocket trên một cổng ngẫu nhiên ngay bên cạnh RPC cố định của nó.

Việc tích hợp thanh toán lặp lại mô hình này. Xây dựng một hệ thống thanh toán tiền điện tử được hỗ trợ bởi Plisio? Bạn sẽ chạy SDK cục bộ trên một trình lắng nghe Flask hoặc Express nhỏ tại `127.0.0.1:3000/plisio/callback`. Webhook của cổng thanh toán không bao giờ có thể truy cập trực tiếp vào máy tính xách tay của bạn từ internet công cộng, vì vậy việc thử nghiệm cục bộ sử dụng một đường hầm (ngrok, Cloudflare Tunnel, Tailscale Funnel) để hiển thị cổng. Đó là một cổng cụ thể trên một số cổng cụ thể mà bạn, người bán, chọn và kiểm soát. Mỗi SDK PHP, Python, Laravel và Node.js của Plisio đều cung cấp một trình trợ giúp `verifyCallbackData` để tính toán lại HMAC-SHA1 của dữ liệu so với khóa bí mật của cửa hàng. Quá trình kiểm tra chạy trên mỗi lệnh gọi lại khi nó đến trình lắng nghe cục bộ. Cùng một địa chỉ loopback, cùng một tác vụ, chữ ký thực được đính kèm.

Hãy nhìn tổng quan một chút. Thực tế, mô hình này xuất hiện ở khắp mọi nơi: thanh toán, OAuth, các dịch vụ mạng Web3 được sử dụng trong quá trình phát triển đều trông giống nhau từ bên trong — một máy chủ trên cổng 49342 hoặc một cổng động nào đó khác, các kết nối thực trên cổng được chỉ định và chạy trên localhost suốt thời gian đó.

Kiểm tra nhanh máy chủ cục bộ và cổng cho mọi hệ điều hành

Một bảng tóm tắt ngắn gọn. Hãy luôn mở nó trong một tab terminal. Bạn sẽ cần đến nó nhiều hơn bạn nghĩ.

Hãy hình dung một máy Linux, bất kỳ bản phân phối nào. Lệnh `sudo ss -tulpn | grep :49342` trả lời câu hỏi "ai đang sử dụng cổng 49342". Bỏ lệnh `grep` đi, bạn sẽ nhận được tất cả các socket đang lắng nghe trên máy. Tò mò về giới hạn cổng động của kernel? Hãy dùng lệnh `cat /proc/sys/net/ipv4/ip_local_port_range`. Nếu bạn chỉ muốn bằng chứng rằng chính giao diện loopback đang hoạt động, lệnh `ip addr show lo` sẽ cho bạn biết. Và này — nếu `lo` biến mất khỏi kết quả, bạn đã tìm thấy một vấn đề lớn hơn nhiều so với chỉ là một cổng.

Mac hoạt động tương tự, chỉ khác ở công cụ vì nó thuộc môi trường BSD. Lệnh `lsof -nP -iTCP:49342 -sTCP:LISTEN` in ra tiến trình đang chiếm giữ cổng. Bỏ dấu hai chấm và số, bạn sẽ liệt kê tất cả các tiến trình đang lắng nghe. Sử dụng tiền tố `sudo` khi bạn cần xem thông tin về socket của người dùng khác. Phạm vi tạm thời nằm ở lệnh `sysctl net.inet.ip.portrange.first net.inet.ip.portrange.hifirst`. Loopback được gọi là `lo0` ở đây (không phải `lo`), và sự khác biệt nhỏ trong cách đặt tên này khiến mọi người nhầm lẫn chỉ một lần trước khi họ ghi nhớ nó mãi mãi. Kiểm tra bằng lệnh `ifconfig lo0`.

Windows hoàn toàn đảo ngược ngôn ngữ. Mở PowerShell với quyền quản trị viên. Lệnh `netstat -ano | findstr :49342` sẽ trả về một PID. Sử dụng lệnh `tasklist /fi "PID eq "` để chuyển đổi số đó thành tên ứng dụng. Còn dải địa chỉ động? Sử dụng lệnh `netsh int ipv4 show dynamicport tcp`. Cần giảm dải địa chỉ vì một ứng dụng cũ cứng đầu yêu cầu địa chỉ ở mức thấp? Lệnh `netsh int ipv4 set dynamic tcp start=49152 num=16384` sẽ thực hiện việc này.

Hãy ghi nhớ những thao tác đó và những rắc rối với localhost của bạn sẽ được giải quyết chỉ trong năm phút, thậm chí ít hơn. Thử làm điều này xem: chạy lệnh `lsof -nP -iTCP -sTCP:LISTEN | grep 127.0.0.1` trên máy tính xách tay của bạn. Danh sách cuộn luôn dài hơn bạn tưởng. Các tab chạy ngầm của trình duyệt. Một vài máy chủ ngôn ngữ soạn thảo, thường là nhiều hơn một. DNS nội bộ của Docker. Các cầu nối IPC Electron từ Slack, Discord, Linear, hoặc bất cứ thứ gì khác bạn đang chạy. Một số tiến trình đo lường từ xa của hệ điều hành mà bạn chưa từng biết đến. Cộng thêm sáu hoặc bảy máy chủ phát triển từ sáng nay mà bạn chắc chắn đã quên tắt. Mức nhiễu nền đó là bình thường. Đó chính là âm thanh của một môi trường phát triển đang hoạt động.

Simon Chartan

A journalist with a strong technical background and a passion for decentralized finance. With degrees in MBA and Master of Engineering in Data Science, the author combines analytical expertise with a clear, engaging writing style. At Plisio, they cover topics such as cryptocurrency, blockchain, DeFi, and digital finance—helping readers make sense of a rapidly evolving fintech landscape.