Local Network Access trong Chrome: lab quyền trên Chrome 156

Local Network Access trong Chrome là cơ chế bắt một trang web công khai phải được người dùng cấp quyền trước khi gửi request tới thiết bị trong mạng nội bộ hoặc tới phần mềm chạy ngay trên máy. Nhiều hướng dẫn trên mạng vẫn mô tả cơ chế cũ dựa vào preflight, nên người chẩn đoán dễ sửa sai chỗ. ProxyVN chạy một trang public thật gọi về endpoint 127.0.0.1 trên Chrome 156 với ba trạng thái quyền, ghi log phía máy chủ và thông báo của trình duyệt.

Local Network Access trong Chrome: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và những gì bài không bàn.

Bài toán cần giải

Một công cụ quản trị thiết bị chạy trên một tên miền công khai. Trang của nó gọi tới agent cài trên máy người dùng ở cổng loopback, hoặc tới thiết bị trong mạng như máy in, camera. Sau một bản cập nhật Chrome, các lệnh gọi này bắt đầu lỗi. Đội phát triển thêm header CORS theo hướng dẫn cũ mà lỗi vẫn còn.

Đầu ra nghiệm thu

Đầu ra là ma trận quyền: ba trạng thái prompt, granted và denied, mỗi trạng thái có kết quả của năm kiểu request từ trang public tới loopback. Mỗi ô ghi kết quả ở phía trang, thông báo trên console và việc request có tới máy chủ hay không. Ma trận có ghi phiên bản Chrome.

Ranh giới với CORS

Bài không giải thích lại CORS. Lab sẽ cho thấy Local Network Access chặn request trước cả khi CORS có cơ hội xét. Khi quyền đã cấp, CORS vẫn áp dụng như thường. Hai lớp này nối tiếp nhau, sửa lớp này không sửa được lớp kia.

Không dùng tài liệu PNA làm cơ chế hiện hành

Chrome từng thử nghiệm Private Network Access, dựa trên preflight CORS với header Access-Control-Request-Private-Network. Bài này coi đó là lịch sử. Mọi khẳng định về cơ chế hiện hành đều lấy từ bài viết của Chrome, đặc tả Local Network Access và phép đo trên Chrome 156.

Giới hạn của lab

Trang public là https://example.com, chạy JavaScript thử trong trang đó. Endpoint đích là máy chủ http.server tự viết trên 127.0.0.1:9892. Trình duyệt là Chrome 156.0.8078.80 cài trên Windows, mở bằng Playwright 1.64.1 ở chế độ headless với hồ sơ tạm. Lab không dùng hồ sơ Chrome của người dùng và không chạm thiết bị nào trong mạng nội bộ.

Ai nên đọc

Người phát triển trang web cần nói chuyện với agent cục bộ hoặc thiết bị nội bộ. Người hỗ trợ kỹ thuật gặp lỗi Failed to fetch từ trang công khai tới địa chỉ nội bộ. Người làm công cụ tự động hóa trình duyệt cần biết quyền này hoạt động ra sao trong chế độ headless.

Phân biệt quyền Local Network Access trong Chrome hiện hành với thử nghiệm PNA preflight cũ

Phần này đặt hai cơ chế cạnh nhau để người đọc nhận ra tài liệu nào đã cũ.

PNA dựa vào thiết bị đồng ý

Private Network Access yêu cầu trình duyệt gửi một preflight trước request từ trang public tới mạng riêng. Thiết bị đích phải trả lời với header Access-Control-Allow-Private-Network: true. Quyết định nằm ở thiết bị, người dùng không được hỏi gì.

LNA dựa vào người dùng đồng ý

Bài viết của Chrome về Local Network Access nói rõ cơ chế mới đặt mọi request từ mạng public tới mạng nội bộ sau một lời nhắc cấp quyền. Thiết bị không cần trả header đặc biệt nào. Người dùng là người quyết định trang nào được phép.

PNA đã dừng lại

