Những thực hành tốt nhất về Simplescraper tôi rút ra sau 1.000 lần scrape

Sau hơn một nghìn lần scrape bằng Simplescraper, tôi ngừng đếm số lần thành công và bắt đầu ghi lại những lần thất bại. Sự chuyển hướng đó — từ “nó có chạy không?” sang “lần này hỏng vì sao?” — dạy tôi nhiều hơn bất kỳ trang tài liệu nào từng làm được.

Simplescraper là một tiện ích Chrome khá ổn để lấy dữ liệu từ website mà không cần viết code. Với trên Chrome Web Store và giao diện point-and-click rất dễ tiếp cận, công cụ này đã có chỗ đứng trong bộ công cụ thu thập dữ liệu không cần code. Nhưng có một điều mà trang giới thiệu không nói hết: để có kết quả ổn định và đáng tin cậy ở quy mô lớn, bạn phải hiểu nơi các công cụ thu thập dữ liệu trực quan bắt đầu trở nên mong manh. Một người lao động dành hơn chín giờ mỗi tuần cho việc nhập dữ liệu lặp đi lặp lại — đúng kiểu nỗi đau khiến người ta tìm đến các công cụ như Simplescraper. Nhưng nếu không hiểu điểm yếu của công cụ, bạn sẽ dùng luôn chín giờ đó để gỡ lỗi thay vì làm việc có ích. Bài viết này tổng hợp năm thực hành tốt nhất tôi rút ra từ trải nghiệm vận hành thực tế: xử lý lỗi chọn phần tử, chọn đúng chế độ thu thập, tận dụng tối đa gói miễn phí, tránh bị chặn, và biết khi nào nên chuyển sang công cụ khác.

Simplescraper là gì (và vì sao thực hành tốt nhất lại quan trọng)

Simplescraper là một tiện ích Chrome cho phép bạn chọn trực quan các phần tử trên một trang web — tiêu đề sản phẩm, giá, hình ảnh, thông tin liên hệ — rồi trích xuất chúng thành dữ liệu có cấu trúc mà không cần viết một dòng code nào. Bạn trỏ, bạn nhấp, và nó tạo ra một “công thức” có thể dùng lại trên các trang tương tự.

Mô hình cốt lõi hoạt động như sau:

• Chọn phần tử trực quan: Nhấp vào thứ bạn muốn. Simplescraper tự nhận diện các mẫu lặp lại (danh sách sản phẩm, kết quả tìm kiếm, tin tuyển dụng).
• Công thức: Lưu cấu hình trích xuất để dùng lại sau này hoặc chạy hàng loạt URL.
• Hai chế độ thu thập: Browser (cục bộ, chạy trong Chrome của bạn) và Cloud (chạy trên máy chủ của Simplescraper, không cần giám sát).
• Tích hợp: Xuất sang Google Sheets, Airtable, webhook, Zapier, Make, CSV và JSON.
• Trích xuất bằng AI: Tính năng mới hơn, tạo CSS selector từ một prompt schema.

Đối tượng người dùng rất rộng — marketer, đội ngũ sales, người vận hành thương mại điện tử, nhà nghiên cứu — bất kỳ ai cần lấy dữ liệu có cấu trúc từ website mà không muốn thuê lập trình viên. Và với những trang đơn giản, Simplescraper làm rất nhanh.

Vậy vì sao thực hành tốt nhất lại quan trọng? Vì ngay khi bạn đi xa hơn một danh sách sản phẩm đơn giản hay một trang thư mục gọn gàng, ma sát sẽ xuất hiện. Nội dung động, cơ chế chống bot, hình ảnh tải lười, cấu trúc HTML lồng nhau — đó là những thứ rất đời thực, và cũng là ranh giới giữa một trải nghiệm bực mình và một trải nghiệm hiệu quả. Biết cách tiếp cận đúng ngay từ đầu sẽ tiết kiệm hàng giờ thử sai.

Thực hành tốt nhất 1: Làm gì khi Simplescraper không chọn được phần tử

Đây là nỗi bực bội phổ biến nhất tôi từng thấy. Bạn nhấp vào một phần tử, Simplescraper tô sáng nó, bạn thấy ổn — rồi đầu ra lại thiếu một nửa dữ liệu. Ảnh trống trơn. Bio rỗng. Vị trí biến mất.

