ERR_PROXY_CERTIFICATE_INVALID: Sửa lỗi chứng chỉ proxy HTTPS

ERR_PROXY_CERTIFICATE_INVALID là lỗi Chrome báo khi chứng chỉ của chính máy chủ proxy không hợp lệ. Lỗi này khác với cảnh báo chứng chỉ của website, vì nó xảy ra trước khi trình duyệt chạm tới trang đích. Thường gặp nhất là khi khai báo proxy dạng https:// trong khi proxy đó chỉ là HTTP thường, hoặc proxy dùng chứng chỉ tự ký. Bài này ProxyVN giải thích cách nhận biết, đọc nguyên nhân và sửa từng trường hợp. Tham khảo dịch vụ tại ProxyVN.

Tổng quan về lỗi ERR_PROXY_CERTIFICATE_INVALID

Phần lớn anh em gặp lỗi này lần đầu đều nghĩ website có vấn đề. Thực tế, website không liên quan. Hiểu rõ lỗi xảy ra ở đoạn đường nào giúp anh em sửa đúng chỗ ngay từ đầu.

Lỗi này nghĩa là gì

Chrome hỗ trợ một loại proxy đặc biệt gọi là secure web proxy, hay proxy HTTPS. Với loại này, đường từ trình duyệt tới proxy được mã hoá bằng TLS, giống như khi vào một website HTTPS. Để mã hoá, proxy phải trình ra một chứng chỉ, và Chrome kiểm tra chứng chỉ đó như kiểm tra chứng chỉ của bất kỳ trang web nào.

Nếu chứng chỉ của proxy hết hạn, tự ký, sai tên hoặc proxy không nói TLS được, Chrome dừng lại và báo ERR_PROXY_CERTIFICATE_INVALID. Trong mã nguồn Chromium, lỗi này có số hiệu -136. Điểm cần nhớ: lỗi nằm ở đoạn trình duyệt tới proxy, không phải đoạn proxy tới website.

Dấu hiệu nhận biết

Lỗi có vài đặc điểm khá dễ thấy, giúp phân biệt với các lỗi khác:

• Mọi trang đều báo cùng một lỗi, kể cả trang HTTP thường không có ổ khoá.
• Không có nút "Advanced" hay "Proceed to..." để bỏ qua như cảnh báo chứng chỉ website.
• Lỗi xuất hiện ngay sau khi đổi cấu hình proxy, cài tiện ích proxy hoặc nhận tệp PAC mới.
• Tắt proxy thì mọi trang vào bình thường.
• Trình duyệt khác như Firefox dùng cùng proxy có thể không lỗi, vì Firefox xử lý proxy HTTPS khác.

Dấu hiệu "mọi trang đều lỗi, kể cả trang HTTP" là chỉ báo mạnh nhất. Cảnh báo chứng chỉ website chỉ xuất hiện với trang HTTPS cụ thể, còn lỗi này chặn tất cả.

Phân biệt với cảnh báo chứng chỉ website

Cảnh báo "Kết nối của bạn không phải là kết nối riêng tư" kèm mã NET::ERR_CERT_AUTHORITY_INVALID hay NET::ERR_CERT_DATE_INVALID là lỗi chứng chỉ của website. Trình duyệt đã đi qua proxy, tới được trang đích, và trang đích trình ra chứng chỉ có vấn đề. Cách xử lý loại cảnh báo đó có trong bài kết nối của bạn không phải là kết nối riêng tư.

Bảng: Phân biệt với cảnh báo chứng chỉ website

Tiêu chí	ERR_PROXY_CERTIFICATE_INVALID	Lỗi chứng chỉ website
Chứng chỉ bị lỗi	Của máy chủ proxy	Của trang web đích
Phạm vi	Mọi trang	Từng trang HTTPS
Nút bỏ qua	Không có	Thường có "Proceed to..."
Tắt proxy	Hết lỗi	Thường vẫn lỗi
Hướng xử lý	Sửa cấu hình hoặc chứng chỉ proxy	Kiểm tra đồng hồ máy, chứng chỉ trang

Bảng này giúp anh em định hướng chỉ trong vài giây. Nếu thấy chữ PROXY trong mã lỗi, hãy tập trung vào proxy, đừng mất công với website.

Nguyên nhân gây lỗi ERR_PROXY_CERTIFICATE_INVALID

Chứng chỉ của proxy, không phải của website