Bài viết của Chrome ghi rằng Chrome trước đó đã thử nghiệm PNA, cần preflight để thiết bị đồng ý, và Local Network Access thay thế nỗ lực đó sau khi PNA bị tạm dừng. Tài liệu nào bảo thêm Access-Control-Allow-Private-Network để sửa lỗi là tài liệu của cơ chế cũ.

Local Network Access replaces that effort, after PNA was put on hold. (Chrome for Developers)

Mốc phiên bản

Chrome 138 cho thử LNA qua cờ chrome://flags/#local-network-access-check. Bản cập nhật ngày 29/09/2025 của bài viết ghi rằng lời nhắc cấp quyền ra mắt ở Chrome 142. Lab chạy trên Chrome 156, sau mốc ra mắt nhiều phiên bản.

Ba không gian địa chỉ

Đặc tả Local Network Access chia địa chỉ IP thành ba không gian: public, local và loopback. PNA dùng ba tên public, private và local. Đặc tả mới đổi tên thành public, local và loopback. Cùng chữ local nhưng nghĩa khác nhau giữa hai tài liệu, rất dễ đọc nhầm.

Request nào bị chặn

Ở mốc đầu, Chrome coi request từ mạng public tới mạng local hoặc loopback là request mạng nội bộ. Mạng local gồm các dải riêng như 192.168.0.0/16, link-local và địa chỉ IPv6 cục bộ. Loopback gồm 127.0.0.0/8 và ::1. Mọi đích khác là public.

Request nội bộ với nhau chưa bị chặn

Đặc tả ghi chú rằng Chromium hiện chỉ áp dụng LNA cho request từ public tới local hoặc loopback. Request khác origin giữa hai địa chỉ nội bộ chưa bị bắt quyền. Kế hoạch mở rộng có trong bài viết, nhưng chưa phải hành vi hiện tại.

Chỉ trong ngữ cảnh an toàn

Quyền yêu cầu ngữ cảnh an toàn. Để không vướng chặn mixed content, Chrome miễn kiểm tra này cho request đã được biết trước là đi vào mạng nội bộ: hostname là IP nội bộ, tên miền .local, hoặc lệnh fetch có tùy chọn targetAddressSpace.

Vì sao Chrome đổi hướng

Bài viết của Chrome nêu hai mục tiêu: bảo vệ người dùng khỏi CSRF nhắm vào router và thiết bị trong mạng, và giảm khả năng trang web dò cấu trúc mạng nội bộ để định danh người dùng. Với PNA, một thiết bị cũ không bao giờ được cập nhật sẽ không thể đồng ý. Với LNA, người dùng quyết định thay thiết bị.

Nhiều nền tảng đã có quyền tương tự

Bài viết so sánh với Android, iOS và macOS, nơi ứng dụng cũng phải xin quyền truy cập mạng nội bộ. Người dùng đã từng cấp quyền này khi cài ứng dụng điều khiển thiết bị trong nhà. Chrome đưa cùng ý tưởng lên mức trang web.

Bảng so sánh hai cơ chế

Bảng: Bảng so sánh hai cơ chế

Điểm so sánh	PNA (cũ)	LNA (hiện hành)
Ai quyết định	Thiết bị đích qua preflight	Người dùng qua lời nhắc
Header thiết bị phải trả	Access-Control-Allow-Private-Network	Không có
Tên không gian	public, private, local	public, local, loopback
Trạng thái	Đã tạm dừng	Ra mắt từ Chrome 142
Tên quyền	Không có	local-network-access, local-network, loopback-network

Khóa phiên bản Chrome và đọc release notes Local Network Access trong Chrome mới

Một bài viết về cơ chế trình duyệt chỉ đúng với phiên bản nó đo. Phần này ghi cách khóa phiên bản.

Ghi phiên bản từ trình duyệt

Lab đọc phiên bản bằng lệnh Browser.getVersion của giao thức DevTools, kết quả là Chrome/156.0.8078.80. Phiên bản này được ghi vào tệp kết quả cùng từng ca. Ai chạy lại lab ở phiên bản khác cần so ma trận mới với ma trận trong bài.

Đọc bài viết trước khi đo

