Cách xử lý lỗi 407 proxy khi dùng tài khoản trong Playwright

Lỗi 407 proxy xuất hiện khi máy chủ proxy yêu cầu xác thực nhưng chưa nhận được thông tin hợp lệ. Với Playwright, tình huống này thường liên quan đến cấu hình tài khoản, mật khẩu, địa chỉ proxy hoặc phương thức xác thực mà trình duyệt hỗ trợ.

Để xử lý đúng, cần phân biệt lỗi của proxy với lỗi đăng nhập website và sự cố kết nối. Bài viết dưới đây trình bày cách cấu hình proxy Playwright, kiểm tra nguyên nhân và xây dựng quy trình chẩn đoán an toàn.

Lỗi 407 Proxy Authentication Required là gì?

Proxy Authentication Required là thông báo đi kèm mã trạng thái HTTP 407. Proxy dùng phản hồi này để yêu cầu phía khách cung cấp thông tin xác thực phù hợp trước khi chuyển tiếp lưu lượng đến máy chủ đích.

Trong cơ chế xác thực HTTP, phản hồi có thể chứa trường Proxy-Authenticate để thông báo phương thức được chấp nhận. Trình duyệt sau đó thực hiện quá trình xác thực theo cấu hình và khả năng hỗ trợ của nó.

Cần phân biệt các trường hợp sau:

• 407: yêu cầu xác thực từ proxy.
• 401: thường là yêu cầu xác thực từ máy chủ tài nguyên.
• 403: yêu cầu bị từ chối; không đủ cơ sở để kết luận sai mật khẩu proxy.

Khi truy cập website HTTPS, trình duyệt thường phải thiết lập đường hầm CONNECT qua HTTP proxy. Nếu xác thực thất bại tại bước này, Playwright có thể báo lỗi điều hướng hoặc lỗi đường hầm thay vì cung cấp một phản hồi trang có trạng thái 407.

Nguyên nhân thường gặp khi dùng proxy có tài khoản

Thông tin xác thực sai hoặc không còn hiệu lực

Tên đăng nhập có thể cần chứa thông tin định tuyến theo quy ước của nhà cung cấp. Thiếu thành phần trong tên tài khoản cũng có thể khiến xác thực thất bại dù mật khẩu đúng.

Ngoài ra, cần kiểm tra tài khoản bị khóa, mật khẩu đã thay đổi, dịch vụ hết hiệu lực hoặc chính sách truy cập vừa được cập nhật. Không nên chỉ đối chiếu hai chuỗi username và password rồi kết luận cấu hình hợp lệ.

Khai báo tài khoản không đúng vị trí

Gắn username và password trực tiếp vào URL không phải lựa chọn nên ưu tiên cho cấu hình trình duyệt Playwright. Cách rõ ràng hơn là tách địa chỉ proxy, tên đăng nhập và mật khẩu thành các thuộc tính riêng trong đối tượng proxy.

Một nhầm lẫn khác là dùng httpCredentials để xử lý xác thực proxy. Thuộc tính này phục vụ xác thực HTTP của máy chủ đích trong browser context, không thay thế username và password của cấu hình proxy.

Nhầm giao thức hoặc cổng kết nối

Giao thức trong địa chỉ proxy mô tả cách kết nối đến proxy, không phải giao thức của website cần mở. Truy cập một website HTTPS không đồng nghĩa phải đổi địa chỉ proxy từ http:// sang https://.

Hãy sử dụng đúng endpoint, giao thức và cổng do nhà cung cấp công bố. Đối với SOCKS, không nên giả định cơ chế username và password hoạt động giống HTTP proxy; cần kiểm tra khả năng hỗ trợ của trình duyệt và cấu hình cụ thể.

Cấu hình proxy Playwright đúng cách

Rà soát nơi khai báo proxy và phạm vi áp dụng trước khi chạy thử Playwright.

Ví dụ với JavaScript và Chromium

Ví dụ sau sử dụng biến môi trường để tách bí mật khỏi mã nguồn. PROXY_SERVER cần chứa địa chỉ endpoint có giao thức và cổng phù hợp; PROXY_USERNAME và PROXY_PASSWORD chứa thông tin xác thực thực tế.

import { chromium } from 'playwright';

const server = process.env.PROXY_SERVER;

const username = process.env.PROXY_USERNAME;

const password = process.env.PROXY_PASSWORD;