Có năm nguyên nhân chính, xếp theo mức độ phổ biến mà ProxyVN gặp khi hỗ trợ anh em. Nguyên nhân đầu tiên chiếm phần lớn số ca.

Khai báo nhầm proxy HTTP thành HTTPS

Đây là nguyên nhân hàng đầu. Nhiều người ghi https:// trước địa chỉ proxy vì nghĩ "proxy này dùng cho trang https". Thực tế, một proxy HTTP thường vẫn mở được trang HTTPS qua phương thức CONNECT. Theo tài liệu về proxy và tunneling của MDN, CONNECT mở một đường hầm hai chiều tới tài nguyên đích, và đó là cách một client đứng sau proxy HTTP vào được website dùng TLS ở cổng 443.

Khi anh em khai báo https://203.0.113.10:8080 trong khi cổng 8080 chỉ nói HTTP thường, Chrome cố bắt tay TLS với proxy. Proxy không hiểu và trả về dữ liệu dạng chữ thường, hoặc đóng kết nối. Chrome coi đó là chứng chỉ không hợp lệ và báo lỗi.

Proxy dùng chứng chỉ tự ký

Một số proxy HTTPS tự dựng, ví dụ Squid với https_port, hay stunnel bọc ngoài proxy HTTP, dùng chứng chỉ tự ký vì tiện. Chrome không tin chứng chỉ tự ký nếu chứng chỉ gốc chưa được thêm vào kho tin cậy của hệ điều hành. Kết quả là lỗi chứng chỉ proxy.

Trong môi trường công ty, chứng chỉ thường do CA nội bộ cấp. Máy được đưa vào domain sẽ có sẵn chứng chỉ gốc qua Group Policy. Máy cá nhân hoặc máy mới cài lại thì không có, và gặp lỗi ngay.

Tên trong chứng chỉ không khớp địa chỉ proxy

Chứng chỉ TLS gắn với tên máy chủ cụ thể, được ghi trong trường Subject Alternative Name. Bài giải thích chứng chỉ SSL là gì của Cloudflare nhấn mạnh chứng chỉ chứa tên miền mà nó được cấp cho. Nếu chứng chỉ cấp cho proxy.congty.vn mà anh em khai báo proxy bằng IP 203.0.113.10, tên không khớp và Chrome từ chối.

Lỗi này hay gặp khi đổi từ tên miền sang IP để "cho nhanh", hoặc khi nhà cung cấp cấp chứng chỉ cho một tên miền rồi đổi tên miền khác. Khai báo đúng tên ghi trong chứng chỉ là sửa được.

Chứng chỉ hết hạn hoặc thiếu chứng chỉ trung gian

Chứng chỉ có ngày bắt đầu và ngày hết hạn. Chứng chỉ Let's Encrypt chỉ có hiệu lực 90 ngày, nếu quên gia hạn thì proxy trình ra chứng chỉ quá hạn. Ngoài ra, máy chủ phải gửi kèm chứng chỉ trung gian để trình duyệt nối được chuỗi tin cậy về chứng chỉ gốc. Thiếu chứng chỉ trung gian cũng khiến Chrome báo không hợp lệ, dù trình duyệt khác có thể vẫn chấp nhận.

Một trường hợp ít ai để ý là đồng hồ máy tính sai. Nếu ngày trên máy lệch nhiều so với thực tế, mọi chứng chỉ đều bị coi là chưa có hiệu lực hoặc đã hết hạn. Lúc đó cả website cũng lỗi theo.

Thiết bị ở giữa chèn chứng chỉ khác

Phần mềm diệt virus có chức năng quét HTTPS, hoặc tường lửa công ty có chức năng giải mã TLS, có thể chặn kết nối tới proxy và trình chứng chỉ của chính chúng. Nếu chứng chỉ gốc của các thiết bị này không có trong kho tin cậy, Chrome báo lỗi chứng chỉ proxy. Tắt tạm chức năng quét HTTPS là cách kiểm tra nhanh.

Cách kiểm tra cấu hình proxy đang áp dụng

Tên trong chứng chỉ không khớp địa chỉ proxy

Trước khi sửa, anh em cần biết Chrome đang dùng proxy nào và ở dạng gì. Chrome có thể nhận proxy từ nhiều nguồn: cài đặt hệ điều hành, tham số dòng lệnh, tiện ích, chính sách công ty, tệp PAC.

