Ngiêm cấm sử đụng PROXY và VPS vào mục đích trái pháp luật bạn sẽ phải chịu toàn bộ trách nhiệm trước pháp luật khi sử dụng dịch vụ của chúng tôi tks!
Lỗi CSP connect-src: đọc báo cáo, khoanh vùng, sửa đúng chỗ

Lỗi CSP connect-src: đọc báo cáo, khoanh vùng và sửa đúng chỗ

Chuyên viên Kỹ thuật ProxyVN 09-25-2026 Đang tính... phút đọc

Lỗi CSP connect-src xảy ra khi Content Security Policy của trang không cho mã JavaScript kết nối tới một địa chỉ. Trình duyệt chặn fetch, WebSocket hay EventSource ngay từ phía máy khách, máy chủ đích không nhận gì. ProxyVN dựng trang lab có CSP và điểm nhận báo cáo, chạy 12 phép kết nối trong Chrome 152 để anh em phân biệt lỗi này với CORS và với proxy mạng.

Lỗi CSP connect-src: lớp nào quyết định hành vi

Ba lỗi hay bị nhầm khi một request từ trang web thất bại là CSP, CORS và lỗi proxy. Cả ba đều làm JavaScript nhận thông báo "Failed to fetch". Muốn sửa đúng, anh em cần biết lỗi đang nằm ở lớp nào.

CSP là chính sách do chính trang khai báo

Content Security Policy là header mà máy chủ gửi kèm trang HTML. Header này liệt kê nguồn nào trang được tải và được kết nối tới. Trình duyệt đọc chính sách rồi áp cho mọi hành động của trang đó.

Theo trang connect-src của MDN, chỉ thị này giới hạn các URL được nạp qua giao diện script. Danh sách gồm fetch, fetchLater, XMLHttpRequest, WebSocket, EventSource, Navigator.sendBeacon và thuộc tính ping của thẻ a. Nếu thiếu connect-src, trình duyệt dùng default-src.

Lỗi CSP connect-src do chính trang của anh em gây ra, không phải do máy chủ bên kia. Đây là khác biệt gốc với CORS, nơi máy chủ bên kia quyết định có cho đọc hay không.

CORS do máy chủ đích quyết định

Với CORS, trình duyệt vẫn gửi request đơn giản tới máy chủ đích. Máy chủ trả phản hồi, trình duyệt kiểm header Access-Control-Allow-Origin rồi mới quyết định cho JavaScript đọc. Sửa CORS là sửa header phía API.

Với CSP, trình duyệt kiểm trước khi gửi. URL không khớp chính sách thì không có gói tin nào rời máy. Sửa CSP là sửa header của trang đang chạy mã.

Proxy chỉ ở lớp mạng

Proxy HTTP hay SOCKS chỉ đổi đường đi của kết nối đã được trình duyệt cho phép. Request bị CSP chặn chưa bao giờ tới proxy. Đổi proxy, tắt proxy hay mua proxy khác đều không làm thay đổi kết quả.

Ngược lại, khi proxy hỏng, trình duyệt báo lỗi mạng như net::ERR_PROXY_CONNECTION_FAILED. Lỗi này không có dòng "violates the following Content Security Policy directive". Đọc nguyên văn console là bước đầu tiên để tách hai nhóm lỗi.

Ranh giới với bài đã có

Bài WebSocket qua HTTP proxy nói về cách WebSocket đi qua proxy ở tầng mạng. Bài reverse proxy là gì có nhắc CSP như một header reverse proxy có thể thêm. Bài này chỉ đi vào connect-src: cách trình duyệt so URL, cách đọc báo cáo vi phạm và cách khoanh vùng khi kết nối bị chặn.

Lỗi CSP connect-src khác CORS và lỗi proxy mạng ở dấu hiệu nào

CSP chặn trước khi gửi

CSP chặn trước khi gửi

Ba lớp lỗi để lại dấu vết ở ba chỗ khác nhau. Bảng dưới đặt các dấu hiệu cạnh nhau, dựa trên kết quả lab ở các phần sau. Anh em dò theo cột đầu để biết đang gặp lớp nào.

