ERR_CONNECTION_REFUSED: đã từ chối kết nối, cách sửa

ERR_CONNECTION_REFUSED là gì?

ERR_CONNECTION_REFUSED nghĩa là trình duyệt đã tìm thấy địa chỉ IP của trang web, nhưng máy ở địa chỉ đó đã từ chối kết nối. Chrome hiển thị “Không thể truy cập trang web này” cùng dòng “example.com đã từ chối kết nối.” và mã ERR_CONNECTION_REFUSED, tức lỗi -102 trong danh sách của Chromium (net_error_list.h).

Thiết bị của bạn đã gửi yêu cầu kết nối TCP tới địa chỉ IP và cổng của máy chủ (443 cho HTTPS, 80 cho HTTP) và nhận lại lời từ chối ngay lập tức: hoặc là gói TCP reset, hoặc là thông báo “port unreachable” (cổng không truy cập được) từ tường lửa. Không có chương trình nào nhận kết nối trên cổng đó, hoặc tường lửa đã từ chối yêu cầu. DNS đã hoạt động; kết nối thì không.

Nói cách khác, đây là một câu trả lời chứ không phải sự im lặng. Nếu không có gì trả lời, Chrome chờ rồi hiển thị ERR_CONNECTION_TIMED_OUT. Nếu kết nối mở ra rồi bị cắt, đó là ERR_CONNECTION_RESET; nếu máy chủ ngắt trước khi gửi trang, đó là ERR_CONNECTION_CLOSED.

Lỗi này hiển thị thế nào trên các trình duyệt và ứng dụng khác

Kết nối bị từ chối là cùng một sự kiện ở mọi nơi; chỉ có cách diễn đạt thay đổi. Các trình duyệt nền Chromium (Chrome, Edge, Brave, Opera) hiển thị mã ERR_CONNECTION_REFUSED, còn các ứng dụng báo lỗi riêng của hệ điều hành:

Các cách sửa bên dưới đều áp dụng dù thông báo diễn đạt thế nào: có thứ gì đó ở địa chỉ và cổng đó đã nói không.

Nguyên nhân phổ biến gây ra ERR_CONNECTION_REFUSED

Các nguyên nhân, đi từ phía trang web tới phía bạn:

• Máy chủ của trang web bị sập — máy chủ web (nginx, Apache, Node.js) bị lỗi, đang khởi động lại hoặc đã bị dừng. Máy vẫn trực tuyến, nhưng không có gì trả lời trên cổng 80 hay 443.
• Tường lửa được đặt để từ chối — tường lửa trên máy chủ, trong mạng của bạn hoặc trên thiết bị của bạn từ chối (thay vì lặng lẽ bỏ qua) các kết nối tới cổng đó.
• Trang chặn mạng của bạn — một số trang từ chối cả dải địa chỉ, chẳng hạn máy chủ thoát của VPN hoặc cả một quốc gia.
• Phần mềm bảo mật hoặc VPN — lớp bảo vệ web của phần mềm diệt virus hoặc VPN chuyển lưu lượng của bạn qua chính nó rồi từ chối kết nối. (Tường lửa trên chính thiết bị của bạn chặn Chrome sẽ hiển thị một trang khác, “Quyền truy cập Internet của bạn bị chặn”, ERR_NETWORK_ACCESS_DENIED.)
• Sai địa chỉ IP — bộ nhớ đệm DNS cũ hoặc một mục trong file hosts đưa bạn tới máy chủ cũ, hoặc tới chính máy tính của bạn (127.0.0.1), nơi không có gì đang lắng nghe.
• Một chuyển hướng hoặc quy tắc HTTPS đã được ghi nhớ — Chrome đã lưu một chuyển hướng, hoặc quy tắc HSTS của trang, và cứ tiếp tục đưa bạn tới một cổng mà trang không còn phục vụ.
• Không có gì lắng nghe trên localhost — dành cho lập trình viên: máy chủ cục bộ không chạy, đã bị lỗi, hoặc chạy trên cổng hay địa chỉ khác với cái bạn đã mở.