Xem proxy hiệu lực trong Chrome

Chrome có trang nội bộ cho biết cấu hình proxy đang áp dụng. Anh em làm theo các bước:

• Gõ chrome://net-internals/#proxy vào thanh địa chỉ.
• Xem mục Effective proxy settings, đây là cấu hình Chrome thật sự dùng.
• Xem mục Original proxy settings để biết cấu hình gốc đến từ đâu.
• Bấm Re-apply settings sau khi sửa, hoặc đóng hẳn Chrome rồi mở lại.

Nếu trong Effective proxy settings có dòng dạng HTTPS 203.0.113.10:8080 hoặc https://..., đó chính là proxy HTTPS đang được dùng. Đối chiếu với thông tin nhà cung cấp để xem cổng đó có thật sự hỗ trợ TLS không.

Xem cấu hình từ chính sách công ty

Nếu máy thuộc công ty, proxy có thể được đẩy qua chính sách ProxySettings. Gõ chrome://policy để xem. Theo danh sách chính sách của Chrome Enterprise, chính sách này có trường ProxyMode nhận các giá trị direct, auto_detect, pac_script, fixed_servers và system. Trường ProxyServer chứa địa chỉ proxy, ProxyPacUrl chứa đường dẫn tệp PAC, ProxyBypassList chứa danh sách bỏ qua.

{
  "ProxyMode": "fixed_servers",
  "ProxyServer": "https://secure-proxy.congty.vn:443",
  "ProxyBypassList": "localhost;127.0.0.1;*.congty.vn"
}

Khi cấu hình đến từ chính sách, anh em không sửa được trong cài đặt Chrome. Cần báo bộ phận IT, gửi kèm ảnh chụp trang chrome://policy và mã lỗi.

Đọc nội dung tệp PAC

Với tệp PAC, hàm FindProxyForURL trả về chuỗi quyết định loại proxy. Chuỗi "PROXY host:port" nghĩa là proxy HTTP thường. Chuỗi "HTTPS host:port" nghĩa là proxy HTTPS, Chrome sẽ bắt tay TLS với proxy. Anh em mở đường dẫn PAC trong trình duyệt để xem nội dung, tìm từ khoá HTTPS ở các lệnh return.

function FindProxyForURL(url, host) {
  // Proxy HTTP thường, Chrome không bắt tay TLS với proxy
  return "PROXY proxy.congty.vn:8080";
 
  // Proxy HTTPS, proxy phải có chứng chỉ hợp lệ cho proxy.congty.vn
  // return "HTTPS proxy.congty.vn:443";
}

Nếu tệp PAC trả về HTTPS cho một proxy chỉ hỗ trợ HTTP, mọi kết nối đều lỗi. Sửa thành PROXY là xong.

Sửa lỗi ERR_PROXY_CERTIFICATE_INVALID theo từng nguyên nhân

Khi đã biết Chrome đang dùng proxy nào, việc sửa khá rõ ràng. Mỗi nguyên nhân có một cách xử lý riêng.

Đổi lược đồ https:// thành http://

Nếu proxy của nhà cung cấp là proxy HTTP thường, chỉ cần đổi lược đồ. Proxy HTTP vẫn mở được trang HTTPS, dữ liệu giữa trình duyệt và website vẫn được mã hoá đầu cuối qua đường hầm CONNECT. Proxy chỉ thấy tên miền đích, không thấy nội dung.

# Sai: khai báo proxy HTTP thường thành HTTPS
chrome.exe --proxy-server="https://203.0.113.10:8080"
 
# Đúng: proxy HTTP thường
chrome.exe --proxy-server="http://203.0.113.10:8080"
 
# Đúng: proxy SOCKS5 (không mật khẩu)
chrome.exe --proxy-server="socks5://203.0.113.10:1080"

Trong cài đặt Windows, ô Address của Manual proxy setup chỉ nhận địa chỉ và cổng, không có lược đồ. Nếu anh em ghi https:// vào ô đó, Windows có thể lưu nguyên chuỗi và Chrome hiểu sai. Xoá phần https:// đi, chỉ để IP hoặc tên miền. Các bước cài đặt proxy trên Chrome đầy đủ có trong bài cách cài đặt proxy cho Google Chrome.

Thử truy cập thẳng vào proxy để xem chứng chỉ