Bảng: Lỗi CSP connect-src khác CORS và lỗi proxy mạng ở dấu hiệu nào

Dấu hiệu

Lỗi CSP connect-src

Lỗi CORS

Lỗi proxy mạng

Console

violates the following Content Security Policy directive

blocked by CORS policy

net::ERR_PROXY_CONNECTION_FAILED hoặc tương tự

Máy chủ đích có log

Không

Có, với request đơn giản

Không

Có báo cáo vi phạm gửi về

Có, nếu khai báo report-uri hoặc report-to

Không

Không

Sự kiện securitypolicyviolation

Có

Không

Không

Ai sửa

Chủ trang

Chủ API

Người quản trị mạng hoặc proxy

Ảnh hưởng của curl

curl gọi được, vì curl không đọc CSP

curl gọi được

curl qua cùng proxy cũng lỗi

Cột máy chủ đích là cột quan trọng nhất

Khi không chắc, mở log máy chủ đích. Có log 200 thì nghiêng về CORS. Không có log nào thì nghiêng về CSP hoặc lỗi mạng, và console sẽ cho biết là cái nào.

Trong lab, request bị CSP chặn không để lại dòng nào ở máy chủ B. Request bị CORS chặn ở bài trước vẫn để lại dòng GET với mã 200. Đặt hai log cạnh nhau là cách nhanh nhất thuyết phục cả nhóm phát triển rằng lỗi nằm ở đâu.

Vì sao curl không giúp chẩn đoán CSP

curl không tải trang HTML, không đọc header CSP và không chạy JavaScript. Một lệnh curl thành công chỉ chứng minh URL đích sống. Nó không nói gì về việc trang có được phép kết nối tới URL đó hay không.

Muốn tái hiện lỗi CSP connect-src, phải chạy trong trình duyệt, trên đúng trang có header CSP. Thử trong một tab khác, hay trang khác cùng tên miền nhưng khác CSP, sẽ cho kết quả khác.

Thiết kế lab lỗi CSP connect-src và kết quả kỳ vọng

Lab dùng lại hai máy chủ Python của bài CORS, thêm trang có header CSP và điểm nhận báo cáo. Cả hai phía đều ghi log ra tệp JSON. Cổng lab là 9500 và 9501, trình duyệt là khung trình duyệt của ứng dụng Claude, user agent Chrome 152.0.7977.167.

Chính sách thử nghiệm

Trang http://127.0.0.1:9500/csp trả header dưới đây. Chính sách cho phép kết nối tới chính origin của trang và đúng một đường dẫn trên API B.

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline';
  connect-src 'self' http://localhost:9501/api/ok; report-uri /csp-report

script-src có 'unsafe-inline' chỉ vì trang lab viết mã trực tiếp trong thẻ script. Trên trang thật, anh em nên dùng nonce hoặc tệp script riêng. connect-src là phần cần thử, nên các chỉ thị khác giữ đơn giản.

Điểm nhận báo cáo và sự kiện trong trang

Máy chủ A nhận POST tại /csp-report và ghi nguyên thân báo cáo. Trong trang, một đoạn mã lắng nghe sự kiện securitypolicyviolation để ghi vi phạm ngay phía trình duyệt. Hai nguồn này giúp đối chiếu khi một trong hai không về.

window.csp = [];
document.addEventListener("securitypolicyviolation",
  e => window.csp.push(e.violatedDirective + " " + e.blockedURI));

Ma trận kỳ vọng

Trước khi chạy, ProxyVN ghi kết quả kỳ vọng theo MDN. URL khớp nguồn được liệt kê phải chạy. URL cùng máy nhưng khác đường dẫn phải bị chặn, vì nguồn có đường dẫn cụ thể chỉ khớp đúng đường dẫn đó.

URL đổi từ localhost sang 127.0.0.1 phải bị chặn, vì CSP so tên máy theo chuỗi. WebSocket tới origin của trang là điểm cần quan sát, vì MDN ghi 'self' không phải trình duyệt nào cũng tính cho giao thức ws. Request bị chặn không được xuất hiện trong log máy chủ B.