if (!server || !username || !password) { throw new Error('Thiếu cấu hình proxy trong biến môi trường'); }

const browser = await chromium.launch({ proxy: { server, username, password } });

try { const context = await browser.newContext(); const page = await context.newPage(); await page.goto('https://example.com'); } finally { await browser.close(); }

Trong cấu hình này, server chỉ chứa địa chỉ proxy. Không ghép lại thông tin đăng nhập vào server khi đã truyền username và password riêng.

Điều kiện kiểm tra biến môi trường trong ví dụ phù hợp với dịch vụ yêu cầu cả tên đăng nhập lẫn mật khẩu. Nếu nhà cung cấp có quy ước khác, cần điều chỉnh kiểm tra theo tài liệu của họ.

Phân biệt phạm vi browser và context

Playwright có tùy chọn proxy ở cấp khởi chạy trình duyệt và cấp browser context. Hãy xác định rõ ứng dụng đang sử dụng cấp nào, đặc biệt khi có nhiều context hoặc tái sử dụng browser từ một dịch vụ khác.

Để chẩn đoán, nên bắt đầu bằng một browser, một context và một trang thử nghiệm. Cấu hình tối giản giúp xác định lỗi có xuất phát từ proxy hay từ lớp quản lý phiên trong ứng dụng.

Nếu chạy bằng Playwright Test, hãy kiểm tra cấu hình proxy trong use, cấu hình từng project và các đoạn ghi đè trong test. Không nên mặc định rằng cấu hình ở một tệp luôn áp dụng cho mọi tiến trình chạy thử.

Quy trình kiểm tra lỗi 407 proxy theo thứ tự

Đối chiếu endpoint và chính sách truy cập

Trước tiên, mở trang quản lý dịch vụ để kiểm tra endpoint, cổng, trạng thái tài khoản và phương thức xác thực. Một số dịch vụ dùng tài khoản, một số dùng danh sách IP được phép, hoặc áp dụng chính sách kết hợp.

Nếu cần cho phép IP nguồn, hãy kiểm tra IP đầu ra của máy thực sự chạy Playwright. Máy cá nhân, container và máy CI có thể đi ra Internet qua các địa chỉ khác nhau.

Kiểm tra proxy bên ngoài Playwright

Phép thử bằng curl giúp đối chiếu khả năng kết nối proxy bên ngoài Playwright.

Dùng một công cụ HTTP có hỗ trợ proxy, chẳng hạn curl, để gửi yêu cầu thử với cùng endpoint và tài khoản. Nếu Playwright đang mở website HTTPS, phép thử cũng nên sử dụng HTTPS để kiểm tra cả bước thiết lập đường hầm.

Nếu phép thử độc lập cũng báo yêu cầu xác thực, hãy ưu tiên kiểm tra dịch vụ proxy và thông tin đăng nhập. Nếu công cụ độc lập hoạt động nhưng trình duyệt thất bại, hãy tập trung vào cấu hình Playwright, cơ chế xác thực và môi trường chạy.

Kết quả thành công từ curl không bảo đảm trình duyệt sẽ hoạt động tương tự. Hai công cụ có thể hỗ trợ phương thức xác thực khác nhau hoặc sử dụng cấu hình hệ thống khác nhau.

Kiểm tra biến môi trường và ký tự đặc biệt

Mật khẩu chứa ký tự đặc biệt có thể bị shell diễn giải khi truyền qua lệnh hoặc tệp cấu hình. Hãy kiểm tra cách trích dẫn giá trị trong môi trường triển khai, thay vì tự sửa nội dung mật khẩu.

Khi truyền username và password bằng thuộc tính riêng, thông thường cần dùng giá trị gốc, không tự mã hóa URL. Đồng thời kiểm tra khoảng trắng hoặc ký tự xuống dòng phát sinh từ secret được đọc từ tệp.

Không nên tự động loại bỏ khoảng trắng của mọi mật khẩu: khoảng trắng có thể là một phần hợp lệ của bí mật. Cần sửa nguồn cấu hình khi xác định được ký tự thừa.

So sánh môi trường hoạt động và môi trường lỗi

Nếu cùng mã nguồn chạy được trên máy cá nhân nhưng thất bại trong CI, hãy đối chiếu phiên bản Playwright, browser binary, secret được cấp và đường đi mạng. Kiểm tra thêm khả năng có proxy trung gian của tổ chức.