Trước khi viết mã lab, bài viết của Chrome và đặc tả đã được tải về và đọc ngày 05/11/2026. Hai nguồn đều trả HTTP 200. Bài viết có ngày đăng 09/06/2025 và bản cập nhật 29/09/2025. Các mục được dùng trong bài là định nghĩa request bị ảnh hưởng, mốc phiên bản và giới hạn đã biết.

Giới hạn đã biết theo bài viết

Bài viết liệt kê WebSocket, WebTransport và WebRTC tới mạng nội bộ chưa bị bắt quyền ở mốc đầu. Request từ Service Worker và Shared Worker cần origin đã được cấp quyền từ trước. Lab không đo các kênh này, nên bài không khẳng định gì thêm về chúng.

Tên quyền đã đổi

Đặc tả ghi rằng trước đây chỉ có một quyền local-network-access. Bản mới tách thành local-network và loopback-network, và Chromium vẫn giữ local-network-access như tên gọi khác. Trên Chrome 156, lab truy vấn được cả ba tên và cả ba trả cùng trạng thái trong mọi ca.

Chính sách doanh nghiệp

Bài viết của Chrome nhắc kế hoạch thêm chính sách doanh nghiệp để cấp trước hoặc từ chối trước quyền cho từng site. Máy được quản lý trong công ty có thể không bao giờ hiện lời nhắc cho các công cụ nội bộ đã được phép. Khi chẩn đoán trên máy công ty, cần hỏi bộ phận IT về chính sách này trước khi kết luận.

Trình duyệt nhúng khác Chrome

Lab đầu tiên chạy trên trình duyệt Chromium 152 nhúng trong một ứng dụng desktop. Request từ https://example.com tới 127.0.0.1 bị chặn với lỗi net::ERR_BLOCKED_BY_CLIENT và không request nào tới máy chủ. Đó là chặn của ứng dụng nhúng, không phải của LNA. Kết quả này bị loại khỏi ma trận chính.

CSP treat-as-public-address không còn tác dụng

Thời PNA, có thể gắn Content-Security-Policy: treat-as-public-address cho một trang chạy trên localhost để trình duyệt coi nó là public. Trên Chromium 152 nhúng, trang có CSP này vẫn gọi được 127.0.0.1 mà không bị chặn. Lab vì vậy dùng một trang public thật thay cho mẹo cũ.

Không bật cờ

Lab chạy Chrome với cấu hình mặc định, không bật cờ local-network-access-check. Kết quả phản ánh hành vi người dùng bình thường nhận được ở phiên bản này, không phải chế độ thử nghiệm.

Dựng trang public gọi endpoint local trong mạng lab để kiểm Local Network Access trong Chrome

Phần này mô tả endpoint, trang gọi và cách điều khiển trình duyệt.

Endpoint loopback

Máy chủ http.server tự viết nghe ở 127.0.0.1:9892. Nó trả pong cho mọi đường dẫn, gắn Access-Control-Allow-Origin bằng đúng Origin nhận được, và trả lời preflight với Access-Control-Allow-Private-Network: true như một thiết bị đã hỗ trợ PNA. Mỗi request được ghi một dòng JSON gồm method, URL, Origin và các header preflight.

Trang public thật

Trang gọi là https://example.com. Đây là trang HTTPS trên mạng public, nên trình duyệt xếp nó vào không gian public. Lab không sửa trang, chỉ chạy một đoạn JavaScript trong ngữ cảnh của trang qua Playwright. Đoạn mã đó thay cho mã của một công cụ quản trị thiết bị thật.

Năm kiểu request

Đoạn JavaScript gửi năm request tới 127.0.0.1:9892: fetch cors, fetch no-cors, fetch với targetAddressSpace loopback, fetch với targetAddressSpace local (cố ý sai không gian), và POST JSON cần preflight CORS. Mỗi request có thời gian chờ 7 giây.

r.push(await tryf('cors', T + '/ping?k=cors', {}));
r.push(await tryf('no-cors', T + '/ping?k=nocors', {mode: 'no-cors'}));
r.push(await tryf('tas=loopback', T + '/ping?k=tas', {targetAddressSpace: 'loopback'}));
r.push(await tryf('tas=local (sai)', T + '/ping?k=taslocal', {targetAddressSpace: 'local'}));
r.push(await tryf('POST json', T + '/ping?k=post',
  {method: 'POST', headers: {'content-type': 'application/json'}, body: '{}'}));