Tái lập lỗi CSP connect-src: ca thành công và ca bị chặn

Phép thử chạy ngày 29/10/2026 trong một tab, các lệnh chạy nối tiếp. Mỗi ca ghi kết quả JavaScript, có hay không dòng log ở máy chủ, và vi phạm mà trang bắt được. Phần đầu là chế độ thực thi, phần sau là Report-Only và redirect.

Mã thử các API kết nối

const B = "http://localhost:9501";
await run("1 ok trong connect-src", B + "/api/ok");
await run("2 star ngoai connect-src", B + "/api/star");
await run("3 relay self", "/relay/books");
await run("4 127.0.0.1 khac host", "http://127.0.0.1:9501/api/ok");
new WebSocket("ws://127.0.0.1:9500/sock");
new WebSocket("ws://localhost:9501/sock");
new EventSource(B + "/api/star");
navigator.sendBeacon(B + "/api/star", "x");

Hàm run bọc fetch và trả về trạng thái hoặc tên lỗi. Hai WebSocket và EventSource được bọc trong Promise có hạn chờ 3 giây để ghi sự kiện onerror hoặc onopen.

Bảng kết quả chế độ thực thi

Ma trận origin được và không được

Ma trận origin được và không được

Bảng: Bảng kết quả chế độ thực thi

Ca

Kết quả trong trang

Log máy chủ

Vi phạm CSP

1. fetch localhost:9501/api/ok

200, đọc được

B ghi GET

Không

2. fetch localhost:9501/api/star

TypeError: Failed to fetch

B không có dòng nào

connect-src, gửi báo cáo

3. fetch /relay/books cùng origin

200

A ghi relay, B ghi GET từ phía server

Không

4. fetch 127.0.0.1:9501/api/ok

TypeError

B không có dòng nào

connect-src

5. WebSocket ws://127.0.0.1:9500/sock

onerror do máy chủ không hỗ trợ WebSocket

A ghi GET /sock

Không

6. WebSocket ws://localhost:9501/sock

onerror

B không có dòng nào

connect-src

7. EventSource localhost:9501/api/star

onerror, readyState 2

B không có dòng nào

connect-src

8. sendBeacon localhost:9501/api/star

Hàm trả true

B không có dòng nào

connect-src

Năm ca bị chặn đều để lại báo cáo POST về /csp-report. Máy chủ B chỉ ghi một request trong suốt phần này, là ca 1. Ca 3 cũng tới B nhưng do máy chủ A gọi, không qua trình duyệt.

Ca 5: 'self' có tính WebSocket

Ca 5 cho thấy Chrome 152 coi ws://127.0.0.1:9500 khớp với 'self' của trang http://127.0.0.1:9500. Không có vi phạm, và máy chủ A nhận request GET /sock. WebSocket lỗi vì máy chủ lab không hỗ trợ nâng cấp kết nối, không phải vì CSP.

Đặc tả CSP Level 3 của W3C cho phép 'self' khớp ws và wss tương ứng với http và https. MDN vẫn cảnh báo không phải trình duyệt nào cũng làm vậy. Nếu ứng dụng phải chạy trên nhiều trình duyệt, ghi rõ wss://tên-miền vào connect-src thay vì dựa vào 'self'.

Ca 8: sendBeacon trả true nhưng không gửi

sendBeacon trả về true trong ca 8, dù CSP đã chặn. Giá trị true chỉ nghĩa là trình duyệt đã nhận yêu cầu vào hàng đợi. Log máy chủ B không có dòng nào, còn trang ghi được một vi phạm connect-src.

Đừng dựa vào giá trị trả về của sendBeacon để biết dữ liệu đã tới máy chủ. Với CSP chặn, hàm vẫn trả true mà không gói tin nào rời trình duyệt.

Đây là kiểu lỗi âm thầm hay gặp ở mã gửi số liệu phân tích. Trang không báo lỗi, người dùng không thấy gì, nhưng bảng số liệu mất dữ liệu. Báo cáo CSP là nguồn duy nhất cho biết chuyện này đang xảy ra.