Một trang, mọi trang hay mọi trình duyệt?

Lỗi xuất hiện ở đâu cho bạn biết nên tìm ở đâu, trước khi bạn thay đổi bất cứ thứ gì:

“Trên mọi trình duyệt” rất quan trọng: Edge, Firefox và Safari không dùng chung bộ nhớ đệm hay tiện ích mở rộng với Chrome, nên bị từ chối trên tất cả cho thấy nguyên nhân nằm dưới tầng trình duyệt, tức thiết bị, mạng của bạn hoặc chính trang web.

Cách 1: kiểm tra xem trang web có sập với tất cả mọi người không

Trước khi thay đổi bất cứ thứ gì trên thiết bị, hãy xác định xem trang có từ chối tất cả mọi người không. Nếu có, không cách sửa nào ở phía bạn giúp được.

Cách thử nhanh nhất là dùng một đường mạng khác: mở trang trên điện thoại bằng dữ liệu di động (tắt Wi-Fi). Sau đó kiểm tra máy chủ từ bên ngoài bằng các công cụ này của DNS Robot:

• Kiểm tra web sập — mở trang từ 11 địa điểm và từ chính trình duyệt của bạn. Sập ở mọi nơi: lỗi ở trang. Vào được ở mọi nơi trừ chỗ bạn: lỗi ở phía bạn.
• Kiểm tra port — nhập trang kèm cổng 443 (hoặc example.com:443). Đóng nghĩa là máy chủ cũng từ chối kết nối của chúng tôi; mở nghĩa là nó nhận kết nối và lời từ chối chỉ xảy ra ở phía bạn.
• Kiểm Tra Ping — kết nối tới trang trên cổng 443 từ 11 thành phố, cùng một lệnh ping cổ điển từ một nơi. Bị từ chối từ mọi thành phố nghĩa là máy đang chạy nhưng không có gì lắng nghe trên cổng đó; không có phản hồi cho ping cổ điển không chứng minh được gì, vì nhiều máy chủ bỏ qua nó.

Cách 2: khởi động lại router và thiết bị

Gợi ý đầu tiên của chính Chrome, “Kiểm tra kết nối”, là khởi động lại “mọi bộ định tuyến, modem hoặc thiết bị mạng khác mà bạn có thể đang sử dụng”. Việc này xóa trạng thái router đã tích lũy, kể cả bộ nhớ đệm DNS của nó.

Rút nguồn điện của router (và modem, nếu là thiết bị riêng), đợi 30 giây, cắm lại và cho nó 2–3 phút để kết nối lại hoàn toàn. Khởi động lại cả máy tính hoặc điện thoại để đặt lại network stack của nó, rồi thử vào trang lần nữa.

Cách 3: xóa chuyển hướng và quy tắc HTTPS mà Chrome đã ghi nhớ

Chrome ghi nhớ các chuyển hướng vĩnh viễn và quy tắc HSTS của từng trang (“luôn dùng HTTPS”). Nếu trang đã chuyển chỗ, hoặc không còn phục vụ HTTPS trên cổng 443, Chrome vẫn đưa bạn tới một địa chỉ hoặc cổng mà không có gì lắng nghe.

• Mở Chrome → menu ba chấm → Xoá dữ liệu duyệt web
• Phạm vi thời gian → Từ trước đến nay, đánh dấu Tệp và hình ảnh được lưu trong bộ nhớ đệm (cookie có thể giữ lại)
• Nhấp vào Xoá dữ liệu (hoặc Xoá khỏi thiết bị này nếu bạn chưa đăng nhập Chrome), rồi thử vào trang lần nữa
• Vẫn bị từ chối? Mở chrome://net-internals/#hsts, nhập tên miền vào ô Delete domain security policies và nhấp Delete. Cách này chỉ hiệu quả với quy tắc do chính trang đặt ra, không áp dụng cho các tên miền đã được tích hợp sẵn trong danh sách tải trước HSTS của Chrome.