Chính nhà sáng lập cũng rằng “element/css selector vẫn chưa đạt 100%.” Sự thẳng thắn đó đáng quý, nhưng nó không giúp bạn sửa lần scrape hỏng lúc 11 giờ đêm thứ Tư.

Các lỗi chọn phần tử thường gặp (và vì sao xảy ra)

Bốn kiểu sau làm Simplescraper vấp nhiều nhất:

1. Hình ảnh tải lười: Phần tử ảnh thực ra cho đến khi bạn cuộn tới nó. Nếu scrape trước khi cuộn, bạn sẽ nhận trường ảnh trống.
2. Container lồng nhau hoặc được nhóm: Cơ chế tự nhận diện của Simplescraper , và đôi khi điều đó có nghĩa là nó chỉ lấy một phần của trang thay vì toàn bộ tập hợp lặp lại. Người dùng báo rằng có những bảng “không chọn được hết tất cả hàng chỉ trong 1 lần”.
3. Nội dung JavaScript động: Các phần tử được render sau khi trang tải ban đầu qua React, Vue hoặc AJAX đơn giản là chưa xuất hiện khi scraper hành động quá sớm.
4. Phân trang cuộn vô hạn: Dữ liệu bạn cần chưa được nạp vào HTML vì phải cuộn hoặc bấm “load more”.

Các bước gỡ lỗi thực tế

Trước khi đụng tới selector thủ công, hãy thử những cách này:

• Cuộn hết trang trước. Điều này buộc hình ảnh và nội dung tải lười đi vào DOM.
• Dùng “Include Similar” khi số lượng trong danh sách có vẻ thấp bất thường. Tài liệu của Simplescraper cũng khuyến nghị cách này cho nội dung được nhóm.
• Chờ trang render xong trên các site nặng JavaScript. Hãy cho nó thêm vài giây trước khi kích hoạt scrape.
• Bắt đầu bằng mẫu nhỏ. Xác nhận số dòng trên 2–3 trang trước khi chạy lô 500 trang.

Chuyển sang CSS selector thủ công

Khi chọn trực quan cứ liên tục thất bại, đã đến lúc dùng thủ công. Đây là nước đi thể hiện người dùng hiệu quả khác với người dùng phổ thông.

Quy trình như sau:

1. Nhấp chuột phải vào phần tử bạn muốn trong Chrome → Inspect.
2. Trong DevTools, xác định tên class hoặc thuộc tính dữ liệu của phần tử (ví dụ: .product-card .price hoặc [data-test="location"]).
3. Trong Simplescraper, chuyển sang tab và dán selector của bạn.
4. Kiểm tra selector bằng cách chạy một lần scrape nhỏ.

Mẹo để selector bền hơn:

• Ưu tiên tên class (.listing-title) hơn selector theo vị trí (div:nth-child(3))
• Dùng khi có — chúng thường ổn định hơn qua các lần cập nhật site
• Tránh các đường dẫn lồng quá sâu, vì chúng dễ gãy khi cấu trúc HTML của site thay đổi

Lựa chọn thay thế bằng AI: để Thunderbit tự nhận diện trường

Nói thẳng luôn — đội của tôi xây dựng chính vì chúng tôi quá chán với đúng vấn đề này. Tính năng “AI Suggest Fields” của Thunderbit đọc cấu trúc trang và tự đề xuất cột cũng như logic trích xuất. Không cần biết CSS. AI thích ứng với bố cục của từng website, kể cả nội dung lồng nhau và hình ảnh tải lười.

Nếu bạn đang mất hơn vài phút cho mỗi lần scrape chỉ để gỡ selector, thì rất đáng thử một cách tiếp cận hoàn toàn khác.

Thực hành tốt nhất 2: Chọn giữa scrape trên Cloud và scrape trên Browser

Phần lớn người dùng Simplescraper chọn chế độ theo mặc định — thường là chế độ họ thử đầu tiên — mà không nghĩ xem chế độ nào mới phù hợp với nhu cầu thực tế. Điều này dẫn đến những lỗi hoàn toàn có thể tránh được.

Khi nào nên dùng Browser scraping (cục bộ)

• Trang cần đăng nhập: LinkedIn, dashboard CRM, công cụ nội bộ — mọi thứ nằm sau xác thực đều cần phiên trình duyệt đang hoạt động của bạn.
• Trích xuất nhanh một lần: Bạn đã ở trên trang rồi, chỉ muốn lấy dữ liệu ngay.
• Tiết kiệm credit miễn phí: Browser scraping không dùng credit cloud.