Thông báo console nguyên văn

Chrome ghi hai dòng cho mỗi fetch bị chặn. Dòng thứ nhất nêu URL và chỉ thị bị vi phạm. Dòng thứ hai là của Fetch API, nói từ chối kết nối vì vi phạm Content Security Policy của tài liệu.

Connecting to 'http://localhost:9501/api/star' violates the following Content Security
Policy directive: "connect-src 'self' http://localhost:9501/api/ok". The action has been blocked.
Fetch API cannot load http://localhost:9501/api/star. Refused to connect because it
violates the document's Content Security Policy.

WebSocket bị CSP chặn chỉ có dòng "Connecting to ... violates". WebSocket lỗi vì máy chủ ở ca 5 có dòng khác hẳn: WebSocket connection to 'ws://127.0.0.1:9500/sock' failed. Hai dòng này đủ để tách lỗi chính sách khỏi lỗi kết nối.

Report-Only và redirect trong lab lỗi CSP connect-src

Hai tình huống sau hay gây bối rối khi triển khai CSP thật. Report-Only cho phép thử chính sách mà không chặn. Redirect làm URL cuối khác URL ban đầu, và CSP xử lý chuyện này theo cách riêng.

Content-Security-Policy-Report-Only

Trang /csp?ro=1 gửi cùng chính sách nhưng bằng header Content-Security-Policy-Report-Only. Fetch tới /api/star lần này thành công với mã 200, và máy chủ B ghi request. Máy chủ A vẫn nhận một báo cáo, trường disposition có giá trị report thay vì enforce.

Theo hướng dẫn CSP của MDN, Report-Only dùng để thử chính sách mới trước khi bật thật. Nếu trang có cả hai header, chính sách thường được thực thi, còn chính sách Report-Only chỉ gửi báo cáo. Cách triển khai an toàn là chạy Report-Only vài ngày, đọc báo cáo, rồi mới chuyển sang thực thi.

Trong lần thử này, sự kiện securitypolicyviolation trong trang được ghi hai lần cho cùng URL, còn máy chủ nhận một báo cáo. Vì vậy đếm vi phạm nên dựa vào báo cáo phía máy chủ, không cộng sự kiện phía trang.

Redirect cùng máy, khác đường dẫn

Máy chủ B được sửa để /api/ok?go=star trả 302 sang /api/star. URL ban đầu khớp nguồn http://localhost:9501/api/ok, vì query string không tham gia so khớp. Sau redirect, trình duyệt cho phép tải /api/star và JavaScript nhận 200.

Kết quả này khớp quy tắc của CSP Level 3: sau redirect, phần đường dẫn của nguồn không còn được so. Chỉ giao thức, tên máy và cổng được kiểm. Quy tắc này tồn tại để chính sách không làm lộ đường dẫn redirect qua báo cáo vi phạm.

Nguồn có đường dẫn trong connect-src không chặn được redirect sang đường dẫn khác trên cùng máy. Muốn giới hạn chặt theo đường dẫn, kiểm tra phải nằm ở máy chủ, không trông vào CSP.

Redirect sang máy khác

/api/ok?go=host trả 302 sang http://127.0.0.1:9501/api/star. Lần này trình duyệt chặn bước redirect, JavaScript nhận TypeError. Log B có request đầu tiên tới /api/ok?go=host nhưng không có request thứ hai.

Vi phạm ghi trong trang mang URL ban đầu là http://localhost:9501/api/ok?go=host, không phải URL đích của redirect. Khi đọc báo cáo của một lỗi CSP connect-src, anh em cần biết URL trong báo cáo có thể là URL trước redirect. Mở tab Network để thấy chuỗi redirect đầy đủ.

report-to và Reporting-Endpoints

Trang /csp?rt=1 thay report-uri bằng report-to lab, kèm header Reporting-Endpoints trỏ về http://127.0.0.1:9500/csp-report-to. Theo trang report-to của MDN, báo cáo kiểu mới gửi bằng POST với Content-Type application/reports+json. Trình duyệt hỗ trợ report-to sẽ bỏ qua report-uri.