Tài liệu secure web proxy của Chromium gợi ý một cách kiểm tra rất hay: tắt cấu hình proxy, rồi mở thẳng địa chỉ của proxy trong tab mới, ví dụ https://203.0.113.10:443/. Chrome sẽ hiện trang lỗi chứng chỉ thông thường, có đủ thông tin chi tiết.

• Bấm vào chữ "Not secure" trên thanh địa chỉ, chọn Certificate is not valid để xem chứng chỉ.
• Xem tab Details: tên trong Subject Alternative Name, ngày hết hạn, đơn vị cấp.
• Nếu trang báo ERR_SSL_PROTOCOL_ERROR, cổng đó không nói TLS, tức là proxy HTTP thường.
• Khi trang mở được mà không có cảnh báo, cấu hình lại Chrome dùng proxy HTTPS là chạy.

Cách này tách được việc kiểm tra chứng chỉ khỏi việc dùng proxy. Lỗi giao thức SSL khi dùng proxy có bài riêng: lỗi ERR_SSL_PROTOCOL_ERROR khi dùng proxy.

Kiểm tra chứng chỉ proxy bằng openssl và curl

Với người quen dòng lệnh, openssl và curl cho thông tin chính xác hơn. Lệnh openssl s_client in ra toàn bộ chuỗi chứng chỉ mà proxy trình ra, kèm ngày hết hạn và tên máy chủ.

# Xem chuỗi chứng chỉ của proxy HTTPS
openssl s_client -connect secure-proxy.congty.vn:443 -servername secure-proxy.congty.vn -showcerts
 
# Chỉ xem tên và ngày hết hạn
openssl s_client -connect secure-proxy.congty.vn:443 -servername secure-proxy.congty.vn </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
 
# Dùng proxy HTTPS với curl (curl 7.52 trở lên)
curl -v -x https://secure-proxy.congty.vn:443 https://example.com/
 
# Chỉ định CA riêng cho proxy
curl -v -x https://secure-proxy.congty.vn:443 --proxy-cacert ca-noibo.pem https://example.com/

Nếu openssl báo "wrong version number" hoặc không in ra chứng chỉ nào, cổng đó không phải TLS. Nếu dòng notAfter là một ngày trong quá khứ, chứng chỉ đã hết hạn. Nếu Verify return code khác 0, chuỗi tin cậy có vấn đề: thiếu chứng chỉ trung gian hoặc chứng chỉ tự ký.

Thêm chứng chỉ gốc nội bộ vào kho tin cậy

Khi proxy dùng chứng chỉ do CA nội bộ cấp, cách đúng là thêm chứng chỉ gốc của CA đó vào kho tin cậy. Trên Windows, Chrome dùng kho chứng chỉ của hệ điều hành:

• Nhận tệp chứng chỉ gốc dạng .cer hoặc .crt từ bộ phận IT.
• Bấm đúp vào tệp, chọn Install Certificate.
• Chọn Local Machine, bấm Next.
• Chọn Place all certificates in the following store, bấm Browse, chọn Trusted Root Certification Authorities.
• Bấm Finish, đóng Chrome hẳn rồi mở lại.

Trên macOS, mở Keychain Access, kéo tệp vào keychain System, bấm đúp vào chứng chỉ, mở mục Trust và chọn Always Trust. Chỉ thêm chứng chỉ gốc khi anh em biết rõ nguồn gốc của nó. Chứng chỉ gốc lạ trong kho tin cậy cho phép bên phát hành đọc được mọi lưu lượng HTTPS.

Gia hạn hoặc thay chứng chỉ phía máy chủ proxy

Nếu anh em tự vận hành proxy HTTPS, việc sửa nằm ở phía máy chủ. Gia hạn chứng chỉ trước hạn, cấu hình máy chủ gửi kèm chuỗi trung gian đầy đủ, và đảm bảo tên trong chứng chỉ khớp với tên mà người dùng khai báo.

# Squid: cổng proxy HTTPS dùng chuỗi chứng chỉ đầy đủ
https_port 443 tls-cert=/etc/squid/fullchain.pem tls-key=/etc/squid/privkey.pem
 
# stunnel bọc proxy HTTP ở cổng 8080 thành proxy HTTPS ở cổng 443
[https-proxy]
accept = 443
connect = 127.0.0.1:8080
cert = /etc/stunnel/fullchain.pem
key = /etc/stunnel/privkey.pem