Đổi lại: máy tính của bạn phải bật, và các job lớn sẽ chậm hơn cloud.

Khi nào nên dùng Cloud scraping

• Trang công khai (danh sách thương mại điện tử, thư mục, website bất động sản) không cần đăng nhập.
• Giám sát theo lịch: Chạy tự động, lặp lại theo chu kỳ.
• Job hàng loạt: trong một lô cloud.
• Giao dữ liệu qua tích hợp: Đẩy tự động sang Google Sheets, Airtable hoặc webhook.

Đổi lại: cloud scraping — 2 credit cho mỗi trang có JavaScript, 1 credit cho trang không có JS — và sẽ hết nhanh gói miễn phí 100 credit.

Khung ra quyết định

Thunderbit đơn giản hóa chuyện này như thế nào

Trong , lựa chọn chỉ là một công tắc đơn giản ngay trong cùng giao diện. Chế độ Cloud xử lý đồng thời tới 50 trang — không có tầng trả phí riêng chỉ để dùng cloud. Chế độ Browser xử lý các site cần đăng nhập mà không cần cấu hình thêm. Gánh nặng tinh thần “mình cần chế độ nào?” giảm đi đáng kể khi cả hai cùng nằm trong một quy trình.

Thực hành tốt nhất 3: Tận dụng tối đa gói miễn phí của Simplescraper

Sự nhầm lẫn về giá là có thật. Tôi từng thấy trên forum có người nghĩ “tiện ích Chrome miễn phí” nghĩa là “mọi thứ đều miễn phí.” Không phải vậy. Ở chiều ngược lại, tôi cũng thấy người ta tưởng Simplescraper đắt vì các gói trả phí không được hiển thị nổi bật. Cả hai đều không giúp ích gì.

Gói miễn phí của Simplescraper thực sự bao gồm gì

Theo :

• Browser scraping: Không giới hạn (chạy cục bộ trong Chrome của bạn)
• Credit cloud: 100 mỗi tháng
• Công thức đã lưu: 3
• Định dạng xuất: CSV và JSON
• Không bao gồm: Hỗ trợ ưu tiên, tùy chọn proxy nâng cao, mức credit cloud cao hơn

Một kịch bản thực tế với gói miễn phí

Giả sử bạn cần scrape 50 trang sản phẩm từ một website thương mại điện tử công khai.

• Chế độ Browser (miễn phí): Bạn có thể làm hoàn toàn miễn phí. Mở từng trang (hoặc dùng danh sách), chạy công thức, xuất ra CSV. Thời gian cần thiết: tùy vào mức kiên nhẫn và tốc độ internet của bạn, nhưng với việc điều hướng thủ công, hãy tính khoảng 15–30 phút làm việc chủ động cho 50 trang.
• Chế độ Cloud (gói miễn phí): Nếu bật render JavaScript, mỗi trang tốn 2 credit. 50 trang = 100 credit. Đó là toàn bộ hạn mức cloud mỗi tháng của bạn cho một job duy nhất. Không có lập lịch, không có chạy lại nếu có lỗi.

Gói miễn phí thực sự hữu ích cho những lần scrape nhỏ, thỉnh thoảng. Nhưng nó cạn rất nhanh khi bạn cần tự động hóa trên cloud hoặc cần quy mô lớn.

So sánh gói miễn phí: Simplescraper vs. Thunderbit

Mô hình thực sự khác nhau. Simplescraper cho bạn scrape cục bộ không giới hạn nhưng cloud bị giới hạn. cho bạn ít trang hơn nhưng mỗi trang đều có đầy đủ năng lực AI, cộng với xuất miễn phí sang các công cụ mà hầu hết đội nhóm thực sự dùng. Gói miễn phí của Simplescraper ổn nếu bạn chỉ cần scrape cục bộ cơ bản và chấp nhận làm thủ công. Nhưng nếu bạn muốn trích xuất bằng AI với khả năng xuất linh hoạt, gói miễn phí của Thunderbit mạnh hơn đáng kể trên mỗi trang.

Thực hành tốt nhất 4: Cách tránh bị chặn khi scrape