Trong lab, sau khoảng 90 giây chờ, máy chủ không nhận báo cáo report-to nào. Vi phạm vẫn hiện trong console và sự kiện trong trang. ProxyVN chưa xác định nguyên nhân, có thể do cách Reporting API gom và gửi báo cáo theo lô hoặc do điều kiện với điểm nhận http. Bài ghi nhận kết quả, không suy ra quy tắc.

Lời khuyên thực tế từ MDN là khai báo cả report-uri và report-to trong giai đoạn chuyển tiếp. Điểm nhận nên chạy trên HTTPS, nhận cả hai Content-Type application/csp-report và application/reports+json. Đừng kết luận chính sách không có vi phạm chỉ vì một kênh báo cáo im lặng.

Đọc báo cáo và log để khoanh vùng lỗi CSP connect-src

Đọc báo cáo vi phạm

Đọc báo cáo vi phạm

Một báo cáo vi phạm chứa đủ thông tin để biết dòng mã nào kết nối tới đâu. Phần này đọc một báo cáo thật từ lab rồi nêu cách gom báo cáo trên hệ thống thật. Đọc đúng báo cáo giúp anh em sửa chính sách hẹp nhất có thể.

Báo cáo report-uri thật từ lab

Báo cáo dưới đây máy chủ A nhận ở ca 2, Content-Type là application/csp-report. ProxyVN giữ nguyên các trường, chỉ xuống dòng cho dễ đọc.

{"csp-report": {
  "document-uri": "http://127.0.0.1:9500/csp",
  "violated-directive": "connect-src",
  "effective-directive": "connect-src",
  "original-policy": "default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src 'self' http://localhost:9501/api/ok; report-uri /csp-report",
  "disposition": "enforce",
  "blocked-uri": "http://localhost:9501/api/star",
  "line-number": 5, "column-number": 25,
  "source-file": "http://127.0.0.1:9500/csp",
  "status-code": 200}}

blocked-uri cho biết URL bị chặn. source-file, line-number và column-number chỉ tới đúng dòng mã gọi fetch. original-policy giúp biết trang đang chạy bản chính sách nào, rất hữu ích khi nhiều máy chủ trả các bản CSP khác nhau.

Các trường cần gom khi chạy thật

  • blocked-uri: gom theo tên máy để biết dịch vụ nào đang bị chặn nhiều nhất.
  • document-uri: biết trang nào sinh vi phạm, nhiều khi chỉ một trang cũ còn gọi API cũ.
  • disposition: tách enforce khỏi report, tránh hoảng vì vi phạm từ chính sách đang thử.
  • source-file: nếu là tệp của tiện ích trình duyệt hay của bên thứ ba, có thể không phải lỗi của ứng dụng.
  • original-policy: phát hiện máy chủ hoặc CDN trả bản chính sách cũ.

Báo cáo đến từ trình duyệt người dùng, nên có cả nhiễu từ tiện ích mở rộng. Tiện ích chèn mã vào trang rồi kết nối ra ngoài, sinh vi phạm không liên quan tới mã của anh em. Lọc theo source-file trước khi thêm nguồn vào chính sách.

Điểm nhận báo cáo tối thiểu

Điểm nhận báo cáo của lab chỉ vài dòng Python, đoạn dưới thêm giới hạn đọc 64 KB so với bản đã chạy. Nó nhận POST, ghi Content-Type cùng thân báo cáo, rồi trả 204. Trên hệ thống thật, anh em thêm giới hạn kích thước thân và giới hạn tốc độ theo IP.

def do_POST(self):
    n = int(self.headers.get("Content-Length", 0) or 0)
    body = self.rfile.read(min(n, 65536)).decode("utf-8", "replace")
    if self.path.startswith("/csp-report"):
        log(kind="csp-report", ctype=self.headers.get("Content-Type"), body=body[:600])
        return self._send(204, b"")
    self._send(404, "no")

