cURL hiện đang được cài trên ước tính 20 tỷ thiết bị trên toàn cầu — nó có sẵn mặc định trên macOS, hầu hết các bản phân phối Linux, và cả Windows 10/11. Thế nhưng, nếu hỏi mười lập trình viên cách route một request cURL qua proxy cho đúng, bạn sẽ nhận được mười câu trả lời hơi khác nhau, và một nửa trong số đó sẽ lỗi ngay khi có xác thực hoặc SOCKS xuất hiện.
Đó chính là khoảng trống mà bài viết này muốn lấp đầy. Phần lớn hướng dẫn chỉ cho bạn một lệnh, nói rằng nó chạy, rồi dừng ở đó. Họ không chỉ cách kiểm tra xem proxy có thật sự đang hoạt động hay không (spoiler: đôi khi là không), và gần như chắc chắn cũng không dẫn bạn qua các mã lỗi xuất hiện ngay khi cấu hình của bạn lệch khỏi “đường chuẩn” dù chỉ một chút. Hướng dẫn này bao quát đầy đủ — proxy HTTP/HTTPS, SOCKS4/SOCKS5/socks5h, biến môi trường (và những cái bẫy rất riêng của chúng), một bảng troubleshooting đúng nghĩa, và cả việc phải làm gì khi cURL + proxy không còn đủ sức xử lý.
cURL là gì và vì sao nên dùng cùng proxy?
cURL là công cụ dòng lệnh dùng để chuyển dữ liệu tới và từ một URL. Chỉ vậy thôi — không có giao diện đồ họa, không màu mè, chỉ là một chương trình nói được HTTP, HTTPS, FTP và vài giao thức khác. Cách gọi đơn giản nhất là:
curl https://example.com
Lệnh này sẽ tải trang và in HTML thô ra terminal. Tự nó đã hữu ích, nhưng lý do thực sự khiến lập trình viên và người dùng doanh nghiệp có kỹ thuật chọn cURL là để test API, scrape dữ liệu, kiểm tra nội dung bị giới hạn theo khu vực, và chạy request trong các pipeline CI/CD.
Proxy đứng giữa máy của bạn và server đích, rồi chuyển tiếp request thay bạn. Server đích sẽ thấy IP của proxy chứ không phải IP của bạn. Điều này quan trọng trong một số tình huống hợp lệ: kiểm tra website hiển thị ra sao từ một quốc gia khác, vượt qua giới hạn tốc độ trong giai đoạn QA, hoặc đưa traffic đi qua cổng gateway doanh nghiệp mà công ty yêu cầu. cURL hỗ trợ đầy đủ các loại proxy — HTTP, HTTPS, SOCKS4 và SOCKS5 — và những flag bạn sẽ gặp lặp đi lặp lại trong bài này là -x / --proxy (địa chỉ proxy), -v (hiển thị chi tiết, bạn thân nhất khi debug), và -k (bỏ qua xác minh SSL, gần như không nên dùng ngoài mục đích thử nghiệm).
Một lưu ý nhanh trước khi đi tiếp: bài này chỉ nói về cơ chế mạng khi dùng proxy với cURL. Nó không phải giấy phép để bỏ qua điều khoản dịch vụ của website đích hay chính sách bảo mật của tổ chức bạn. Proxy chỉ đổi đường đi của mạng — không đổi được cái gì là hợp pháp hay được phép.
Trước khi bắt đầu
Độ khó: Cơ bản đến trung cấp Thời gian cần thiết: Khoảng 15 phút để đi qua các ví dụ cốt lõi Bạn cần có:
- cURL đã được cài đặt (kiểm tra bằng
curl --version— nếu bạn dùng macOS, Linux, hoặc Windows 10/11 thì gần như chắc chắn đã có sẵn) - Thông tin proxy từ nhà cung cấp: host, port, giao thức (HTTP/HTTPS/SOCKS), và username/password nếu cần
- Một terminal (Terminal trên macOS, bất kỳ shell nào trên Linux, PowerShell hoặc CMD trên Windows)
Nếu vì lý do nào đó cURL chưa được cài, chỉ cần một dòng lệnh: brew install curl trên macOS qua Homebrew, sudo apt install curl trên Debian/Ubuntu, hoặc sudo yum install curl trên RHEL/CentOS. Trên Windows, cURL đã được đi kèm với hệ điều hành từ Windows 10 build 17063.
Trong suốt bài này, tôi sẽ dùng các giá trị mẫu — proxy.example:8080 cho địa chỉ proxy và user:pwd cho thông tin xác thực. Hãy thay chúng bằng thông tin proxy thật của bạn, và đừng bao giờ dán credential thật vào lịch sử shell, ảnh chụp màn hình, hay tin nhắn Slack. Tôi đã thấy quá nhiều mật khẩu proxy bị lộ trong các kênh Slack hơn mức tôi muốn thừa nhận.
Cách dùng cURL với proxy HTTP hoặc HTTPS
Đây là cấu hình phổ biến nhất, và cũng là kiểu bạn sẽ dùng trong phần lớn tác vụ liên quan đến proxy.
Dùng cờ -x / --proxy
Cú pháp cơ bản như sau:
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x và --proxy làm đúng cùng một việc — chọn cái nào dễ nhớ với bạn hơn. Vì HTTP là giao thức proxy mặc định của cURL, về mặt kỹ thuật bạn có thể bỏ tiền tố http:// và chỉ viết proxy.example:8080. Nhưng tôi vẫn khuyên nên viết rõ ràng, vì sáu tháng sau bạn sẽ thấy mình biết ơn chính mình vì điều đó.
Hãy đặt toàn bộ URL trong dấu ngoặc kép. Nếu mật khẩu của bạn có ký tự như @, # hoặc &, chuỗi không được quote sẽ bị shell “xử lý hộ” trước khi cURL kịp nhìn thấy.
Kết nối qua proxy HTTPS
Một số nhà cung cấp mã hóa cả kết nối tới proxy bằng TLS, không chỉ phần từ proxy đến đích. Đây là một chuyện khác với việc scrape một website HTTPS — giao thức proxy và giao thức của target là hai biến độc lập. Cách chỉ định là:
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
Nếu bạn gặp lỗi chứng chỉ ở đây, đừng vội thêm -k rồi bỏ qua. Cờ này tắt hoàn toàn việc xác minh chứng chỉ SSL, có thể chấp nhận cho một bài test nội bộ kéo dài năm phút, nhưng là ý tưởng cực tệ nếu đụng tới production hoặc dữ liệu người dùng thật. Nếu bạn đang làm việc với corporate proxy chặn TLS (một thiết lập MITM, khá phổ biến trong môi trường doanh nghiệp), cách sửa đúng là import CA certificate của proxy, không phải tắt xác minh.
Xác thực bằng --proxy-user
Bạn cũng có thể tách thông tin đăng nhập ra thành một flag riêng thay vì nhét hết vào URL:
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
Lưu ý rằng -U viết hoa không giống với xác thực tới website đích (-u / --user, chữ thường) — nhầm hai cái này rất dễ khiến bạn gửi mật khẩu proxy sang nhầm nơi. Với môi trường doanh nghiệp dùng NTLM hoặc Digest thay vì Basic, hãy thêm --proxy-ntlm hoặc --proxy-digest cùng với --proxy-user.
Cách dùng cURL với SOCKS proxy: SOCKS4, SOCKS5 và socks5h
SOCKS proxy hoạt động ở tầng thấp hơn proxy HTTP — nó không quan tâm bạn đang tunnel giao thức nào, vì vậy rất hữu ích cho traffic không phải HTTP, Tor circuits, và mọi thứ nhạy cảm về quyền riêng tư. Nhiều bài viết đối thủ chỉ ném cho bạn một lệnh rồi thôi. Đó là một thiếu sót, vì khác biệt giữa SOCKS4, SOCKS5 và socks5h:// thực sự rất quan trọng.
| Tính năng | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| Hỗ trợ TCP | Có | Có | Có |
| Hỗ trợ UDP | Không | Có | Có |
| Xác thực | Không | Có | Có |
| Phân giải DNS từ xa | Không | Không (DNS nội bộ) | Có (proxy phân giải) |
| Tương thích với Tor | Không | Rủi ro (rò rỉ DNS) | Có |
Dòng về phân giải DNS là chỗ khiến nhiều người “dính đòn” nhất. Với socks5://, máy bạn sẽ tự phân giải hostname trước khi chuyển kết nối cho proxy — nghĩa là bộ phân giải DNS cục bộ của bạn (và gián tiếp là ISP) vẫn biết bạn đang cố truy cập domain nào, dù lưu lượng HTTP thực tế đi qua proxy. socks5h:// khắc phục điều này bằng cách để proxy tự phân giải hostname, nên không có thông tin nào về đích bị lộ ở máy local. Đó cũng là lý do tài liệu Tor luôn nhấn mạnh socks5h:// — dùng socks5:// thuần túy sẽ làm mất đi một phần đáng kể tính ẩn danh mà Tor vốn cung cấp.
Đây là cách dùng từng biến thể trong cURL:
curl --socks4 "proxy.example:1080" "http://example.com"
curl -x "socks5://user:pwd@proxy.example:1080" "http://example.com"
curl -x "socks5h://user:pwd@proxy.example:1080" "http://example.com"
Nếu không có lý do đặc biệt nào khác, hãy ưu tiên socks5h://. Nó không tốn thêm gì cả nhưng lại loại bỏ một rò rỉ mà bạn sẽ khó mà tự phát hiện.
Đặt proxy bằng biến môi trường (và tránh các bẫy)
Việc gõ -x cho từng lệnh sẽ rất nhanh trở nên mệt mỏi. Biến môi trường cho phép bạn đặt proxy một lần cho mỗi phiên shell, rồi mọi lệnh cURL sau đó sẽ tự kế thừa — manual của cURL ghi nhận http_proxy, HTTPS_PROXY, ALL_PROXY và NO_PROXY là bộ biến được hỗ trợ.
Phần cơ bản
export http_proxy="http://user:pwd@proxy.example:8080"
export HTTPS_PROXY="http://user:pwd@proxy.example:8080"
export ALL_PROXY="socks5h://proxy.example:1080"
Đây là chỗ rất nhiều người hay nhầm: tên biến nói về giao thức của URL đích, chứ không phải giao thức của proxy. Vì vậy http_proxy điều khiển request tới các URL http://, còn HTTPS_PROXY điều khiển request tới các URL https:// — bạn hoàn toàn có thể trỏ cả hai về cùng một HTTP proxy server, và đó là chuyện hoàn toàn bình thường.
Bỏ qua bằng NO_PROXY
export NO_PROXY="localhost,127.0.0.1,.internal.example"
Các mục được ngăn cách bằng dấu phẩy, và dấu chấm đứng đầu .internal.example hoạt động như một wildcard cho mọi subdomain. NO_PROXY ghi đè mọi thứ khác — ngay cả khi bạn đã chỉ định -x trực tiếp trên dòng lệnh, nếu domain khớp với NO_PROXY thì request đó sẽ đi thẳng, không qua proxy.
Những bẫy thực tế hay khiến người ta mắc phải
- Quên
export. Nếu bạn chỉ gõhttp_proxy=http://...mà không cóexport, biến đó chỉ tồn tại trong shell hiện tại và cURL — vốn là một process con — sẽ hoàn toàn không nhìn thấy. Theo kinh nghiệm của tôi, đây là nguyên nhân phổ biến nhất đằng sau các ticket kiểu “proxy không hoạt động”. - Phân biệt hoa thường. cURL ưu tiên kiểm tra
http_proxyviết thường trước và sẽ dùng nó nếu tồn tại cả hai dạng. Một số công cụ khác chỉ đọc dạng viết hoa. Nếu bạn đang debug vì sao một biến “không được nhận”, hãy kiểm tra xem có bản sao trùng tên nhưng khác hoa thường hay không. - Bẫy alias trong PowerShell. Trên PowerShell 5.1, gõ
curlkhông hề gọi cURL — nó gọiInvoke-WebRequest, một công cụ hoàn toàn khác với bộ flag khác. Nếu flag-xtrên Windows báo lỗi rất kỳ lạ, hãy gõ rõcurl.exeđể chắc chắn bạn đang chạy đúng cURL. - Khác biệt cú pháp trên Windows. CMD dùng
set http_proxy=...; PowerShell dùng$env:http_proxy = "...". Trộn lẫn hai cú pháp này giữa các phiên terminal là cách rất dễ làm mất cả buổi chiều. - Biến cũ còn sót.
unset http_proxyvàunset https_proxysẽ xóa cấu hình proxy đã chết nhưng vẫn âm thầm route (rồi fail) mọi request.
Nếu muốn bật/tắt nhanh, vài alias trong .bashrc sẽ giúp tiết kiệm thời gian thật sự:
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
Bắt cURL luôn dùng proxy (file cấu hình)
Nếu bạn ở sau corporate proxy tới 95% thời gian, một file .curlrc (trên hệ Unix-like, đặt trong thư mục home) hoặc _curlrc (trên Windows, trong thư mục app-data) sẽ tạo cấu hình mặc định lâu dài mà không cần đụng tới biến môi trường:
proxy="http://proxy.example:8080"
Với một request riêng lẻ mà bạn muốn bỏ qua proxy, --noproxy "*" sẽ ghi đè cấu hình cho đúng lần gọi đó. Thứ tự ưu tiên thường là flag dòng lệnh > biến môi trường > file cấu hình, nên -x trên dòng lệnh luôn thắng nếu có xung đột.
Một cảnh báo quan trọng: đừng lưu mật khẩu plain text trong .curlrc nếu file đó có thể bị sync, backup, hoặc vô tình commit vào repo. Với CI pipeline, hãy dùng secret manager của nền tảng bạn đang chạy và inject credential dưới dạng biến môi trường đã được che (masked) thay vì lưu cứng.
Cách kiểm tra xem proxy có thật sự hoạt động hay không
Đây là phần gần như mọi bài viết khác đều bỏ qua, và cũng là phần tiết kiệm thời gian debug nhiều nhất. Thiết lập proxy rồi nghĩ rằng traffic đang đi qua nó là cách khiến người ta mất hàng giờ để xử lý một scraper vốn từ đầu tới cuối chưa hề dùng proxy.
Cách 1: So sánh IP đầu ra
Chạy cùng một request trả IP hai lần — một lần trực tiếp, một lần qua proxy — rồi so sánh:
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
Nếu cả hai lệnh trả về cùng một địa chỉ IP, thì proxy của bạn không làm gì cả. Hãy kiểm tra lại cú pháp flag, biến môi trường, hoặc xem NO_PROXY có vô tình khớp với target hay không.
Cách 2: Đọc verbose output
Thêm -v vào bất kỳ request proxy nào và cURL sẽ in ra toàn bộ quá trình bắt tay:
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
Hãy tìm dòng như * Connected to proxy.example (xx.xx.xx.xx) port 8080, sau đó là > CONNECT httpbin.org:443 HTTP/1.1 và cuối cùng là < HTTP/1.1 200 Connection established. Chuỗi này — kết nối tới proxy, rồi tạo tunnel CONNECT tới đích — chính là phương thức HTTP CONNECT đang hoạt động, và đó là điều phải xảy ra khi một target HTTPS được route qua HTTP proxy. Nếu dòng CONNECT đó không bao giờ xuất hiện, thì flag proxy chưa được áp dụng. Một lưu ý nhỏ: chỉ bật -v khi bạn đang debug, và hãy che thông tin nhạy cảm trước khi chia sẻ output ở bất kỳ đâu — chế độ verbose có thể in cả credential proxy dưới dạng văn bản thuần.
Cách 3: So sánh song song
Với việc test geo, hãy lưu cả hai kết quả ra file rồi dùng diff:
curl https://httpbin.org/ip > direct.json
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip > proxied.json
diff direct.json proxied.json
Nếu nội dung phản hồi (hoặc header, với nội dung bị giới hạn theo khu vực) khác nhau, bạn đã có bằng chứng trực quan rằng proxy thực sự đang thay đổi đường đi của mạng — một cách nhanh, ít công sức để xóa tan nghi ngờ trước khi đào sâu hơn.
Khắc phục các lỗi proxy cURL thường gặp
Phần này nhiều bài viết thường nói qua loa rồi nhắc -k một lần. Chủ đề này xứng đáng có một bảng tham chiếu đàng hoàng.
| Lỗi | Nguyên nhân có thể | Cách khắc phục |
|---|---|---|
curl: (7) Failed to connect | Sai host/port của proxy, hoặc proxy đang ngừng hoạt động | Kiểm tra lại địa chỉ; thử kết nối thô bằng telnet host port hoặc nc -zv host port |
407 Proxy Authentication Required | Thiếu hoặc sai thông tin xác thực proxy | Thêm --proxy-user user:pass; kiểm tra xem nhà cung cấp có yêu cầu NTLM/Digest/Negotiate thay vì Basic không |
curl: (56) Recv failure: Connection reset by peer | Proxy ngắt kết nối giữa chừng | Kiểm tra độ ổn định của proxy với nhà cung cấp; nếu là proxy chấm dứt TLS, hãy kiểm tra cách xử lý cert thay vì tắt xác minh |
curl: (28) Connection timed out | Firewall chặn, proxy cũ, hoặc sai port | Chạy env | grep -i proxy để kiểm tra biến còn sót; unset biến cũ; thử request trực tiếp để khoanh vùng nguyên nhân |
| Lỗi xác minh chứng chỉ | Chứng chỉ proxy không được tin cậy hoặc có proxy đang chặn/giải mã TLS | Lấy đúng CA chain và dùng --proxy-cacert; tránh tắt xác minh ngoài một lần chẩn đoán duy nhất |
Bước đầu tiên cho hầu hết các lỗi này luôn là thêm -v. Nó sẽ cho bạn biết chính xác kết nối bị gãy ở đâu — phân giải DNS, kết nối TCP, bắt tay TLS, hay trao đổi xác thực với proxy — thay vì bắt bạn đoán dựa trên một mã lỗi ba chữ số.
Riêng với corporate proxy, --proxy-ntlm và --proxy-negotiate sẽ xử lý các kiểu xác thực trong domain Windows. Một điểm mà cURL thực sự không xử lý native: PAC files (Proxy Auto-Config scripts mà một số doanh nghiệp dùng để gán proxy động). Nếu công ty bạn dùng PAC, bạn sẽ phải tự trích host và port proxy thực tế — thường là từ phần cài đặt mạng của trình duyệt — vì cURL không có bộ phân tích PAC tích hợp sẵn.
Khi cURL + proxy vẫn chưa đủ
cURL kết hợp proxy làm rất tốt với HTML tĩnh, gọi REST API, và lấy dữ liệu đơn giản. Điểm nó chịu thua là các lớp phòng thủ phổ biến của web hiện đại: ứng dụng single-page được render bằng JavaScript, hệ thống anti-bot như Cloudflare hay Akamai, và các lớp CAPTCHA. Nếu bạn trỏ cURL vào một app React hoặc Vue nằm sau những lớp này, bạn thường chỉ nhận lại một <div id="root"></div> rỗng — về mặt kỹ thuật là request thành công, nhưng dữ liệu thì vô dụng. Đó không phải lỗi của cURL. Nó vốn không phải trình duyệt, và chưa bao giờ tự nhận là trình duyệt cả.
Nếu bạn đã quen dùng cURL trong terminal mà vẫn chạm vào bức tường đó, bước tiếp theo hợp lý không phải là đổi sang một stack hoàn toàn khác — mà là thêm một lớp xử lý rendering và structure thay bạn. Đó chính là khoảng trống mà bộ công cụ dành cho developer của Thunderbit được tạo ra để lấp đầy.
| Tình huống | cURL + Proxy | Thunderbit API (POST /extract) |
|---|---|---|
| Trang HTML tĩnh | Hoạt động hoàn hảo | Hoạt động, đồng thời trả dữ liệu có cấu trúc |
| SPA được render bằng JS | Nhận HTML rỗng / thiếu | renderMode: "full" xử lý phần JS |
| Anti-bot / CAPTCHA | Bị chặn | Có cơ chế xử lý sẵn |
| Xuất dữ liệu có cấu trúc | HTML thô — bạn phải tự parse | JSON theo schema của bạn |
| Hàng loạt (100+ URL) | Vòng lặp thủ công + tự giới hạn tốc độ | POST /batch/extract |
Open API của Thunderbit cung cấp endpoint /extract trả về JSON khớp schema trực tiếp từ các trang nặng JavaScript, và endpoint /distill để chuyển đổi sang Markdown sạch — cả hai đều gọi được ngay trong đúng phiên terminal mà bạn vẫn đang dùng để chạy cURL. Ngoài ra còn có MCP server cho các AI coding assistant như Claude hoặc Cursor, và cả CLI (npx @thunderbit/thunderbit-cli extract <url> --schema fields.json) nếu bạn muốn làm hoàn toàn trong script. Tất cả những thứ này không thay thế cURL ở những việc cURL làm tốt — nó chỉ nhận tiếp phần mà cURL không thể đi xa hơn về mặt cấu trúc. Nếu bạn muốn nhìn bức tranh rộng hơn về nơi extraction có hỗ trợ AI phù hợp thế nào so với việc tự viết logic scraper, bài AI web scraping và bài so sánh best AI web scrapers sẽ đi sâu hơn, còn bài web scraping without coding là phần nhập môn rất ổn nếu bạn tiếp cận từ góc nhìn business hơn là engineering.
Kết luận
Làm cho cURL và proxy nói chuyện được với nhau không hề khó một khi bạn biết các điểm lỗi thực sự nằm ở đâu — và hóa ra gần như chẳng cái nào nằm ở chính proxy cả. Quên export. Nhầm -u với -U. Dùng socks5:// trong khi đáng lẽ phải là socks5h://. Chạy alias curl của PowerShell thay vì curl.exe. Mỗi lỗi này đều tạo ra một thông báo mơ hồ, chung chung, nhưng chẳng liên quan gì đến nhà cung cấp proxy.
Thói quen tiết kiệm thời gian nhất: xác minh trước khi troubleshooting. Chạy kiểm tra IP, liếc qua output -v, xác nhận proxy có thật sự nằm trong đường đi của request trước khi cho rằng lỗi nằm ở đâu đó phía sau. Và khi target bắt đầu trả về JavaScript thay vì HTML sạch, đó không phải vấn đề của cURL để sửa bằng thêm flag — mà là tín hiệu nên dùng một công cụ sinh ra để render, như Thunderbit's API, vốn có gói miễn phí nếu bạn muốn tự thấy sự khác biệt giữa JSON đầu ra và HTML thô.
Câu hỏi thường gặp
cURL có dùng proxy mặc định không?
Không. Trừ khi bạn đã đặt biến môi trường http_proxy / HTTPS_PROXY hoặc cấu hình file .curlrc, cURL sẽ kết nối trực tiếp tới target mà không đi qua proxy.
Làm sao để ngăn cURL dùng proxy cho một request duy nhất?
Thêm --noproxy "*" vào đúng lệnh đó. Nếu muốn tắt cho cả phiên shell, chạy unset http_proxy && unset https_proxy.
Tôi có thể dùng cURL với rotating proxy không?
Có — nếu nhà cung cấp đưa cho bạn một rotating gateway (một endpoint duy nhất nhưng đổi IP mới cho mỗi request), chỉ cần trỏ -x đến địa chỉ gateway đó như bất kỳ proxy nào khác. Với các logic xoay vòng phức tạp hơn cho target được render bằng JS, một lớp API như Thunderbit sẽ xử lý rotation và anti-bot ở bên trong, nên bạn không phải tự quản lý retry logic bằng tay.
Vì sao socks5:// làm lộ DNS request còn socks5h:// thì không?
Với socks5://, máy local sẽ tự phân giải hostname đích trước khi gửi yêu cầu kết nối tới proxy — nghĩa là DNS resolver của ISP có thể nhìn thấy domain bạn đang truy cập. socks5h:// đẩy việc phân giải hostname sang chính proxy, nên ở máy local sẽ không thấy gì về đích.
Dùng cURL với proxy có hợp pháp không? Bản thân việc dùng proxy là hợp pháp ở hầu hết các khu vực pháp lý. Điều quan trọng là bạn làm gì với nó — luôn tôn trọng điều khoản dịch vụ của website đích, robots.txt nếu có liên quan, và mọi luật bảo vệ dữ liệu phù hợp. Bài này chỉ nói về kỹ thuật, không phải giấy phép pháp lý cho bất kỳ trường hợp sử dụng cụ thể nào.
Tìm hiểu thêm