Truy vấn quyền trước và sau

Trước và sau năm request, đoạn mã gọi navigator.permissions.query với ba tên quyền. Nhờ vậy thấy được trạng thái ban đầu và việc trạng thái có đổi sau khi trình duyệt xử lý lời nhắc hay không.

Ba trạng thái quyền

Ba ca quyền trong Chrome

Ca mặc định không đặt quyền. Ca granted và ca denied đặt quyền trước bằng lệnh Browser.setPermission của giao thức DevTools cho origin https://example.com. Lệnh này thay cho cú nhấp Allow hoặc Block của người dùng trên lời nhắc.

await cdp.send("Browser.setPermission", {
    "permission": {"name": "local-network-access"},
    "setting": "granted",
    "origin": "https://example.com"})

Vì sao chọn 127.0.0.1

Đích loopback là trường hợp dễ dựng nhất mà không chạm thiết bị nào của người khác trong mạng. Theo đặc tả, loopback là không gian riêng tư nhất. Request từ public tới loopback thuộc nhóm bị chặn ngay từ mốc đầu, nên đủ để kiểm cơ chế mà không cần router hay máy in thật.

Không có giao diện người dùng

Lab không mô phỏng cú nhấp trên lời nhắc vì ở headless lời nhắc không tồn tại. Lệnh setPermission đặt trạng thái giống như sau khi người dùng đã chọn. Hành vi trong lúc lời nhắc đang mở, ví dụ request có treo hay không, nằm ngoài phạm vi đo.

Hồ sơ tạm cho từng ca

Mỗi ca mở Chrome với một thư mục hồ sơ tạm mới. Quyền đã cấp ở ca này không rò sang ca khác. Hồ sơ Chrome của người dùng không bị đụng tới, nên không có quyền thật nào bị thay đổi trên máy.

Chế độ headless

Ở headless không có giao diện để hiện lời nhắc. Ca mặc định vì vậy cho thấy hành vi khi lời nhắc không được ai trả lời. Ở trình duyệt có giao diện, người dùng sẽ thấy lời nhắc và lựa chọn của họ quyết định kết quả.

Ghi console

Playwright thu mọi thông báo console của trang. Chrome ghi lý do chặn vào console dưới dạng thông báo CORS, kèm tên không gian địa chỉ. Đây là nguồn chẩn đoán chính, vì JavaScript chỉ nhận được TypeError: Failed to fetch.

So permission granted/denied và response network trace của Local Network Access trong Chrome

Đây là kết quả đo trên Chrome 156.0.8078.80.

Ca mặc định: prompt rồi denied

Trước request, cả ba tên quyền trả prompt. Cả năm request đều thất bại với TypeError: Failed to fetch trong 1 tới 2 mili giây. Sau request, quyền chuyển thành denied. Máy chủ không ghi dòng nào cho ca này, kể cả preflight.

Thông báo của Chrome

Console ghi cho fetch cors rằng truy cập từ origin https://example.com bị chặn bởi CORS policy, với lý do Permission was denied for this request to access the loopback address space. Thông báo có chữ CORS nhưng lý do là quyền LNA. Người chỉ đọc chữ CORS sẽ sửa sai chỗ.

Ca granted

Ba tên quyền trả granted. Fetch cors nhận 200 trong 4 mili giây. Fetch no-cors nhận phản hồi opaque. Fetch với targetAddressSpace loopback nhận 200. Máy chủ ghi đủ ba request GET, Origin là https://example.com.

Sai không gian bị chặn

Với targetAddressSpace local trong khi đích là 127.0.0.1, request thất bại cả khi quyền đã cấp. Console ghi rằng request có target IP address space là local nhưng tài nguyên lại ở không gian khác. Đúng như đặc tả, tùy chọn này không dùng để lách được kiểm tra.

POST cần preflight