Báo cáo có thể bị người ngoài gửi giả, vì điểm nhận là URL công khai ghi ngay trong header. Đừng dùng số báo cáo làm căn cứ tự động mở rộng chính sách. Báo cáo là tín hiệu để người xem xét, không phải lệnh để hệ thống tự thêm nguồn.

Nên tách điểm nhận khỏi máy chủ ứng dụng chính. Một trang lỗi có thể sinh hàng nghìn báo cáo mỗi phút khi có nhiều người dùng. Đặt điểm nhận ở dịch vụ riêng giúp đợt báo cáo dồn dập không làm chậm ứng dụng.

Khi gom báo cáo, lưu theo ngày và theo bản chính sách. Mỗi lần đổi CSP, so số vi phạm trước và sau để biết thay đổi có mở đúng chỗ không. Số vi phạm của một nguồn tụt về không sau khi thêm nguồn đó là dấu hiệu sửa đúng.

Tab Network và Issues trong DevTools

Tab Network hiện request bị CSP chặn với trạng thái blocked kèm lý do csp. Request bị CORS chặn có trạng thái CORS error. Hai nhãn này đủ để phân loại mà không cần đọc log máy chủ.

Bảng Issues của DevTools gom các vi phạm CSP theo chỉ thị. Khi trang có nhiều vi phạm, bảng này giúp thấy nhanh chỉ thị nào cần sửa. Ghi lại phiên bản trình duyệt khi chụp màn hình, vì giao diện DevTools thay đổi giữa các bản.

Lỗi proxy nhìn trông thế nào

Để đối chiếu, lỗi proxy ở tầng mạng không sinh báo cáo CSP, không có sự kiện securitypolicyviolation. Console ghi mã lỗi net:: như ERR_PROXY_CONNECTION_FAILED hay ERR_TUNNEL_CONNECTION_FAILED. Mọi request ra ngoài cùng lúc lỗi, không chỉ một URL.

Nếu chỉ một vài tên miền lỗi qua proxy, kiểm danh sách bỏ qua proxy như bài no_proxy là gì hướng dẫn. Còn nếu lỗi chỉ xảy ra với một URL và console nhắc Content Security Policy, proxy không liên quan.

Sửa lỗi CSP connect-src theo bằng chứng

Khi đã chắc lỗi nằm ở CSP, cách sửa là thêm đúng nguồn cần thiết vào connect-src. Phần này nêu thứ tự sửa và những cách sửa nên tránh. Mỗi thay đổi nên đi qua Report-Only trước khi thực thi.

Thêm nguồn hẹp nhất

Nguồn hẹp nhất là giao thức cộng tên máy cộng cổng, ví dụ https://api.vi-du.test. Thêm đường dẫn nếu muốn hẹp hơn, nhưng nhớ quy tắc redirect ở trên. Tránh thêm cả tên miền gốc với dấu sao như https://*.vi-du.test nếu chỉ cần một máy.

Với WebSocket, ghi rõ wss://tên-máy. Với API dùng cả HTTP và WebSocket trên cùng tên máy, cần hai nguồn https:// và wss://. Kết quả ca 5 cho thấy Chrome nối 'self' sang ws, nhưng không nên mở rộng điều đó cho tên máy khác.

Những cách sửa nên tránh

  • Thêm dấu sao vào connect-src: trang được kết nối tới mọi nơi, mất tác dụng chống rò dữ liệu.
  • Thêm https: không kèm tên máy: tương đương mọi máy chủ HTTPS.
  • Xóa hẳn header CSP để "cho chạy": mất cả bảo vệ script-src và các chỉ thị khác.
  • Chuyển sang Report-Only vĩnh viễn: chính sách không còn chặn gì.

Mỗi cách trên đều làm lỗi biến mất, nhưng đổi lại là mở rộng bề mặt tấn công. connect-src là một trong những chỉ thị ngăn mã độc chèn vào trang gửi dữ liệu người dùng ra ngoài. Mở rộng nó cần lý do cụ thể cho từng nguồn.

CSP do ai đặt