Một thay đổi của năm 2026: Chrome 154 (tháng 10/2026) bật “Luôn sử dụng kết nối bảo mật” theo mặc định, nên Chrome sẽ xin phép bạn trước lần đầu truy cập một trang công khai không có HTTPS thay vì lặng lẽ thử (Google Security Blog).

Cách 4: kiểm tra cài đặt proxy

Trang lỗi của Chrome có nhắc tới proxy, nên hãy kiểm tra, nhưng cần biết trước điều sẽ xảy ra. Khi Chrome không kết nối được tới máy chủ proxy, nó hiển thị một trang có tiêu đề “Không có Internet” cùng ERR_PROXY_CONNECTION_FAILED (“Đã xảy ra sự cố với máy chủ proxy hoặc địa chỉ không chính xác.”) chứ không phải ERR_CONNECTION_REFUSED. Nếu đó là trang bạn thấy, đây chính là cách sửa của bạn.

Windows: Cài đặt → Mạng & Internet → Proxy. Trong “Thiết lập proxy thủ công”, nhấp Chỉnh sửa (hoặc Thiết lập) bên cạnh “Sử dụng máy chủ proxy”, tắt tùy chọn này rồi nhấp Lưu. Tắt luôn “Sử dụng tập lệnh thiết lập” nếu bạn không nhận ra địa chỉ. Hãy để “Tự động phát hiện” bật, trừ khi bạn biết mạng của mình không dùng nó.

macOS: Cài đặt hệ thống → Mạng → Wi-Fi → Chi tiết → Proxy. Tắt mọi proxy mà tổ chức của bạn không thiết lập, rồi nhấp OK.

Chrome dùng cài đặt proxy của hệ thống, Firefox cũng mặc định như vậy (“Dùng các thiết lập proxy của hệ thống”), nên một proxy lỗi thời làm hỏng mọi trình duyệt cùng lúc. Trên thiết bị của trường học hoặc công ty, quản trị viên đặt proxy và bạn không thể thay đổi.

Cách 5: xóa bộ nhớ đệm DNS

Nếu trang đã chuyển sang máy chủ mới, một câu trả lời DNS được lưu đệm vẫn có thể trỏ tới IP cũ, nơi không còn gì lắng nghe. Xóa bộ nhớ đệm buộc thiết bị của bạn tra cứu địa chỉ hiện tại.

# Windows (Command Prompt as Administrator)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Also clear Chrome's internal DNS cache:
# chrome://net-internals/#dns → Clear host cache

Sau khi xóa, hãy xóa luôn bộ nhớ đệm DNS riêng của Chrome tại chrome://net-internals/#dns và làm sạch các socket pool tại chrome://net-internals/#sockets: Chrome giữ cả hai tách biệt khỏi hệ điều hành. Hướng dẫn đầy đủ có trong bài cách xóa DNS cache trên mọi hệ điều hành.

Để xem địa chỉ mà máy tính của bạn thực sự dùng (kể cả file hosts và bộ nhớ đệm), chạy ping example.com, hoặc Resolve-DnsName example.com trong PowerShell, rồi so với Tra Cứu DNS. Đừng dùng nslookup cho việc này: nó hỏi thẳng máy chủ DNS và bỏ qua cả hai.

Cách 6: chuyển sang máy chủ DNS công cộng

Nếu bộ phân giải của nhà mạng vẫn trả về địa chỉ cũ sau khi bạn đã xóa bộ nhớ đệm, hãy chuyển sang một bộ phân giải công cộng để nhận câu trả lời mới.

Windows: Cài đặt → Mạng & Internet → Wi-Fi → “Quản lý các mạng đã biết” → mạng của bạn (Ethernet → mạng của bạn) → Chỉnh sửa bên cạnh “Gán máy chủ DNS” → Thủ công → bật IPv4 → DNS ưa thích 1.1.1.1, DNS thay thế 1.0.0.1 → Lưu.

macOS: Cài đặt hệ thống → Mạng → Wi-Fi → Chi tiết → DNS → thêm 1.1.1.1 và 1.0.0.1, xóa các mục cũ → OK.