Tệp fullchain.pem chứa cả chứng chỉ máy chủ và chứng chỉ trung gian. Dùng tệp cert.pem chỉ chứa một chứng chỉ là nguyên nhân phổ biến của lỗi thiếu chuỗi trung gian.

Đọc nhật ký mạng khi lỗi ERR_PROXY_CERTIFICATE_INVALID khó tìm

Đọc nhật ký mạng của trình duyệt

Tài liệu Chromium thừa nhận lỗi chứng chỉ proxy khó chẩn đoán vì chi tiết chứng chỉ không hiện ra dễ dàng. Khi các cách trên chưa đủ, nhật ký mạng của Chrome là công cụ cuối cùng.

Ghi nhật ký bằng net-export

Chrome có công cụ ghi lại mọi sự kiện mạng. Anh em làm theo các bước:

• Mở tab mới, gõ chrome://net-export.
• Chọn Include raw bytes nếu cần chi tiết gói tin, mặc định để Strip private information.
• Bấm Start Logging to Disk, chọn nơi lưu tệp JSON.
• Mở một tab khác, tải lại trang bị lỗi.
• Quay lại tab net-export, bấm Stop Logging.

Tệp nhật ký có thể chứa địa chỉ trang đã truy cập. Trước khi gửi cho người hỗ trợ, anh em nên đóng các tab không liên quan và chỉ ghi trong khoảng thời gian ngắn.

Đọc tệp nhật ký

Tệp JSON được mở bằng công cụ xem nhật ký netlog-viewer do Google cung cấp. Trong tab Events, lọc theo từ khoá proxy hoặc SSL. Những sự kiện cần tìm:

• PROXY_RESOLUTION_SERVICE: cho biết Chrome chọn proxy nào cho yêu cầu đó.
• SSL_CONNECT_JOB hoặc SSL_HANDSHAKE_ERROR: bước bắt tay TLS với proxy.
• CERT_VERIFIER_JOB: kết quả kiểm tra chứng chỉ, kèm mã lỗi chi tiết như CERT_COMMON_NAME_INVALID hay CERT_DATE_INVALID.

Mã lỗi chi tiết trong CERT_VERIFIER_JOB cho biết chính xác nguyên nhân. CERT_COMMON_NAME_INVALID là sai tên, CERT_DATE_INVALID là hết hạn, CERT_AUTHORITY_INVALID là chứng chỉ tự ký hoặc CA lạ.

Bảng tra nguyên nhân theo mã chi tiết

Bảng dưới gom các mã chi tiết thường thấy trong nhật ký và cách xử lý tương ứng:

Bảng: Bảng tra nguyên nhân theo mã chi tiết

Mã chi tiết	Nguyên nhân	Cách xử lý
CERT_AUTHORITY_INVALID	Chứng chỉ tự ký hoặc CA nội bộ chưa được tin	Thêm chứng chỉ gốc vào kho tin cậy
CERT_COMMON_NAME_INVALID	Tên trong chứng chỉ khác địa chỉ proxy	Khai báo proxy bằng đúng tên trong chứng chỉ
CERT_DATE_INVALID	Chứng chỉ hết hạn hoặc đồng hồ máy sai	Gia hạn chứng chỉ, chỉnh đồng hồ
SSL_PROTOCOL_ERROR	Cổng không nói TLS	Đổi lược đồ về http://
CERT_REVOKED	Chứng chỉ đã bị thu hồi	Cấp chứng chỉ mới

Nhờ bảng này, anh em không cần đoán. Một tệp nhật ký ghi trong 10 giây thường đủ để chỉ ra nguyên nhân.

Khi nào nên dùng HTTP CONNECT hoặc SOCKS5 thay cho proxy HTTPS

Chuyển về HTTP CONNECT hoặc SOCKS5

Proxy HTTPS có lợi ích rõ ràng, nhưng không phải lúc nào cũng cần. Phần này giúp anh em quyết định có nên giữ loại proxy này hay chuyển sang loại đơn giản hơn.

Lợi ích thật của proxy HTTPS

Proxy HTTPS mã hoá cả đoạn trình duyệt tới proxy. Tài liệu Chromium nêu rõ điều này hữu ích trên mạng không an toàn như sân bay hay quán cà phê, nơi duyệt web HTTP có thể làm lộ cookie và phiên đăng nhập. Ngoài ra, người trên cùng mạng Wi-Fi không thấy được anh em đang gọi tên miền nào qua proxy, và thông tin xác thực proxy cũng được mã hoá.