Header CSP có thể đến từ ứng dụng, từ reverse proxy hay từ CDN đứng trước. Khi sửa ở ứng dụng mà header vẫn cũ, kiểm xem Nginx, Cloudflare hay một lớp khác có ghi đè không. Trường original-policy trong báo cáo cho biết trình duyệt đang nhận bản nào.

CSP còn có thể khai báo bằng thẻ meta http-equiv trong HTML. MDN ghi cách này không hỗ trợ đủ tính năng, ví dụ không dùng được report-to. Nếu trang có cả header và thẻ meta, trình duyệt áp cả hai chính sách, kết nối phải qua được cả hai.

Kiểm sau khi sửa

Sau khi thêm nguồn, chạy lại ma trận thử như lab: URL được phép phải chạy, URL ngoài danh sách vẫn phải bị chặn. Phép thử thứ hai hay bị bỏ qua, nhưng nó xác nhận chính sách không bị mở quá tay. Lưu ma trận vào kho mã để chạy lại mỗi lần đổi CSP.

Lỗi CSP connect-src trong ứng dụng có proxy và tiện ích

Một số tình huống làm lỗi CSP connect-src lẫn vào chuyện proxy. Phần này nêu những tình huống ProxyVN thấy dễ gây nhầm. Không có tình huống nào trong số này được sửa bằng cách đổi proxy.

Tiện ích proxy của trình duyệt

Tiện ích quản lý proxy trên Chrome chỉ đổi đường đi của kết nối trình duyệt đã cho phép. Nó không đổi CSP của trang. Một trang bị lỗi CSP connect-src khi bật tiện ích proxy sẽ vẫn lỗi khi tắt tiện ích.

Có trường hợp ngược lại: tiện ích chèn mã vào trang để gọi API của chính tiện ích, rồi bị CSP của trang chặn. Báo cáo vi phạm khi đó có source-file là tệp của tiện ích. Đây là lỗi của tiện ích, chủ trang không cần sửa.

Proxy công ty chèn header

Một số proxy chặn TLS của doanh nghiệp có thể sửa header phản hồi, kể cả thêm hoặc xóa CSP. Khi trang chạy khác nhau giữa mạng công ty và mạng ngoài, so header CSP nhận được ở hai nơi. Lệnh curl -I qua cùng proxy cho thấy header proxy trả về.

Trường hợp này hiếm, nhưng khi gặp thì báo cáo vi phạm sẽ có original-policy khác với chính sách máy chủ thật gửi. Đó là bằng chứng để làm việc với bộ phận mạng. Ngoài trường hợp này, proxy không tham gia vào CSP.

Ứng dụng thu thập dữ liệu chạy trong trình duyệt

Khi dùng Playwright hay Puppeteer để thu thập dữ liệu, mã chạy trong trang bằng page.evaluate cũng chịu CSP của trang đó. fetch từ evaluate tới API của anh em có thể bị chặn. Các thư viện này có tùy chọn bỏ qua CSP cho phiên tự động, ví dụ bypassCSP trong Playwright, nhưng chỉ nên dùng trên trang mình được phép tự động hóa.

Cách gọn hơn là không fetch từ trong trang, mà đọc dữ liệu ra rồi gửi từ phía Node hay Python. Request phía script không chịu CSP. Proxy cho script khi đó cấu hình ở tầng thư viện như bài định dạng proxy mô tả.

Với các tác vụ chạy từ máy chủ cần IP Việt Nam ổn định qua HTTP hoặc SOCKS5, anh em có thể mua proxy tại trang chủ ProxyVN. Proxy giúp phần kết nối ra ngoài của script, còn lỗi CSP connect-src trong trang vẫn phải sửa ở header của trang.

Checklist lỗi CSP connect-src và giới hạn của lab

Danh sách sau gom các bước từ lab, xếp theo thứ tự nên làm khi gặp lỗi mới. Phần cuối nêu những gì lab chưa thử. Anh em đối chiếu trước khi áp kết quả cho trình duyệt khác.

Checklist khoanh vùng

Checklist lỗi CSP connect-src