POST JSON ở ca granted gửi được preflight OPTIONS tới máy chủ, với Access-Control-Request-Method: POST. Preflight không có header Access-Control-Request-Private-Network. Request thất bại vì máy chủ lab không trả Access-Control-Allow-Headers cho content-type. Đây là lỗi CORS thật, xảy ra sau khi LNA đã cho qua.

Ca denied

Ba tên quyền trả denied. Năm request đều thất bại ngay, console ghi cùng lý do permission was denied cho từng request. Máy chủ không ghi dòng nào. Kết quả giống ca mặc định ở headless, chỉ khác trạng thái ban đầu.

Ma trận quyền

Ma trận quyền

Bảng: Ma trận quyền

Request	prompt (headless)	granted	denied
fetch cors	Failed, không tới máy chủ	200	Failed, không tới máy chủ
fetch no-cors	Failed	opaque, tới máy chủ	Failed
targetAddressSpace loopback	Failed	200	Failed
targetAddressSpace local (sai)	Failed	Failed, sai không gian	Failed
POST JSON	Failed	preflight tới, CORS chặn	Failed
Trạng thái quyền sau ca	denied	granted	denied

Trạng thái được lưu theo origin

Trong ca mặc định, quyền chuyển từ prompt sang denied sau request đầu tiên và giữ nguyên cho bốn request sau. Bốn request đó không có cơ hội hỏi lại. Với người dùng thật đã bấm Block, trang sẽ gặp lỗi mãi cho tới khi người dùng tự mở cài đặt site để đổi lại.

Không request nào lộ ra khi bị từ chối

Ở ca mặc định và ca denied, log máy chủ trống. Request bị chặn trong trình duyệt trước khi mở kết nối. Thiết bị nội bộ không nhận được gì, nên không thể bị tấn công CSRF qua đường này. Đây là khác biệt lớn với no-cors thời trước, khi request vẫn tới thiết bị.

Thời gian thất bại

Mọi lượt thất bại đều trong vài mili giây, không có lượt nào chờ hết 7 giây. Ở headless, lời nhắc không hiện nên không có thời gian chờ người dùng. Ở trình duyệt có giao diện, request có thể treo cho tới khi người dùng chọn, điều lab chưa đo.

Tách cơ chế Local Network Access trong Chrome hiện hành khỏi PNA preflight thử nghiệm đã cũ

Phần này dùng kết quả để trả lời câu hỏi: header PNA còn giúp gì không.

Header PNA không cứu được request

PNA cũ và LNA mới

Máy chủ lab trả Access-Control-Allow-Private-Network: true cho mọi preflight. Ở ca mặc định và ca denied, request vẫn thất bại, vì preflight không hề được gửi. Thêm header này vào thiết bị không thay đổi gì với Chrome 156.

Preflight không mang header PNA

Ở ca granted, preflight của POST JSON tới máy chủ mà không có Access-Control-Request-Private-Network. Chrome 156 không còn hỏi thiết bị theo kiểu PNA. Preflight còn lại là preflight CORS bình thường, chỉ xảy ra khi request cần theo luật CORS.

Dấu hiệu tài liệu đã cũ

Một tài liệu đã cũ thường có ba dấu hiệu: bảo thêm Access-Control-Allow-Private-Network, gọi không gian nội bộ là private, và không nhắc lời nhắc cấp quyền. Gặp ba dấu hiệu này thì đối chiếu lại với bài viết của Chrome trước khi làm theo.

Thứ cần sửa ở trang

Trang public cần chạy trên HTTPS và chuẩn bị cho việc người dùng thấy lời nhắc. Với tên miền public trỏ về địa chỉ nội bộ, thêm targetAddressSpace đúng không gian để tránh mixed content. Thông báo cho người dùng vì sao trang cần quyền này giúp họ không bấm Block theo phản xạ.

Thứ cần sửa ở thiết bị

Thiết bị hoặc agent cục bộ vẫn cần CORS đúng: trả Access-Control-Allow-Origin cho đúng origin và Access-Control-Allow-Headers cho các header trang gửi. Ca POST JSON của lab thất bại chính vì thiếu header này. LNA không thay CORS.