Không mặc định rằng biến HTTP_PROXY hoặc HTTPS_PROXY của hệ điều hành sẽ tự cấu hình đúng lưu lượng trình duyệt Playwright. Cần khai báo tùy chọn proxy rõ ràng cho thành phần đang thực hiện yêu cầu.

Đọc log và nhận diện đúng lớp xảy ra lỗi

Đối chiếu lỗi điều hướng với log trình duyệt giúp xác định bước kết nối thất bại.

Có thể theo dõi sự kiện requestfailed và ghi lại thông báo từ request.failure() để nhận diện yêu cầu bị lỗi. Với phản hồi HTTP mà trang quan sát được, sự kiện response giúp kiểm tra trạng thái và địa chỉ liên quan.

Tuy nhiên, lỗi xác thực trong quá trình thiết lập đường hầm có thể không xuất hiện như một response thông thường của trang. Khi đó, cần kết hợp lỗi từ page.goto, log trình duyệt và log phía proxy nếu có.

• Không kết nối được endpoint: kiểm tra DNS, cổng, tường lửa và khả năng truy cập mạng.
• Nhận yêu cầu xác thực: kiểm tra tài khoản, mật khẩu và phương thức xác thực.
• Thiết lập đường hầm thất bại: kiểm tra CONNECT, quyền truy cập đích và chính sách proxy.
• Chỉ một website bị lỗi: kiểm tra thêm phản hồi từ website và giới hạn truy cập của dịch vụ.

Không nên coi mọi lỗi điều hướng là lỗi 407 proxy. Việc xác định đúng lớp thất bại giúp tránh thay đổi cấu hình không liên quan.

Những cách sửa không nên áp dụng tùy tiện

Tự thêm Proxy-Authorization vào header của trang

Không nên dùng extraHTTPHeaders như giải pháp mặc định cho xác thực proxy. Header của yêu cầu trang không tương đương cơ chế xác thực do trình duyệt xử lý, đặc biệt khi có đường hầm HTTPS.

Cách làm này còn có nguy cơ đưa bí mật vào log hoặc gửi thông tin nhạy cảm sai phạm vi. Hãy ưu tiên đối tượng proxy và phương thức được Playwright hỗ trợ.

Tắt kiểm tra chứng chỉ hoặc tăng thời gian chờ

Bỏ qua lỗi chứng chỉ không giải quyết được tài khoản proxy không hợp lệ. Tương tự, tăng timeout chỉ kéo dài thời gian chờ nếu nguyên nhân thực sự là xác thực thất bại.

Chỉ điều chỉnh chứng chỉ hoặc timeout khi đã có bằng chứng cho thấy vấn đề nằm ở lớp tương ứng. Không nên gộp nhiều thay đổi vào cùng một lần kiểm tra.

Thử lại liên tục với cùng cấu hình

Retry có ích cho một số lỗi mạng tạm thời nhưng không sửa được mật khẩu sai. Thử lại liên tục còn có thể kích hoạt giới hạn truy cập hoặc khóa tài khoản theo chính sách dịch vụ.

Khi nhận diện lỗi xác thực, nên dừng tác vụ, ghi nhận nguyên nhân và yêu cầu kiểm tra cấu hình trước khi chạy lại.

Bảo vệ thông tin xác thực khi vận hành

Lưu tài khoản proxy trong hệ thống quản lý secret hoặc biến môi trường được kiểm soát. Không đưa mật khẩu vào kho mã, ảnh chụp màn hình, báo cáo lỗi hoặc đường dẫn có thể bị ghi log.

Khi cần hỗ trợ kỹ thuật, chỉ chia sẻ endpoint đã kiểm tra, thời điểm phát sinh, thông báo lỗi đã loại bỏ bí mật và môi trường chạy. Nếu thông tin đăng nhập từng bị công khai, cần thay đổi thông tin đó và cập nhật các tác vụ liên quan.

Kết luận

Để xử lý Proxy Authentication Required trong Playwright, hãy bắt đầu từ endpoint và quyền truy cập, sau đó kiểm tra username, password, giao thức và phạm vi cấu hình. Phép thử độc lập cùng log phù hợp sẽ giúp phân biệt lỗi dịch vụ với lỗi tích hợp.

Cấu hình xác thực proxy bằng các thuộc tính riêng, bảo vệ secret và sửa từng nguyên nhân có bằng chứng là nền tảng để vận hành proxy Playwright ổn định, dễ bảo trì.