Với proxy HTTP thường, nội dung trang HTTPS vẫn được mã hoá đầu cuối. Thứ lộ ra là tên miền trong yêu cầu CONNECT và thông tin đăng nhập proxy dạng Basic. Chủ đề này được giải thích kỹ hơn trong bài HTTPS proxy là gì và bài proxy SSL là gì.

Hạn chế về tương thích

Tài liệu Chromium cũng cảnh báo các trình duyệt khác không hỗ trợ kiểu HTTPS trong tệp PAC. Nếu đặt PAC có HTTPS cho toàn hệ thống, các ứng dụng khác dùng proxy hệ thống có thể không hiểu. Nhiều phần mềm, công cụ tự động, trình duyệt chống phát hiện cũng chỉ hỗ trợ HTTP và SOCKS5.

Bảng: Hạn chế về tương thích

Loại proxy	Mã hoá đoạn tới proxy	Mức tương thích	Phù hợp khi
HTTP (CONNECT)	Không, nội dung HTTPS vẫn mã hoá đầu cuối	Rất cao	Dùng hằng ngày, công cụ tự động
HTTPS (secure web proxy)	Có	Thấp, chủ yếu Chrome và curl	Wi-Fi công cộng, yêu cầu bảo mật công ty
SOCKS5	Không	Cao	Ứng dụng không phải trình duyệt, game, công cụ dòng lệnh

Với nhu cầu đổi IP, quản lý tài khoản hay thu thập dữ liệu, proxy HTTP hoặc SOCKS5 là đủ dùng và ít lỗi hơn. Proxy HTTPS phù hợp khi có yêu cầu bảo mật rõ ràng cho đoạn mạng cục bộ.

Chuyển đổi mà không mất bảo mật

Nếu lo ngại bảo mật trên Wi-Fi công cộng mà proxy chỉ hỗ trợ HTTP, anh em có vài lựa chọn. Một là chỉ vào trang HTTPS, vì nội dung vẫn được mã hoá đầu cuối. Hai là dùng proxy có xác thực bằng danh sách IP cho phép thay vì mật khẩu, để không lộ mật khẩu qua mạng. Ba là dựng đường hầm SSH tới máy chủ của mình rồi dùng SOCKS5 qua đường hầm đó.

# Mở đường hầm SSH tạo proxy SOCKS5 cục bộ ở cổng 1080
ssh -N -D 127.0.0.1:1080 user@may-chu-cua-ban
 
# Chrome dùng proxy SOCKS5 cục bộ đó
chrome.exe --proxy-server="socks5://127.0.0.1:1080"

Toàn bộ lưu lượng từ máy tới máy chủ SSH được mã hoá, kể cả trên Wi-Fi công cộng. Đây là ví dụ triển khai chung, không phụ thuộc vào nhà cung cấp proxy cụ thể nào.

Phòng tránh lỗi ERR_PROXY_CERTIFICATE_INVALID về sau

Sửa xong một lần, anh em nên áp dụng vài thói quen để lỗi không quay lại, nhất là khi quản lý nhiều máy hoặc nhiều hồ sơ trình duyệt.

Ghi rõ loại proxy khi lưu cấu hình

Nhiều lỗi bắt nguồn từ việc ghi chép thiếu. Khi lưu thông tin proxy, anh em nên ghi đủ bốn phần: giao thức, địa chỉ, cổng, thông tin xác thực. Ví dụ http://user:pass@203.0.113.10:8080 hoặc socks5://203.0.113.10:1080. Đừng ghi https:// chỉ vì proxy dùng cho trang HTTPS.

Khi chép proxy vào công cụ, hãy dán đúng định dạng mà công cụ yêu cầu. Một số công cụ có ô chọn giao thức riêng, khi đó ô địa chỉ không được có lược đồ.

Theo dõi hạn chứng chỉ của proxy tự vận hành

Với proxy HTTPS do anh em tự dựng, nên dùng certbot với chế độ tự gia hạn, hoặc đặt lịch kiểm tra ngày hết hạn. Một lệnh openssl chạy định kỳ là đủ để cảnh báo trước 14 ngày.