Không chắc bộ phân giải nào nhanh nhất từ vị trí của bạn? Hãy chạy Kiểm tra tốc độ DNS của DNS Robot: công cụ này đo Cloudflare, Google, Quad9 và các nhà cung cấp khác ngay từ kết nối của bạn trong vài giây.

Cách 7: tạm thời tắt VPN, phần mềm diệt virus và tường lửa

VPN, lớp bảo vệ web của phần mềm diệt virus và tường lửa đều nằm giữa trình duyệt và internet, và mỗi thứ đều có thể từ chối kết nối. Các lớp bảo vệ quét HTTPS cho lưu lượng của bạn đi qua một dịch vụ cục bộ; nếu dịch vụ đó hỏng, các trang HTTPS có thể lỗi trên mọi trình duyệt cùng lúc. Và một số trang từ chối thẳng địa chỉ của VPN.

Hãy thử từng thứ một: ngắt VPN rồi tải lại. Sau đó tạm dừng bảo vệ web của phần mềm diệt virus trong một phút rồi tải lại. Cuối cùng, tạm dừng mọi tường lửa của bên thứ ba, thường là một phần của bộ phần mềm diệt virus. (Tường lửa của macOS chỉ lọc kết nối đến, còn Windows Defender Firewall cho phép lưu lượng đi ra trừ khi có người thêm quy tắc. Nếu Chrome hiển thị “Quyền truy cập Internet của bạn bị chặn”, nguyên nhân là tường lửa trên thiết bị của bạn.)

Nếu trang tải được khi tắt một trong số đó, hãy bật lại và thêm ngoại lệ cho trang, hoặc chọn máy chủ VPN khác, thay vì để tắt hẳn lớp bảo vệ.

Cách 8: kiểm tra tiện ích mở rộng bằng chế độ ẩn danh

Tiện ích mở rộng hiếm khi gây ra mã này: tiện ích chặn một trang sẽ hiển thị ERR_BLOCKED_BY_CLIENT. Nhưng một cửa sổ Ẩn danh (Ctrl+Shift+N, hoặc Cmd+Shift+N trên Mac) là phép thử mười giây loại trừ cùng lúc cả tiện ích lẫn dữ liệu lưu đệm, vì tiện ích bị tắt ở đó trừ khi bạn đã cho phép.

Nếu trang tải được trong chế độ Ẩn danh, vào chrome://extensions, tắt hết, rồi bật lại từng cái một cho đến khi lỗi quay lại. Nếu vẫn lỗi trong chế độ Ẩn danh, nguyên nhân nằm ngoài Chrome.

Cách 9: kiểm tra file hosts

File hosts ghi đè DNS cho những tên có trong đó. Nếu trang được ánh xạ trong đó tới 127.0.0.1 hoặc IP của một máy chủ cũ, trình duyệt sẽ kết nối tới đó và bị từ chối. Các mục phát triển còn sót lại và danh sách hosts chặn quảng cáo là những nghi phạm thường gặp, và file này ảnh hưởng tới mọi trình duyệt.

# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts

# macOS / Linux:
sudo nano /etc/hosts

# Look for lines containing the domain, e.g.:
# 127.0.0.1   example.com   ← forces the connection to your own PC
# 203.0.113.7 example.com   ← forces an old server IP

# Delete the offending line, save, then flush DNS.

Cách 10: trên Android hoặc iPhone

Điện thoại từ chối kết nối vì cùng những lý do, chỉ khác công tắc:

• Đổi mạng: tải trang bằng dữ liệu di động, rồi bằng Wi-Fi. Nếu chỉ một trong hai từ chối, vấn đề nằm ở mạng đó chứ không phải điện thoại.
• Tắt các ứng dụng VPN, kể cả ứng dụng chặn quảng cáo và tường lửa chạy dưới dạng VPN (chúng hiển thị biểu tượng chìa khóa hoặc VPN trên thanh trạng thái).
• Gỡ proxy của Wi-Fi: trên Android, mở cài đặt của mạng Wi-Fi → biểu tượng cây bút (Sửa đổi) → Tùy chọn nâng cao → Proxy → Không có (tên có thể khác tùy hãng điện thoại). Trên iPhone: Cài đặt → Wi-Fi → ⓘ cạnh mạng → Định cấu hình proxy → “Off” (tắt).
• Xóa dữ liệu của Chrome: Chrome → Cài đặt → Quyền riêng tư và bảo mật → Xoá dữ liệu duyệt web → Tệp và hình ảnh được lưu trong bộ nhớ đệm.
• Đang thử máy chủ của chính bạn? Trên điện thoại, localhost là chính chiếc điện thoại. Hãy dùng địa chỉ IP nội bộ của máy tính (xem phần tiếp theo).