Hỗ trợ người dùng cuối

Khi người dùng báo công cụ không kết nối được agent, bước đầu tiên là hỏi họ có thấy lời nhắc truy cập mạng nội bộ không và đã chọn gì. Nếu đã chọn Block, hướng dẫn họ mở biểu tượng cài đặt site cạnh thanh địa chỉ để đổi quyền. Bước này giải quyết nhiều ca hơn mọi thay đổi ở thiết bị.

Thông báo trong trang

Trang có thể gọi navigator.permissions.query trước khi gửi request. Nếu trạng thái là denied, hiện hướng dẫn đổi quyền thay vì báo lỗi kết nối chung. Nếu là prompt, giải thích trước vì sao trang cần truy cập mạng nội bộ. Lab cho thấy ba tên quyền đều truy vấn được trên Chrome 156.

Trình duyệt nhúng và trình duyệt khác

Kết quả ERR_BLOCKED_BY_CLIENT trên trình duyệt nhúng nhắc rằng không phải mọi trình duyệt nền Chromium đều có cùng lớp chặn. Ứng dụng nhúng có thể có chính sách riêng. Firefox và Safari có lộ trình riêng. Bài chỉ khẳng định về Chrome 156.

Đầu ra nghiệm thu Local Network Access trong Chrome: ma trận quyền granted/denied public-to-local và network trace có phiên bản Chrome

Phần này gom đầu ra thành bản ghi có thể lưu.

Tệp đầu ra

Lab sinh pw_result.json gồm phiên bản Chrome, trạng thái quyền trước và sau, kết quả từng request và toàn bộ console của từng ca. Kèm theo là log.jsonl của máy chủ, nơi thấy request nào thật sự tới. Hai tệp đủ để người khác kiểm lại ma trận.

Danh sách kiểm tra

Danh sách nghiệm thu

• Phiên bản Chrome được đọc từ trình duyệt và ghi cùng kết quả.
• Trang gọi là trang public thật, không dùng mẹo CSP cũ.
• Có đủ ba trạng thái quyền, mỗi trạng thái một hồ sơ tạm.
• Log máy chủ xác nhận request nào tới, request nào không.
• Có ca targetAddressSpace sai không gian.
• Có ca preflight CORS để tách lỗi CORS khỏi lỗi quyền.
• Kết quả trình duyệt nhúng ghi riêng, không trộn vào ma trận.

Những gì lab chưa chạy

Chưa thử trình duyệt có giao diện với lời nhắc thật. Chưa thử thiết bị ở dải 192.168.x.x hay tên .local. Chưa thử iframe, ảnh, WebSocket, WebRTC, Service Worker. Chưa thử chính sách doanh nghiệp. Chưa thử trang HTTP public. Chưa thử Edge, Firefox, Safari.

Câu kết luận được phép viết

Câu được phép viết là: trên Chrome 156.0.8078.80, fetch từ https://example.com tới 127.0.0.1 bị chặn trước khi tới máy chủ khi quyền chưa được cấp, và đi qua khi quyền là granted. Câu không được phép viết là: mọi trình duyệt chặn request này. Lab có một trình duyệt nhúng chặn theo cách khác.

Vận hành công cụ và crawler với Local Network Access trong Chrome

Phần này chuyển kết quả lab thành việc cần làm cho người dùng Chrome tự động hóa.

Tự động hóa trình duyệt

Kịch bản Playwright hoặc Puppeteer mở trang public rồi gọi dịch vụ cục bộ, ví dụ một bộ giải mã chạy ở 127.0.0.1, sẽ thất bại ở Chrome mới nếu không cấp quyền. Ở headless, lời nhắc không hiện và quyền chuyển thành denied như ca mặc định của lab. Cấp quyền bằng Browser.setPermission cho đúng origin khi chạy thử.

Không cấp quyền cho mọi origin

Lệnh setPermission trong lab chỉ cấp cho https://example.com. Không nên cấp quyền mạng nội bộ cho mọi origin trong hồ sơ dùng để duyệt web chung. Một hồ sơ riêng cho kịch bản và một danh sách origin được phép giữ đúng mục đích bảo vệ của LNA.