Không ai nghĩ đến cơ chế chống bot cho đến khi họ đối diện một bức tường CAPTCHA hoặc một bộ dữ liệu trống rỗng. Lúc đó bạn đã mất thời gian, và có thể cả credit.

Phòng ngừa luôn rẻ hơn gỡ lỗi khi sự cố đã xảy ra.

Đặt rate limit và kiểm soát tốc độ request

Lý do số một khiến bạn bị chặn: bắn vào site quá nhiều request trong thời gian quá ngắn. Với máy chủ web, 50 request trong 10 giây từ một IP trông như một cuộc tấn công, không phải một nhà nghiên cứu tò mò.

Nguyên tắc chung:

• Chèn 2–5 giây giữa các request trang với đa số site thương mại.
• Với mục tiêu nhạy cảm hơn (marketplace, site đánh giá), hãy chậm hơn — 5–10 giây.
• Nếu bạn dùng API của Simplescraper, tham số có thể giúp đảm bảo trang tải xong trước khi trích xuất, đồng thời tự nhiên làm chậm nhịp chạy.

Khi nào nên bật xoay proxy

Xoay proxy thay đổi địa chỉ IP giữa các request, khiến bạn trông như nhiều người dùng khác nhau. Bạn sẽ cần nó cho:

• Amazon, Yelp, TripAdvisor, LinkedIn (hệ thống chống bot rất gắt)
• Bất kỳ site nào giới hạn theo IP
• Job chạy lô lớn (hàng trăm trang từ cùng một miền)

Nền tảng của Simplescraper gồm standard, premium và residential. Tuy nhiên, mức khả dụng cụ thể theo từng gói không phải lúc nào cũng rõ trong tài liệu công khai — hãy kiểm tra trước khi mặc định rằng gói miễn phí xử lý được các mục tiêu khó. Proxy residential thường đắt hơn nhưng ít bị gắn cờ hơn.

Xử lý các site nặng JavaScript

Các site hiện đại xây bằng React, Vue hoặc Angular render nội dung sau khi trang tải ban đầu. Nếu scraper hành động trước khi JavaScript chạy xong, bạn sẽ nhận các trường trống.

Chiến lược:

• Dùng chế độ cloud scraping để render tốt hơn (cloud của Simplescraper có thể thực thi JavaScript).
• Cuộn thủ công trang trước khi chạy browser scrape để kích hoạt nội dung tải lười.
• Dùng waitForSelector trong workflow dựa trên API để tạm dừng cho tới khi phần tử mục tiêu xuất hiện.
• Chấp nhận rằng một số ứng dụng một trang quá động có thể đơn giản là vượt ngoài khả năng xử lý ổn định của công cụ trực quan.

Lựa chọn không cần động tay

tự xử lý bảo vệ chống bot, CAPTCHA và render JavaScript — không cần cấu hình proxy, không cần chỉnh delay, không cần cuộn thủ công. Với người không muốn trở thành kỹ sư DevOps nghiệp dư chỉ để scrape một danh mục sản phẩm, điều đó rất quan trọng. Vấn đề không biến mất — nó chỉ trở thành vấn đề của người khác.

Thực hành tốt nhất 5: Biết khi nào Simplescraper đã chạm trần

Tôi ước ai đó đã viết phần này cho tôi cách đây hai năm.

Có một thời điểm công cụ không còn tiết kiệm thời gian mà bắt đầu ngốn thời gian. Nhận ra ngưỡng đó sớm giúp bạn tránh rơi vào cái bẫy “mình đã xây 15 công thức rồi, giờ không thể đổi được.”

Giới hạn thực tế của Simplescraper

• Ứng dụng một trang động tải nội dung qua AJAX mà không có điều hướng trang truyền thống
• Cuộn vô hạn yêu cầu cuộn liên tục để tải hết toàn bộ mục (không phải phân trang bấm từng trang chuẩn)
• Làm giàu trang con: scrape trang danh sách rồi vào từng trang chi tiết để lấy thêm dữ liệu. Simplescraper làm được việc này bằng , nhưng độ phức tạp thiết lập tăng rất nhanh.
• Thay đổi bố cục làm hỏng các công thức hiện có. Khi site cập nhật cấu trúc HTML, các CSS selector được tinh chỉnh cẩn thận của bạn sẽ ngừng hoạt động.

Dấu hiệu bạn đã vượt quá giới hạn của công cụ

Có lẽ bạn đã chạm trần khi:

• Bạn phải chỉnh CSS selector thủ công ở mọi lần scrape vì cơ chế tự nhận diện cứ thất bại
• Công thức bị hỏng sau khi site cập nhật và phải xây lại
• Bạn cần scrape hàng chục hoặc hàng trăm trang cùng lúc nhưng cứ đụng trần credit hoặc tốc độ
• Dữ liệu từ trang con đòi hỏi chuỗi công thức nhiều bước phức tạp
• Bạn dành nhiều thời gian bảo trì scrape hơn là sử dụng dữ liệu đã trích xuất

Dấu hiệu cuối cùng là rõ nhất. Khi việc bảo trì trở thành công việc chính, lợi thế tiện lợi của no-code không còn nữa.

Chuyển sang workflow dùng AI

Đây là lúc tôi nói về thứ đội tôi xây dựng với , vì nó được thiết kế riêng cho những kiểu lỗi mô tả ở trên:

• AI đọc lại từng trang mỗi lần — không có công thức mong manh hay CSS selector nào phải duy trì. Nếu site đổi bố cục, AI sẽ thích ứng ở lần chạy tiếp theo.
• Scrape trang con làm giàu bảng dữ liệu của bạn chỉ với một cú nhấp. Scrape trang danh sách, rồi tự động vào từng trang chi tiết để lấy thêm trường dữ liệu.
• Scrape theo lịch bằng ngôn ngữ tự nhiên (“mỗi thứ Hai lúc 9 giờ sáng”) thay vì cấu hình preset thời gian.
• Cloud scraping đồng thời 50 trang để tăng tốc trên các site công khai.
• Xuất gốc miễn phí sang Google Sheets, Airtable, Notion và Excel mà không cần cấu hình webhook.

Simplescraper vs. Thunderbit: So sánh trực tiếp

Đây là mọi thứ đặt cạnh nhau:

Tóm lại: Simplescraper rất mạnh cho việc trích xuất đơn giản, trực quan, ít thiết lập, nơi việc tinh chỉnh thủ công thỉnh thoảng vẫn chấp nhận được. Thunderbit tiếp nối đúng chỗ mô hình đó bắt đầu đổ vỡ — xử lý hiểu trang, thích ứng bố cục và độ phức tạp của workflow để bạn không phải làm.

Không có công cụ nào tốt hơn trong mọi trường hợp. Chúng đứng ở những điểm khác nhau trên đường cong độ phức tạp — và điều đó hoàn toàn ổn.

Checklist nhanh: Thực hành tốt nhất với Simplescraper

Lưu lại mục này cho lần scrape tiếp theo:

1. Luôn thử trên mẫu nhỏ trước. Xác nhận số hàng và độ đầy đủ của trường dữ liệu trên 2–3 trang trước khi mở rộng.
2. Cuộn trang trước khi scrape để kích hoạt nội dung tải lười.
3. Dùng “Include Similar” khi việc nhận diện danh sách có vẻ quá hẹp.
4. Chọn chế độ scraping có chủ đích. Browser cho site cần đăng nhập; cloud cho trang công khai và job theo lịch.
5. Đặt độ trễ giữa các request — tối thiểu 2–5 giây cho site thương mại, lâu hơn với mục tiêu chống bot mạnh.
6. Hiểu phép tính gói miễn phí. 100 cloud credits = 50 trang có JavaScript. Lập kế hoạch cho phù hợp.
7. Chỉ lưu công thức cho các trang ổn định. Nếu site cập nhật thường xuyên, công thức sẽ hỏng.
8. Học CSS selector cơ bản làm phương án dự phòng. Tên class và data attributes tốt hơn selector theo vị trí.
9. Theo dõi dấu hiệu bị chặn một cách chủ động. Nếu bạn nhận kết quả trống hoặc CAPTCHA, hãy giảm tốc hoặc đổi chế độ.
10. Nhận ra ngưỡng trần. Khi thời gian bảo trì vượt thời gian sử dụng dữ liệu, hãy cân nhắc giải pháp khác.

Kết luận: Mỗi lần scrape đều phải đáng giá

Bài học lớn rút ra từ hơn một nghìn lần scrape không nằm ở bất kỳ công cụ đơn lẻ nào. Điều quan trọng là cách tiếp cận quan trọng hơn phần mềm. Hiểu vì sao một lần scrape thất bại — tải lười, chọn sai chế độ, chống bot quá gắt, selector mong manh — còn giá trị hơn mọi danh sách tính năng.