Localhost Refused to Connect (dành cho lập trình viên)

Thấy localhost từ chối kết nối hoặc ERR_CONNECTION_REFUSED trên 127.0.0.1 nghĩa là không có gì trên máy của bạn nhận kết nối ở địa chỉ và cổng bạn đã mở. Những lý do thường gặp:

• Máy chủ phát triển không chạy — bạn chưa khởi động nó, hoặc nó đã bị lỗi. Kiểm tra terminal nơi npm run dev, rails s hoặc python manage.py runserver lẽ ra đang chạy.
• Sai cổng — máy chủ khởi động trên cổng khác (ví dụ 3001 vì 3000 đã bận). Sao chép địa chỉ từ dòng khởi động của nó.
• Không có cổng trong địa chỉ — http://localhost đi tới cổng 80, trong khi máy chủ phát triển dùng cổng riêng (3000, 5173, 8000, 8080).
• 127.0.0.1 hay [::1] — trình duyệt thử cả hai địa chỉ cho localhost, nhưng máy chủ có thể chỉ lắng nghe trên một trong hai. Mở thẳng địa chỉ còn lại (http://127.0.0.1:3000 hoặc http://[::1]:3000), hoặc kết nối từ một công cụ chỉ thử một địa chỉ, sẽ bị từ chối.
• Trong Docker — ứng dụng phải lắng nghe trên 0.0.0.0 bên trong container, và cổng phải được công khai (-p 3000:3000). Ứng dụng gắn với 127.0.0.1 trong container không truy cập được từ máy của bạn (thay vào đó bạn có thể thấy ERR_EMPTY_RESPONSE).
• Từ điện thoại hoặc máy giả lập — ở đó, localhost là chính thiết bị. Hãy dùng IP LAN của máy tính và khởi động máy chủ phát triển trên mọi giao diện (Vite: --host), hoặc 10.0.2.2 từ trình giả lập Android, bí danh của nó cho localhost của máy tính bạn.

# What is listening on port 3000?
# macOS / Linux:
lsof -nP -iTCP:3000 -sTCP:LISTEN

# Windows (PowerShell):
netstat -ano | findstr :3000 | findstr LISTENING

# No output = nothing is listening = connection refused.
# 127.0.0.1:3000 in the output = IPv4 only; [::1]:3000 = IPv6 only.

Nếu bạn cần kiểm tra xem một cổng trên máy chủ công khai của mình có truy cập được từ internet hay không (chứ không chỉ từ chính máy đó), hãy dùng Kiểm tra port của DNS Robot: công cụ này kiểm tra kết nối từ bên ngoài mạng của bạn, đúng như khách truy cập thực sự trải nghiệm.

“Đã từ chối kết nối” bên trong một trang nhúng

Nếu dòng “example.com đã từ chối kết nối.” xuất hiện trong một khung trên trang khác (biểu mẫu, báo cáo, bản đồ hoặc form đăng nhập được nhúng), thường đó không phải lỗi mạng. Chrome hiển thị cùng câu đó khi trang được nhúng cấm hiển thị bên trong các trang của website khác bằng header X-Frame-Options hoặc Content-Security-Policy: frame-ancestors. Bên trong, đó là ERR_BLOCKED_BY_RESPONSE, lỗi -27 (net_error_list.h).

Với tư cách khách truy cập, hãy mở liên kết được nhúng trong một tab riêng; nó sẽ tải được ở đó. Với tư cách chủ trang, hãy cho phép trang nhúng bạn bằng Content-Security-Policy: frame-ancestors 'self' https://parent.example. X-Frame-Options chỉ có thể nói DENY hoặc SAMEORIGIN, và các trình duyệt hiện nay theo frame-ancestors khi trang gửi cả hai. Xem trang của bạn đang gửi gì bằng Kiểm tra HTTP Header, còn hướng dẫn X-Frame-Options của chúng tôi có các header chính xác.

Dành cho chủ website: trang của bạn từ chối kết nối

Nếu khách truy cập báo ERR_CONNECTION_REFUSED trên trang của bạn, gói tin của họ đã tới một máy ở IP của bạn, nhưng không có gì ở đó nhận kết nối. Hãy làm theo danh sách kiểm tra này:

• Máy chủ web có đang chạy không? SSH vào và kiểm tra systemctl status nginx (hoặc apache2, caddy). Một máy chủ không khởi động được sau khi khởi động lại do cấu hình hỏng, hoặc bị tắt khi máy hết bộ nhớ, sẽ không còn gì lắng nghe. Khởi động lại bằng sudo systemctl restart nginx.
• Nó có lắng nghe đúng cổng và địa chỉ không? Chạy ss -tlnp | grep -E ':(80|443) '. Máy chủ chỉ lắng nghe trên 127.0.0.1 sẽ từ chối mọi người từ bên ngoài; không có gì trên 443 nghĩa là không có server block nào lắng nghe ở đó (HTTPS chưa bao giờ được thiết lập, hoặc file của trang chưa được bật). nginx -T in ra cấu hình đang thực sự được nạp.
• Tường lửa có đang từ chối không? Quy tắc đặt ở chế độ từ chối (iptables REJECT, ufw reject) sẽ gửi lời từ chối. Mặc định deny của ufw và các tường lửa đám mây như security group của AWS bỏ gói tin một cách lặng lẽ, và khách truy cập thấy đó là ERR_CONNECTION_TIMED_OUT.
• fail2ban có chặn ai không? Lệnh chặn mặc định của nó từ chối địa chỉ bị chặn, nên khách truy cập đó (hoặc chính bạn, sau vài lần đăng nhập SSH thất bại) nhận ERR_CONNECTION_REFUSED trong khi mọi người khác vào được. Kiểm tra sudo fail2ban-client status.
• IP máy chủ của bạn có thay đổi không? So sánh bản ghi A của bạn với IP thật của máy chủ bằng Tra Cứu DNS. Sau khi chuyển máy chủ, bản ghi A cũ đưa khách truy cập tới máy trước đó.
• Đứng sau Cloudflare? Với bản ghi bật proxy (đám mây cam), khách truy cập kết nối tới Cloudflare chứ không phải bạn, nên sẽ không thấy mã này. Khi máy chủ gốc của bạn từ chối kết nối của Cloudflare, Cloudflare hiển thị Error 521: Web server is down của riêng nó.
• Kiểm tra từ bên ngoài: Kiểm tra port trên cổng 80 và 443, và Kiểm tra HTTP Header cho một yêu cầu thật từ internet công cộng.

Cách xác minh lỗi đã được khắc phục

Sau mỗi cách khắc phục, hãy xác nhận kết nối ở cấp độ mạng thay vì chỉ tải lại trang — điều này cho bạn biết cổng có thực sự mở hay chưa.

# Test the TCP connection directly (Mac/Linux):
nc -zv -w 5 example.com 443
# "succeeded" = port open, "refused" = still rejected

# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed

# Then confirm the address your computer actually uses:
ping -c 1 example.com          # Mac/Linux
Resolve-DnsName example.com    # Windows PowerShell

Hoặc bỏ qua terminal: nhập tên miền và cổng vào Kiểm tra port của DNS Robot để nhận câu trả lời mở/đóng từ bên ngoài mạng của bạn. Nếu cổng mở từ bên ngoài nhưng trình duyệt vẫn hiển thị ERR_CONNECTION_REFUSED, thứ gây chặn nằm trên thiết bị hoặc mạng của bạn: hãy quay lại các cách sửa về VPN, phần mềm bảo mật và file hosts.