Proxy không đổi không gian địa chỉ

Trang public đi qua proxy vẫn là trang public. Proxy chuyển tiếp HTTP hay SOCKS chỉ đổi đường đi ra Internet. Request tới 127.0.0.1 hay mạng nội bộ không đi qua proxy theo cấu hình thông thường, và LNA được xét ở trình duyệt trước đó. Đổi proxy không giải quyết lỗi quyền.

Bỏ qua proxy cho địa chỉ nội bộ

Khi trình duyệt dùng proxy, danh sách bỏ qua proxy nên có localhost, 127.0.0.1 và dải nội bộ. Nếu không, request tới thiết bị nội bộ có thể bị gửi lên proxy và thất bại theo cách khác, làm lẫn lỗi proxy với lỗi quyền. Cách ghi danh sách có ở bài định dạng proxy.

Đọc console thay vì đọc mã lỗi

TypeError: Failed to fetch là chung cho mọi nguyên nhân. Thông báo console có tên không gian địa chỉ là chỗ phân biệt lỗi quyền với lỗi CORS và lỗi mạng. Kịch bản tự động nên thu console như lab đã làm.

Ghi phiên bản vào mọi báo cáo

Cơ chế này còn đang mở rộng sang WebSocket, WebRTC và request nội bộ với nhau. Mỗi báo cáo lỗi nên có phiên bản Chrome. Lỗi chưa có ở bản này có thể xuất hiện ở bản sau, và ngược lại.

Kiểm lại sau mỗi bản Chrome

Giữ pw.py và srv.py như một bài test. Sau mỗi bản Chrome lớn, chạy lại ba ca và so ma trận. Khi Chrome mở rộng LNA sang request nội bộ với nhau hay WebSocket, các dòng mới cần được thêm vào ma trận thay vì đoán.

Proxy ở đâu trong luồng

Proxy phục vụ phần đi ra Internet của kịch bản, không phải phần nói chuyện với dịch vụ cục bộ. Khi cần IP tại Việt Nam cho phần đó, anh em có thể mua proxy tại trang chủ ProxyVN. Vai trò của proxy có ở bài Web Scraping proxy là gì, còn chuyện CORS khi đi qua proxy có ở bài CORS và proxy.

Local Network Access trong Chrome: câu hỏi thường gặp

Các câu dưới đây gom những điểm hay bị hỏi.

Thêm Access-Control-Allow-Private-Network có sửa được lỗi không?

Không với Chrome 156 trong lab. Request bị chặn trước khi preflight được gửi.

Quyền mặc định là gì?

Prompt. Ở headless, lời nhắc không hiện và quyền chuyển thành denied sau request đầu tiên.

Request bị từ chối có tới thiết bị không?

Không. Log máy chủ trống ở cả ca mặc định và ca denied.

targetAddressSpace có dùng để lách được không?

Không. Ghi sai không gian thì request thất bại cả khi quyền đã cấp.

Đã cấp quyền mà vẫn lỗi thì sao?

Xem lỗi CORS. Trong lab, POST JSON qua được quyền nhưng bị CORS chặn vì thiếu Access-Control-Allow-Headers.

Trang chạy trên localhost gọi 127.0.0.1 có bị chặn không?

Lab chỉ đo ca này trên trình duyệt nhúng Chromium 152 và request đi qua. Đặc tả ghi Chromium chưa áp quyền cho request giữa hai địa chỉ nội bộ.

Proxy có giúp vượt lời nhắc này không?

Không. LNA được xét ở trình duyệt theo không gian địa chỉ của trang và đích, không theo IP đi ra.

Local Network Access trong Chrome và những điều cần nhớ

Local Network Access trong Chrome đặt request từ trang public tới loopback và mạng nội bộ sau quyền của người dùng, thay cho preflight PNA đã dừng. Lab trên Chrome 156 cho thấy quyền chưa cấp thì request không tới máy chủ, quyền granted thì request đi qua và CORS vẫn áp dụng. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khuyên anh em khóa phiên bản Chrome khi chẩn đoán Local Network Access trong Chrome.