Checklist lỗi CSP connect-src

  • Đọc nguyên văn console: có cụm "violates the following Content Security Policy directive" không.
  • Mở log máy chủ đích: request có tới không.
  • Xem tab Network: nhãn csp hay CORS error.
  • Đọc báo cáo vi phạm: blocked-uri, source-file, original-policy.
  • Kiểm header CSP thật trình duyệt nhận, kể cả thẻ meta và header do CDN thêm.
  • Xác định API bị chặn: fetch, WebSocket, EventSource hay sendBeacon.
  • Thêm nguồn hẹp nhất, thử bằng Report-Only, rồi bật thực thi.
  • Chạy lại ma trận: URL được phép chạy, URL ngoài danh sách vẫn bị chặn.
  • Không đổi proxy để sửa lỗi CSP.

Giới hạn của lab

Lab chạy trên một trình duyệt nhân Chromium bản 152 qua HTTP trên 127.0.0.1. Chưa thử Firefox, Safari, HTTPS, thẻ meta CSP, fetchLater và thuộc tính ping. Báo cáo report-to không về trong 90 giây chờ, bài chưa kết luận nguyên nhân.

Kết quả ca 5 về 'self' và WebSocket đúng với Chrome 152, không suy cho trình duyệt khác. Quy tắc redirect lấy từ đặc tả CSP Level 3 và khớp kết quả lab trên Chrome. Các phần về Playwright, tiện ích và proxy công ty là phân tích theo tài liệu, chưa chạy trong lab.

Câu hỏi thường gặp về lỗi CSP connect-src

Lỗi CSP connect-src có làm request tới máy chủ không?

Không. Trình duyệt chặn trước khi gửi. Lab cho thấy máy chủ đích không ghi dòng nào cho mọi ca bị chặn ở chế độ thực thi.

Thêm header CORS ở API có sửa được lỗi này không?

Không. CORS là quyết định của máy chủ đích, còn CSP là chính sách của trang gọi. Phải sửa connect-src trên header của trang.

Vì sao localhost chạy mà 127.0.0.1 bị chặn?

CSP so tên máy theo chuỗi. localhost và 127.0.0.1 là hai tên khác nhau, dù cùng một máy. Ca 4 của lab bị chặn vì lý do này.

Report-Only có làm chậm trang không?

Report-Only không chặn request, chỉ gửi thêm báo cáo. Với nhiều vi phạm, số request báo cáo tăng theo, nên điểm nhận cần chịu tải và có giới hạn tốc độ.

Có cần connect-src khi đã có default-src?

Không bắt buộc. Thiếu connect-src thì trình duyệt dùng default-src. Khai báo riêng giúp mở kết nối tới API mà không mở luôn ảnh, font hay script.

Lỗi CSP connect-src và những điều cần nhớ

Lỗi CSP connect-src là trình duyệt chặn kết nối theo chính sách của chính trang, nên máy chủ đích không có log. Đọc console, báo cáo và log máy chủ để tách khỏi CORS, rồi thêm nguồn hẹp nhất qua Report-Only. Cần proxy ổn định cho script phía máy chủ khi xử lý lỗi CSP connect-src, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.

Quảng cáo
Xem ngay
TIN TỨC LIÊN QUAN
Kinh Nghiệm Mua Proxy: 12 Điều Cần Hỏi Trước Khi Trả Tiền
Kinh Nghiệm Mua Proxy: 12 Điều Cần Hỏi Trước Khi Trả Tiền
Chuyên viên Kỹ thuật ProxyVN 03-11-2026
Nên Mua Proxy Loại Nào? Bảng Chọn Theo Từng Việc
Nên Mua Proxy Loại Nào? Bảng Chọn Theo Từng Việc
Chuyên viên Kỹ thuật ProxyVN 02-11-2026
Proxy Tĩnh Là Gì? Khi Nào Nên Giữ Một IP Cố Định
Proxy Tĩnh Là Gì? Khi Nào Nên Giữ Một IP Cố Định
Chuyên viên Kỹ thuật ProxyVN 01-11-2026