# Kiểm tra chứng chỉ còn hạn ít nhất 14 ngày (1209600 giây)
echo | openssl s_client -connect secure-proxy.congty.vn:443 -servername secure-proxy.congty.vn 2>/dev/null | openssl x509 -noout -checkend 1209600 && echo "Con han" || echo "Sap het han"

Gắn lệnh này vào cron hoặc Task Scheduler, kèm một lệnh gửi thông báo, anh em sẽ không bao giờ bị bất ngờ vì chứng chỉ hết hạn vào sáng thứ hai.

Chọn proxy có định dạng rõ ràng

Nhà cung cấp proxy uy tín luôn ghi rõ giao thức và cổng cho từng loại. Khi cần IP Việt Nam ổn định cho công việc, anh em có thể mua proxy Việt Nam tại ProxyVN, hỗ trợ HTTP và SOCKS5, cấp sẵn tên đăng nhập và mật khẩu, kèm hướng dẫn định dạng cho từng công cụ.

Thấy chữ PROXY trong mã lỗi chứng chỉ, hãy nhìn vào cấu hình proxy trước, website gần như vô can.

ProxyVN đảm bảo mạng kết nối luôn ổn định, proxy chất lượng không bị mất kết nối, tool sử dụng không có lỗi và nếu có thì được hỗ trợ sửa 24/24. Gặp lỗi cấu hình, anh em chỉ cần gửi ảnh trang chrome://net-internals/#proxy để được kiểm tra nhanh.

Những trường hợp đặc biệt của lỗi ERR_PROXY_CERTIFICATE_INVALID

Ngoài các nguyên nhân chính, vài tình huống ít gặp hơn cũng gây ra lỗi này. Biết trước giúp anh em không mất thời gian tìm sai hướng.

Tiện ích proxy ghi lược đồ sai

Một số tiện ích quản lý proxy cho chọn giao thức HTTP, HTTPS, SOCKS4, SOCKS5 trong danh sách thả xuống. Chọn nhầm HTTPS cho proxy HTTP thường là lỗi rất dễ mắc, vì tên gọi gây hiểu lầm. Mở lại cấu hình tiện ích, đổi về HTTP, lưu và tải lại trang.

Nếu dùng nhiều hồ sơ proxy trong tiện ích, kiểm tra cả hồ sơ đang bật lẫn quy tắc tự chuyển hồ sơ. Đôi khi một quy tắc cũ trỏ một số tên miền sang hồ sơ có lược đồ sai.

Trình duyệt chống phát hiện và công cụ tự động

Trình duyệt chống phát hiện dựa trên Chromium cũng có thể báo lỗi tương tự khi hồ sơ được gán proxy kiểu HTTPS. Với Puppeteer, Playwright hoặc Selenium, tham số --proxy-server truyền vào Chromium phải đúng lược đồ. Nếu không chắc, dùng http:// cho proxy HTTP và socks5:// cho SOCKS5.

// Puppeteer: dùng proxy HTTP thường, xác thực bằng page.authenticate
const browser = await puppeteer.launch({
  args: ["--proxy-server=http://203.0.113.10:8080"]
});
const page = await browser.newPage();
await page.authenticate({ username: "user", password: "pass" });
await page.goto("https://example.com");

Đây là ví dụ triển khai chung. Điểm cần lưu ý là không nhét tên đăng nhập, mật khẩu vào chuỗi --proxy-server, vì Chromium không đọc phần đó.

Proxy HTTP/2 của Chrome

Tài liệu Chromium ghi rằng Chrome thương lượng giao thức trong lúc bắt tay TLS với proxy, nếu proxy hỗ trợ HTTP/2 thì proxy hoạt động như proxy HTTP/2. Một số proxy khai báo hỗ trợ HTTP/2 nhưng cấu hình chưa chuẩn, gây lỗi bắt tay. Khi gặp lỗi chỉ với một proxy HTTPS cụ thể mà chứng chỉ vẫn hợp lệ, thử tắt HTTP/2 phía máy chủ proxy để khoanh vùng.

Kết luận

ERR_PROXY_CERTIFICATE_INVALID là lỗi chứng chỉ của chính máy chủ proxy, không phải của website. Nguyên nhân phổ biến nhất là khai báo proxy HTTP thường thành https://, tiếp theo là chứng chỉ tự ký, sai tên hoặc hết hạn. Cần proxy HTTP, SOCKS5 ổn định, hãy liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để được hỗ trợ xử lý ERR_PROXY_CERTIFICATE_INVALID.