Simplescraper thực sự hoạt động tốt cho những tác vụ trích xuất đơn giản. Nếu trang của bạn gọn gàng, nhu cầu vừa phải, và bạn không ngại thỉnh thoảng chỉnh tay — nó làm được việc.

Nhưng nếu bạn thấy mình đang vật lộn với công cụ nhiều hơn là sử dụng nó — gỡ selector, xây lại công thức hỏng, cấu hình proxy, cuộn trang thủ công — đó là tín hiệu, không phải thất bại cá nhân. Điều đó chỉ có nghĩa là bạn đã vượt ra ngoài giới hạn mà scraping trực quan đơn thuần có thể xử lý hiệu quả.

Nếu nghe quen quen, hãy thử — sáu trang với đầy đủ tính năng AI, xuất miễn phí sang Sheets, Airtable và Notion. So sánh nó với quy trình hiện tại của bạn và xem cái nào phù hợp hơn. Đôi khi, thực hành tốt nhất chính là biết lúc nào cần chuyển sang một công cụ khác hoàn toàn.

Câu hỏi thường gặp

Simplescraper có miễn phí không?

Có, Simplescraper có gói miễn phí bao gồm scrape browser cục bộ không giới hạn, , 3 công thức đã lưu và xuất CSV/JSON. Các trang cloud có JavaScript tốn 2 credit mỗi trang, nên 100 credit đó đủ cho khoảng 50 trang ở chế độ cloud. Gói trả phí bắt đầu từ 39 USD/tháng (Plus) cho 6.000 credit và 70 USD/tháng (Pro) cho 15.000 credit.

Simplescraper có xử lý được website nặng JavaScript không?

Đôi khi có. Chế độ cloud của Simplescraper có thể render JavaScript, và công cụ này quảng cáo hỗ trợ ứng dụng một trang. Tuy nhiên, các SPA phức tạp với render động nặng, cuộn vô hạn hoặc hệ thống chống bot mạnh vẫn có thể cho kết quả thiếu sót. Dùng cloud mode với thời gian chờ phù hợp sẽ tăng độ tin cậy, nhưng các site quá động vẫn là thách thức cho bất kỳ công cụ thu thập dữ liệu trực quan nào.

Sự khác nhau giữa scrape cloud và scrape browser trong Simplescraper là gì?

Browser scraping chạy cục bộ trong trình duyệt Chrome của bạn — nó dùng phiên đang hoạt động của bạn (rất phù hợp với site cần đăng nhập), không tốn credit, nhưng máy phải luôn bật. chạy trên máy chủ của Simplescraper — nhanh hơn, chạy tự động, hỗ trợ lập lịch và tích hợp, nhưng tốn credit theo từng trang và không truy cập được các trang nằm sau đăng nhập cá nhân của bạn.

Khi nào tôi nên chuyển từ Simplescraper sang một giải pháp thay thế như Thunderbit?

Tín hiệu rõ nhất là khi thời gian bảo trì vượt thời gian sử dụng dữ liệu. Nếu bạn thường xuyên phải sửa selector hỏng sau mỗi lần site cập nhật, cấu hình proxy thủ công, xây lại công thức, hoặc dành nhiều thời gian gỡ lỗi hơn là phân tích dữ liệu đã trích xuất, thì bạn đã vượt quá mức mà scraping trực quan thủ công có thể cung cấp hiệu quả. Các công cụ như dùng AI để diễn giải cấu trúc trang mỗi lần chạy sẽ loại bỏ phần lớn gánh nặng bảo trì đó.

Làm sao để tránh bị chặn khi scrape bằng Simplescraper?

Ba thực hành chính: Thứ nhất, kiểm soát tốc độ request với độ trễ 2–5 giây giữa các trang (lâu hơn với site chống bot mạnh như Amazon hoặc Yelp). Thứ hai, dùng chế độ browser như một phương án dự phòng cho các site chặn IP cloud quá gắt — phiên trình duyệt của bạn trông giống lưu lượng bình thường hơn. Thứ ba, bật xoay proxy cho các job hàng loạt trên mục tiêu nhạy cảm, nhưng hãy xác minh gói của bạn có bao gồm tùy chọn proxy nào trước khi phụ thuộc vào nó.

Tìm hiểu thêm