Thiết Kế Tổng Quan — Tools V2 Worker Engine

1. Giới Thiệu

Tools V2 là một Worker Engine tự động hóa, được xây dựng để thực thi hai nhóm nghiệp vụ chính: tạo traffic trình duyệt thực và gửi báo cáo bảo mật tự động đến hơn 100 nền tảng trên toàn cầu.

Hệ thống không phải là một ứng dụng người dùng tương tác trực tiếp. Nó hoạt động như một worker nền, liên tục nhận lệnh từ Go A PI Backend, thực thi các tác vụ trên trình duyệt Chrome thực, rồi gửi kết quả về. Toàn bộ quá trình diễn ra tự động, không cần sự can thiệp của con người sau khi cấu hình.

Điểm cốt lõi của Tools V2 là khả năng mô phỏng hành vi người dùng thực một cách chính xác. Mỗi phiên trình duyệt được khởi động với proxy riêng, fingerprint riêng, vị trí địa lý riêng và hành vi di chuyển chuột tự nhiên. Điều này giúp các tác vụ vượt qua được các hệ thống phát hiện bot của Google, Cloudflare và các nền tảng khác.

2. Vị Trí Trong Hệ Thống

2.1. Ba Thành Phần Chính

Hệ thống Traffic Tools V2 gồm ba thành phần hoạt động phối hợp với nhau:

Admin Dashboard là giao diện web dành cho người vận hành. Tại đây, người dùng tạo chiến dịch, cấu hình từ khóa, domain mục tiêu, số lượng traffic cần tạo, và theo dõi kết quả theo thời gian thực.

Go API Backend là trung tâm điều phối. Nó lưu trữ toàn bộ dữ liệu chiến dịch, phân phối tác vụ xuống các worker, thu thập kết quả và cung cấp dữ liệu cho Admin Dashboard.

Tools V2 Worker Engine là nơi công việc thực sự diễn ra. Nó nhận tác vụ từ Go API, mở Chrome, thực hiện hành vi trên trình duyệt, và gửi kết quả về.

2.2. Mô Hình Phân Tán

Tools V2 được thiết kế để chạy trên nhiều máy chủ vật lý cùng lúc. Mỗi máy chủ chạy một instance Tools V2 độc lập, tự đăng ký với Go API qua một định danh duy nhất (SERVER_ID). Go API phân phối tác vụ đều cho tất cả các worker đang hoạt động.

Mô hình này mang lại hai lợi ích quan trọng:

Khi cần tăng năng lực xử lý, chỉ cần thêm máy chủ mới và deploy thêm một instance Tools V2. Không cần thay đổi bất kỳ cấu hình nào trên các máy chủ hiện có.

Khi một máy chủ gặp sự cố, các máy chủ còn lại tiếp tục hoạt động bình thường. Go API tự động ngừng phân phối tác vụ cho worker không phản hồi.

2.3. Luồng Hoạt Động Tổng Quát

Một tác vụ traffic đi qua các bước sau:

Người vận hành tạo chiến dịch trên Admin Dashboard với từ khóa, domain mục tiêu và số lượng traffic.

Go API Backend lưu chiến dịch và tạo danh sách tác vụ cần thực thi.

Tools V2 định kỳ hỏi Go API có tác vụ mới không. Khi có, nó nhận về danh sách tác vụ và lưu vào MongoDB nội bộ.

Cron job của Tools V2 lấy tác vụ từ hàng đợi, yêu cầu proxy từ Go API, khởi động Chrome và thực thi.

Sau khi hoàn thành, Tools V2 chụp màn hình bằng chứng, upload lên cloud storage và gửi kết quả về Go API qua webhook.

Go API cập nhật trạng thái tác vụ. Admin Dashboard hiển thị kết quả và ảnh bằng chứng.

3. Nghiệp Vụ Thứ Nhất — Tạo Traffic Trình Duyệt

3.1. Mục Tiêu Nghiệp Vụ

Nghiệp vụ tạo traffic nhằm mục đích tác động đến các chỉ số SEO và quảng cáo của một domain. Tùy theo loại tác vụ, mục tiêu có thể là:

Tăng CTR (Click-Through Rate) cho quảng cáo Google Ads hoặc CocCoc Ads của khách hàng.

Tăng thứ hạng SEO tự nhiên bằng cách tạo organic traffic từ search engine.

Tăng lượng direct traffic cho domain.

Làm hại thứ hạng SEO của domain đối thủ bằng cách tăng bounce rate.

3.2. Tại Sao Cần Mô Phỏng Trình Duyệt Thực

Các search engine và nền tảng quảng cáo hiện đại có hệ thống phát hiện bot rất tinh vi. Chúng phân tích hàng chục tín hiệu để phân biệt người dùng thật với bot:

Fingerprint của trình duyệt: User-Agent, canvas fingerprint, WebGL renderer, danh sách fonts.

Hành vi tương tác: Cách di chuyển chuột, tốc độ gõ phím, pattern scroll.

Thông tin mạng: IP address, geolocation, timezone.

Lịch sử phiên: Cookies, localStorage, session history.

Nếu dùng HTTP request đơn thuần hoặc headless browser không được cấu hình đúng, các hệ thống này sẽ phát hiện và bỏ qua traffic, không tính vào số liệu thực. Tools V2 giải quyết vấn đề này bằng cách chạy Chrome thực với đầy đủ các biện pháp chống phát hiện.

3.3. Bốn Loại Traffic Flow

Ads Flow — Click Quảng Cáo:

Đây là luồng phức tạp nhất. Hệ thống mở Chrome, truy cập Google hoặc CocCoc, tìm kiếm từ khóa được cấu hình, sau đó tìm quảng cáo của domain mục tiêu trong trang kết quả. Quảng cáo được nhận diện qua nhãn "Tài trợ" hoặc "Sponsored". Sau khi click, hệ thống ở lại trang trong khoảng thời gian được cấu hình, mô phỏng hành vi đọc nội dung.

Mục tiêu của luồng này là tăng CTR cho chiến dịch quảng cáo của khách hàng, giúp quảng cáo được hiển thị nhiều hơn và ở vị trí tốt hơn.

Search Flow — Traffic Tự Nhiên:

Hệ thống tìm kiếm từ khóa trên search engine, tìm kết quả tự nhiên (organic) của domain mục tiêu trong SERP, click vào và duyệt web như người dùng thực. Hệ thống có thể truy cập nhiều trang con trong cùng domain, scroll và đọc nội dung trong thời gian ngẫu nhiên.

Mục tiêu là tăng organic traffic, cải thiện tín hiệu engagement mà Google dùng để đánh giá thứ hạng SEO.

Home Traffic Flow — Truy Cập Trực Tiếp:

Hệ thống truy cập thẳng URL đích mà không qua tìm kiếm, mô phỏng người dùng đã biết địa chỉ website và truy cập trực tiếp. Loại traffic này được tính là "direct traffic" trong Google Analytics.

Kill Flow — Negative SEO:

Hệ thống tìm kiếm từ khóa liên quan đến domain đối thủ, click vào kết quả của họ, nhưng thoát trang ngay lập tức. Hành vi này tạo ra bounce rate cao, một tín hiệu tiêu cực mà Google có thể dùng để đánh giá chất lượng trang.

3.4. Cách Hệ Thống Tránh Bị Phát Hiện

Tools V2 áp dụng nhiều lớp biện pháp để mô phỏng người dùng thực:

Stealth Browser Configuration:

Ẩn thuộc tính navigator.webdriver — đây là dấu hiệu đầu tiên mà các hệ thống phát hiện bot kiểm tra.

Giả mạo WebGL vendor và renderer để trông giống card đồ họa thực.

Randomize canvas fingerprint mỗi phiên để tránh bị nhận dạng qua fingerprinting.

Patch navigator.plugins để hiển thị danh sách plugin như browser thật.

Override permissions API để tránh các permission prompts bất thường.

Natural Behavior Simulation:

Di chuyển chuột theo đường cong Bezier tự nhiên thay vì đường thẳng.

Tốc độ di chuyển chuột biến thiên, có overshoot và correction movements.

Gõ phím với delay ngẫu nhiên từ 50 đến 150ms giữa các ký tự.

Scroll từ từ với easing function, pause tại các điểm quan trọng.

Thời gian ở lại trang được tính dựa trên số lượng từ trong trang, thêm random variance.

Proxy và Identity Management:

Mỗi phiên dùng một proxy riêng biệt để có IP khác nhau.

Geolocation của browser được cấu hình khớp với vị trí địa lý của proxy.

Timezone được set theo geolocation.

User-Agent được chọn phù hợp với loại thiết bị (desktop Windows, desktop Mac, Android, iOS).

Resource Blocking:

Block images, fonts, stylesheets không cần thiết để tăng tốc độ load trang.

Block tracking scripts của bên thứ ba.

Chỉ load những gì cần thiết cho việc tìm kiếm và click.

3.5. Quản Lý Đồng Thời

Mỗi worker có thể chạy nhiều phiên Chrome đồng thời. Số lượng phiên tối đa được kiểm soát bởi CRON_TASK_LIMIT. Hệ thống phân bổ tài nguyên thông minh:

Ưu tiên Kill Flow trước vì cần ít thời gian nhất.

Tiếp theo là Home Traffic Flow.

Sau đó là Ads Flow (Google Ads click).

Cuối cùng là CocCoc Ads click.

Mỗi loại task có giới hạn riêng để tránh một loại chiếm hết tài nguyên. Các browser được khởi động cách nhau 3 giây để tránh spike CPU.

3.6. Xử Lý Lỗi Và Retry

Khi một tác vụ thất bại, hệ thống không bỏ qua mà thực hiện retry:

Task được reset về trạng thái PENDING và đưa lại vào hàng đợi.

Số lần retry được theo dõi qua trường retries_total.

Khi vượt quá TASK_RETRY_LIMIT, task bị đánh dấu thất bại và xóa khỏi hàng đợi.

Các task bị kẹt ở trạng thái PROCESSING quá 20 phút được tự động reset về PENDING.

Cơ chế này đảm bảo rằng ngay cả khi server bị tắt đột ngột, các task đang chạy sẽ được retry khi server khởi động lại.

4. Nghiệp Vụ Thứ Hai — Báo Cáo Bảo Mật Tự Động

4.1. Mục Tiêu Nghiệp Vụ

Nghiệp vụ báo cáo bảo mật nhằm mục đích tự động gửi báo cáo về các domain vi phạm đến các tổ chức và nền tảng bảo mật trên toàn cầu. Khi một domain bị báo cáo đến đủ nhiều nền tảng, nó có thể bị đưa vào danh sách đen, bị chặn bởi các trình duyệt, bị xóa khỏi kết quả tìm kiếm, hoặc bị đình chỉ dịch vụ.

Đây là công cụ phục vụ cho các chiến dịch bảo vệ thương hiệu, chống phishing, chống quảng cáo gian lận và loại bỏ nội dung vi phạm.

4.2. Hai Phương Thức Báo Cáo

Browser-Based Reports — Điền Form Trực Tiếp:

Hệ thống mở Chrome, điều hướng đến trang báo cáo của nền tảng, điền form với nội dung được tạo bởi AI, xử lý CAPTCHA nếu có, và submit. Phương thức này được dùng cho các nền tảng yêu cầu tương tác trực tiếp trên website.

Các nền tảng tiêu biểu sử dụng phương thức này:

Google Safe Browsing — Báo cáo phishing và malware.

Microsoft SmartScreen — Báo cáo website nguy hiểm.

Cloudflare — Báo cáo lạm dụng dịch vụ Cloudflare.

Spamhaus — Báo cáo spam và malware.

Netcraft — Báo cáo phishing.

ESET, Kaspersky, Fortinet — Báo cáo đến các hãng antivirus.

Google Ads — Báo cáo vi phạm chính sách quảng cáo.

US-CERT, CISA, NCSC — Báo cáo đến các cơ quan an ninh mạng chính phủ.

AdGuard, Mozilla Firefox — Báo cáo đến các nhà cung cấp trình duyệt và bộ lọc.

Email-Based Reports — Gửi Email Tự Động:

Hệ thống tạo nội dung email bằng AI, sau đó gửi đến địa chỉ abuse của từng nền tảng qua SMTP. Phương thức này được dùng cho các nền tảng nhận báo cáo qua email.

Các nền tảng tiêu biểu sử dụng phương thức này:

Google (Ads Abuse, Gmail Abuse, Play Abuse, YouTube Abuse, Cloud Compliance).

Microsoft, PayPal.

Các hãng antivirus: Kaspersky, ESET, Avast, McAfee, Bitdefender, Sophos.

Các tổ chức chống phishing: OpenPhish, APWG, Abusix, Talos, Symantec.

Các nhà cung cấp threat intelligence: AlphaSoc, AiLabs, MalwarePatrol, Sucuri.

Hơn 80 nền tảng khác từ danh sách VirusTotal vendors.

4.3. Vai Trò Của AI Trong Báo Cáo

Mỗi nền tảng có yêu cầu khác nhau về nội dung báo cáo. Google Safe Browsing cần mô tả kỹ thuật về phishing. Spamhaus cần thông tin về spam infrastructure. Các hãng antivirus cần mô tả về malware behavior.

Thay vì hardcode nội dung cho từng nền tảng, Tools V2 sử dụng GPT-4o-mini để tạo nội dung phù hợp:

Mỗi nền tảng có một prompt riêng được lưu trên Go API Backend.

Khi cần tạo báo cáo, hệ thống lấy prompt từ API, cung cấp thông tin về domain cần báo cáo, và yêu cầu AI tạo nội dung theo format của nền tảng đó.

AI trả về nội dung dạng JSON với các trường tương ứng với form fields của nền tảng.

Hệ thống điền các trường này vào form và submit.

Cách tiếp cận này cho phép cập nhật nội dung báo cáo mà không cần thay đổi code. Khi một nền tảng thay đổi form, chỉ cần cập nhật prompt trên Go API.

4.4. Xử Lý CAPTCHA Trong Báo Cáo

Nhiều nền tảng bảo mật sử dụng CAPTCHA để ngăn chặn báo cáo tự động. Tools V2 xử lý điều này theo hai cách:

Qua Anti-Captcha API:

Hệ thống gửi thông tin CAPTCHA (site key, URL) đến dịch vụ Anti-Captcha. Dịch vụ này dùng người thật hoặc AI để giải CAPTCHA và trả về token. Hệ thống submit token này vào form.

Qua OpenAI Vision (Fallback):

Khi Anti-Captcha API thất bại hoặc không khả dụng, hệ thống chụp screenshot vùng CAPTCHA và gửi đến GPT-4o-mini Vision API. AI phân tích hình ảnh và trả về answer hoặc tọa độ cần click.

4.5. Bằng Chứng Báo Cáo

Sau mỗi báo cáo thành công, hệ thống chụp màn hình trang confirmation và upload lên cloud storage. URL ảnh được gửi về Go API để Admin Dashboard hiển thị bằng chứng cho từng báo cáo.

5. Quản Lý Proxy

5.1. Tại Sao Proxy Quan Trọng

Proxy là yếu tố then chốt để traffic được tính là hợp lệ. Nếu nhiều phiên trình duyệt cùng dùng một IP, các search engine sẽ phát hiện pattern bất thường và bỏ qua traffic đó. Mỗi phiên cần một IP khác nhau, lý tưởng là IP từ đúng quốc gia và nhà mạng của người dùng mục tiêu.

5.2. Nguồn Proxy

Tools V2 sử dụng proxy từ nhiều nguồn:

ZingProxy là nguồn proxy chính, cung cấp proxy chất lượng cao với IP sạch từ nhiều quốc gia. Kết nối qua API với ZING_PROXY_API_KEY.

Proxy từ Go API là proxy được Go API Backend cấp phát cho từng task cụ thể qua proxy_webhook URL. Đây là cơ chế linh hoạt cho phép Go API kiểm soát việc phân bổ proxy.

Free Proxy là proxy miễn phí từ các nguồn công cộng, lưu trong thư mục working-proxies/. Chất lượng thấp hơn, chỉ dùng khi không có lựa chọn khác.

5.3. Cơ Chế Cấp Phát Proxy

Mỗi task group trong hệ thống có một trường proxy_webhook — đây là URL mà Tools V2 gọi để lấy proxy cho task đó. Khi task được thực thi:

Tools V2 gọi proxy_webhook URL.

Go API trả về thông tin proxy phù hợp (host, port, username, password, type).

Tools V2 cấu hình proxy này cho browser context của task.

Sau khi task hoàn thành, proxy được giải phóng.

Cơ chế này cho phép Go API kiểm soát hoàn toàn việc phân bổ proxy, đảm bảo không có hai task nào dùng cùng proxy cùng lúc.

5.4. Các Loại Proxy Được Hỗ Trợ

HTTP proxy.

HTTPS proxy.

SOCKS4 proxy.

SOCKS5 proxy.

Mỗi loại được xử lý bởi agent tương ứng: https-proxy-agent cho HTTP/HTTPS và socks-proxy-agent cho SOCKS4/SOCKS5.

6. Quản Lý Browser Profile

6.1. Profile Là Gì

Browser Profile là một danh tính kỹ thuật số hoàn chỉnh, bao gồm:

Tài khoản Google với email, password và refresh token.

Thông tin thiết bị: User-Agent, screen resolution, device type, operating system.

Thông tin địa lý: country, timezone, latitude, longitude.

Session data: cookies, localStorage từ các lần sử dụng trước.

Profile được dùng cho các tác vụ cần đăng nhập Google hoặc cần lịch sử duyệt web nhất quán. Khi dùng profile, browser trông giống một người dùng thực đã có lịch sử sử dụng, thay vì một browser mới hoàn toàn.

6.2. Tại Sao Profile Quan Trọng

Google và các nền tảng khác đánh giá độ tin cậy của một phiên duyệt web dựa trên nhiều yếu tố, trong đó có lịch sử tài khoản. Một tài khoản Google đã tồn tại lâu, có lịch sử tìm kiếm và hoạt động bình thường sẽ được tin tưởng hơn một browser mới hoàn toàn.

Ngoài ra, session data được lưu lại giúp tránh phải đăng nhập lại mỗi lần, giảm thời gian thực thi và giảm nguy cơ bị phát hiện qua hành vi đăng nhập bất thường.

6.3. Vòng Đời Profile

Profile được tạo và quản lý trên Go API Backend, sau đó đồng bộ xuống Tools V2.

Sau mỗi lần sử dụng, session data (cookies, localStorage) được lưu lại để dùng cho lần sau.

Profile được đặt cooldown sau khi sử dụng để tránh dùng quá nhiều trong thời gian ngắn.

Nếu đăng nhập thất bại nhiều lần liên tiếp, profile bị vô hiệu hóa tự động.

7. Lưu Trữ Bằng Chứng

7.1. Mục Đích

Sau mỗi tác vụ thành công, hệ thống chụp màn hình bằng chứng để:

Xác nhận tác vụ đã được thực thi thực sự, không phải giả mạo kết quả.

Cung cấp bằng chứng trực quan cho người vận hành xem trên Admin Dashboard.

Lưu lại lịch sử để kiểm tra khi có tranh chấp.

7.2. Chiến Lược Lưu Trữ

Hệ thống lưu ảnh theo thứ tự ưu tiên:

DigitalOcean Spaces là lựa chọn đầu tiên. Đây là dịch vụ object storage tương thích S3, có CDN tích hợp, URL công khai và tốc độ truy cập nhanh từ Đông Nam Á (region Singapore).

Cloudinary là lựa chọn dự phòng khi DigitalOcean Spaces không khả dụng. Cloudinary cũng cung cấp CDN và hỗ trợ transformation ảnh.

Local storage là lựa chọn cuối cùng, lưu ảnh trong thư mục storage/screenshots/ trên server. Chỉ dùng khi cả hai cloud storage đều không khả dụng.

7.3. Quy Trình Upload

Chụp screenshot toàn trang hoặc viewport tùy cấu hình.

Compress ảnh để giảm kích thước file.

Upload lên cloud storage và nhận URL.

Gửi URL về Go API qua webhook.

Go API lưu URL vào database để Admin Dashboard hiển thị.

8. Tính Tự Phục Hồi

8.1. Crash Recovery

Một trong những tính năng quan trọng nhất của Tools V2 là khả năng tự phục hồi sau sự cố. Khi server bị tắt đột ngột hoặc crash:

Khi khởi động lại, hệ thống đọc tất cả task groups có trạng thái PROCESSING từ MongoDB.

Các task này được reset về PENDING và đưa lại vào hàng đợi.

Cron job tiếp tục thực thi các task này như bình thường.

Cơ chế này đảm bảo không có task nào bị mất khi server gặp sự cố.

8.2. Stuck Task Recovery

Đôi khi một task có thể bị kẹt ở trạng thái PROCESSING mà không tiến triển, ví dụ khi Chrome crash mà không được xử lý đúng cách. Hệ thống xử lý tình huống này bằng cách:

Định kỳ kiểm tra các task đã ở trạng thái PROCESSING quá 20 phút.

Các task này được reset về PENDING để retry.

Log ghi lại số lượng task được reset để theo dõi.

8.3. Retry Limit

Để tránh một task lỗi liên tục chiếm tài nguyên mãi mãi, hệ thống có giới hạn retry:

Mỗi lần task được reset về PENDING, retries_total tăng lên 1.

Khi retries_total vượt quá TASK_RETRY_LIMIT, task bị đánh dấu thất bại.

Tất cả các task con trong group được đánh dấu ERROR với thông báo lý do.

Task group bị xóa khỏi MongoDB.

9. Tích Hợp Với Go API Backend

9.1. Cách Tools V2 Nhận Tác Vụ

Tools V2 không chờ Go API push tác vụ xuống. Thay vào đó, nó chủ động hỏi Go API mỗi giây:

Cron job task-group-api-request-cron chạy mỗi giây.

Nó kiểm tra số lượng task đang pending và processing trong MongoDB nội bộ.

Nếu tổng số task thấp hơn ngưỡng tối thiểu (thường là maxProcess * 2), nó request thêm task từ Go API.

Số lượng task request mỗi lần tối đa là maxProcess * 10, không vượt quá 300.

Cơ chế này đảm bảo hàng đợi luôn có đủ task để worker không bị idle, đồng thời không request quá nhiều task gây lãng phí.

9.2. Cách Tools V2 Gửi Kết Quả

Sau khi hoàn thành một task, Tools V2 gửi kết quả về Go API qua webhook:

Endpoint: [API_HOST]/webhook/task/update-status.

Payload bao gồm: task ID, trạng thái (thành công/thất bại), URL ảnh bằng chứng, thời gian thực thi.

Xác thực bằng WEBHOOK_API_KEY trong header.

9.3. Cách Tools V2 Nhận Tác Vụ Báo Cáo

Tương tự traffic tasks, report tasks cũng được lấy qua polling:

Cron job report-task-api-request-cron chạy mỗi giây.

Mỗi lần có thể request tối đa 10 batch.

Mỗi batch chứa một report task.

Khi không còn task nào, vòng lặp dừng lại.

9.4. Xác Thực Giao Tiếp

Tất cả giao tiếp giữa Tools V2 và Go API đều được xác thực:

Requests từ Tools V2 đến Go API dùng API_KEY trong header.

Webhook từ Go API đến Tools V2 dùng WEBHOOK_API_KEY trong header.

Proxy requests dùng PROXY_API_KEY riêng biệt.

IP whitelist (IP_ALLOWED) kiểm soát IP nào được phép gọi API của Tools V2.

10. Giám Sát Trạng Thái

10.1. Endpoint Giám Sát

Tools V2 cung cấp các endpoint để giám sát trạng thái từ bên ngoài mà không cần SSH vào server:

GET / trả về trạng thái tổng quan: số Chrome instances đang chạy, số task đang xử lý, số proxy đang dùng.

GET /health trả về health check đơn giản với status, uptime và timestamp.

GET /logs?filePath=... cho phép đọc file log từ xa.

10.2. Thông Tin Trạng Thái

Response của GET / cung cấp:

browserSessionRunning: Số Chrome instances đang chạy. Nếu con số này liên tục bằng BROWSER_LIMIT_PER_PROCESS, worker đang chạy full capacity.

task.maxProcess: Giới hạn task đồng thời tối đa.

task.totalProcessRunning: Số task đang thực thi.

proxy.totalProcessRunning: Số proxy đang được sử dụng.

proxy.processRunning: Danh sách ID các proxy đang dùng.

10.3. Đọc Log Từ Xa

Thay vì SSH vào server để đọc log, người vận hành có thể dùng endpoint /logs:

GET /logs?filePath=app/2026-03-26/error.log — Đọc error log của ngày cụ thể.

GET /logs?filePath=task/2026-03-26/combined.log — Đọc task log.

GET /logs?filePath=browser_manager/2026-03-26/crash.log — Đọc browser crash log.

Log được tổ chức theo service và ngày, giúp dễ dàng tìm kiếm và phân tích.

11. Các Giới Hạn Vận Hành

11.1. Giới Hạn Đồng Thời

Hệ thống có các giới hạn để tránh quá tải server:

CRON_TASK_LIMIT: Số task traffic chạy đồng thời tối đa. Mặc định 25 trong production.

CRON_REPORT_LIMIT: Số report task chạy đồng thời tối đa. Mặc định 2 trong production.

CRON_SEARCH_LIMIT: Số search task chạy đồng thời tối đa. Mặc định 1 trong production.

BROWSER_LIMIT_PER_PROCESS: Tổng số Chrome instances tối đa. Đây là hard limit tuyệt đối.

11.2. Tại Sao Cần Giới Hạn

Mỗi Chrome instance tiêu thụ khoảng 200-400MB RAM và một lượng CPU đáng kể. Nếu không có giới hạn, server có thể hết RAM và crash. Các giới hạn này được cấu hình dựa trên RAM và CPU của từng server.

Ví dụ với server 16GB RAM:

Dành 4GB cho hệ điều hành và các process khác.

12GB còn lại cho Chrome instances.

Mỗi Chrome instance trung bình 300MB.

Tối đa khoảng 40 instances, nhưng nên đặt giới hạn ở 28-30 để có buffer.

11.3. Staggered Launch

Để tránh spike CPU khi nhiều Chrome instances khởi động cùng lúc, hệ thống khởi động mỗi browser cách nhau 3 giây. Điều này giúp CPU load được phân bổ đều hơn và tránh tình trạng server bị quá tải trong thời gian ngắn.

12. Tóm Tắt Điểm Mạnh Và Giới Hạn

12.1. Điểm Mạnh

Mô phỏng hành vi người dùng thực ở mức độ cao, khó bị phát hiện bởi các hệ thống anti-bot hiện đại.

Hỗ trợ hơn 100 nền tảng báo cáo bảo mật, bao gồm cả browser-based và email-based.

Kiến trúc phân tán cho phép scale horizontal bằng cách thêm server mới mà không cần thay đổi cấu hình.

Tự phục hồi sau crash, không mất task khi server gặp sự cố.

Nội dung báo cáo được tạo bởi AI, có thể cập nhật mà không cần thay đổi code.

Hệ thống proxy linh hoạt, hỗ trợ nhiều loại proxy và nhiều nguồn cung cấp.

12.2. Giới Hạn Cần Lưu Ý

Mỗi Chrome instance tiêu thụ nhiều RAM. Server cần đủ RAM để chạy số lượng instance mong muốn.

Chất lượng proxy ảnh hưởng trực tiếp đến tỷ lệ thành công. Proxy bị block hoặc chậm sẽ làm giảm hiệu quả.

Các nền tảng như Google liên tục cập nhật hệ thống phát hiện bot. Cần theo dõi và điều chỉnh cấu hình định kỳ.

CAPTCHA solving có chi phí (Anti-Captcha API tính phí theo số lần giải). Cần theo dõi số dư tài khoản.

OpenAI API có chi phí theo số token. Cần theo dõi usage để kiểm soát chi phí.

13. Chi Tiết Các Loại Traffic Flow

13.1. Ads Flow — Phân Tích Chi Tiết

Ads Flow là luồng phức tạp nhất trong hệ thống vì nó yêu cầu tìm đúng quảng cáo của domain mục tiêu trong một trang kết quả tìm kiếm có thể chứa nhiều quảng cáo của nhiều domain khác nhau.

Thách thức kỹ thuật:

Trang SERP của Google thay đổi cấu trúc HTML thường xuyên. Quảng cáo có thể xuất hiện ở đầu trang, cuối trang, hoặc xen kẽ với kết quả tự nhiên. Nhãn "Tài trợ" có thể có nhiều dạng HTML khác nhau tùy theo phiên bản Google đang thử nghiệm.

Hệ thống xử lý điều này bằng cách:

Sử dụng nhiều selector CSS khác nhau để tìm quảng cáo, không phụ thuộc vào một selector duy nhất.

Kiểm tra nhiều dấu hiệu nhận diện quảng cáo: class CSS, aria-label, data attributes, URL tracking parameters.

Tính confidence score cho mỗi element tìm được. Chỉ click khi confidence đạt ngưỡng tối thiểu.

Nếu không tìm thấy quảng cáo của domain mục tiêu, task được đánh dấu thất bại và retry sau.

Hành vi sau khi click:

Sau khi click vào quảng cáo, hệ thống không thoát ngay mà ở lại trang trong khoảng thời gian được cấu hình trong task (time_on_page). Trong thời gian này:

Scroll trang từ từ để mô phỏng đọc nội dung.

Di chuyển chuột ngẫu nhiên trên trang.

Đôi khi click vào các link nội bộ trong trang.

Thời gian ở lại có random variance để tránh pattern đều đặn.

Hỗ trợ đa nền tảng:

Ads Flow hỗ trợ cả Google Ads và CocCoc Ads. Với CocCoc, hệ thống sử dụng CocCoc Flow riêng biệt vì cấu trúc SERP của CocCoc khác với Google.

13.2. Search Flow — Phân Tích Chi Tiết

Search Flow mô phỏng người dùng tìm kiếm thông tin và tìm thấy website của khách hàng trong kết quả tự nhiên.

Tìm kiếm từ khóa:

Hệ thống gõ từ khóa vào ô tìm kiếm với delay ngẫu nhiên giữa các ký tự, mô phỏng tốc độ gõ của người thật. Đôi khi có typo và correction. Sau khi gõ xong, nhấn Enter hoặc click nút tìm kiếm.

Tìm kết quả mục tiêu:

Trong trang SERP, hệ thống tìm kết quả tự nhiên của domain mục tiêu. Kết quả tự nhiên được phân biệt với quảng cáo bằng cách loại trừ các elements có dấu hiệu quảng cáo. Nếu domain mục tiêu không xuất hiện trong trang đầu, task được đánh dấu thất bại.

Duyệt web sau khi click:

Sau khi click vào kết quả, hệ thống duyệt web như người dùng thực:

Đọc nội dung trang chính trong thời gian tương ứng với số lượng từ.

Có thể click vào các link nội bộ để truy cập trang con.

Scroll tự nhiên, pause tại các heading và hình ảnh.

Thời gian tổng trên website theo cấu hình time_on_page.

13.3. Kill Flow — Phân Tích Chi Tiết

Kill Flow được thiết kế để tạo ra tín hiệu tiêu cực cho domain đối thủ thông qua bounce rate cao.

Cơ chế hoạt động:

Bounce rate là tỷ lệ người dùng vào trang rồi thoát ngay mà không tương tác thêm. Google sử dụng bounce rate như một trong nhiều tín hiệu để đánh giá chất lượng trang. Bounce rate cao có thể là dấu hiệu nội dung không phù hợp với từ khóa tìm kiếm.

Kill Flow tạo ra bounce rate cao bằng cách:

Tìm kiếm từ khóa liên quan đến domain đối thủ.

Click vào kết quả của domain đối thủ.

Thoát trang ngay lập tức, không scroll hay tương tác.

Lặp lại từ nhiều IP khác nhau để tạo pattern đáng kể.

Tỷ lệ Kill Traffic:

Biến KILL_TRAFFIC_RATIO (mặc định 0.8) kiểm soát tỷ lệ task được phân loại là kill traffic trong tổng số task. Điều này cho phép điều chỉnh mức độ tấn công.

13.4. Home Traffic Flow — Phân Tích Chi Tiết

Home Traffic Flow tạo ra direct traffic — loại traffic mà người dùng truy cập trực tiếp vào website mà không qua search engine hay link từ trang khác.

Ý nghĩa của Direct Traffic:

Direct traffic là tín hiệu mạnh về brand awareness. Khi nhiều người truy cập trực tiếp vào một website, điều đó cho thấy họ đã biết đến thương hiệu và nhớ địa chỉ website. Google và các analytics platform đánh giá cao loại traffic này.

Đa nền tảng:

Khi tạo Home Traffic task, hệ thống tự động tạo 4 biến thể cho 4 nền tảng: Windows Desktop, MacOS Desktop, Android Mobile, iOS Mobile. Mỗi nền tảng có User-Agent, screen resolution và fingerprint riêng biệt, tạo ra traffic đa dạng hơn và tự nhiên hơn.

Giới Hạn Per Target:

Biến HOME_TRAFFIC_PER_TARGET_LIMIT (mặc định 3) giới hạn số lượng home traffic task đang chạy đồng thời cho cùng một URL mục tiêu. Điều này tránh tình trạng quá nhiều phiên truy cập cùng một URL cùng lúc, tạo ra pattern bất thường.

14. Chi Tiết Hệ Thống Báo Cáo

14.1. Quy Trình Tạo Báo Cáo Đầy Đủ

Khi một report task được tạo, quy trình diễn ra như sau:

Bước 1 — Nhận Task:

Go API tạo report task với thông tin domain cần báo cáo và danh sách nền tảng cần báo cáo đến. Tools V2 nhận task này qua polling cron job.

Bước 2 — Lấy Cấu Hình:

Với mỗi nền tảng, hệ thống lấy cấu hình từ Go API:

Prompt cho AI: Mô tả role, context và yêu cầu nội dung.

GPT config: Model, temperature, max_tokens, response_format.

Response config: Danh sách required fields, mapping với form fields.

Cấu hình được cache 1 giờ để giảm số lần gọi API. Nếu API không khả dụng, hệ thống dùng fallback prompts được lưu trong thư mục prompts/fallback/.

Bước 3 — Tạo Nội Dung:

Hệ thống gọi GPT-4o-mini với prompt đã lấy và thông tin về domain cần báo cáo. AI trả về nội dung báo cáo dạng JSON với các trường tương ứng với form fields của nền tảng.

Ví dụ với Google Safe Browsing, AI trả về:

url: URL cần báo cáo.

description: Mô tả về hành vi phishing hoặc malware.

additionalInfo: Thông tin bổ sung về cách phát hiện.

Bước 4 — Thực Thi Báo Cáo:

Với browser-based platforms:

Mở Chrome và điều hướng đến trang báo cáo.

Điền form với nội dung từ AI.

Xử lý CAPTCHA nếu xuất hiện.

Submit form và chờ confirmation.

Chụp màn hình bằng chứng.

Với email-based platforms:

Tạo email với subject và body từ AI.

Gửi qua SMTP đến địa chỉ abuse của nền tảng.

Log kết quả gửi.

Bước 5 — Gửi Kết Quả:

Sau khi hoàn thành, hệ thống gửi kết quả về Go API:

Trạng thái: COMPLETED hoặc FAILED.

URL ảnh bằng chứng (nếu có).

Thông báo lỗi (nếu thất bại).

Thời gian thực thi.

14.2. Xử Lý Thất Bại Trong Báo Cáo

Báo cáo có thể thất bại vì nhiều lý do:

Nền tảng thay đổi cấu trúc form.

CAPTCHA không giải được.

Network timeout.

AI tạo nội dung không đúng format.

Khi thất bại, task được đánh dấu FAILED với thông báo lỗi chi tiết. Go API có thể tạo lại task để retry sau.

14.3. Danh Sách Đầy Đủ Nền Tảng Browser-Based

Các nền tảng báo cáo qua form trực tiếp:

Google Safe Browsing — Báo cáo phishing, malware, unwanted software.

Microsoft SmartScreen — Báo cáo website nguy hiểm cho Windows Defender.

Cloudflare — Báo cáo lạm dụng dịch vụ Cloudflare (DDoS, phishing, spam).

Spamhaus — Báo cáo spam infrastructure, botnet, malware hosting.

Google Ads Policy Violation — Báo cáo vi phạm chính sách quảng cáo Google.

Google Ads Third-party — Báo cáo quảng cáo của bên thứ ba vi phạm.

Google Ads Other — Báo cáo các vi phạm khác liên quan đến Google Ads.

Google Legal Troubleshooter — Báo cáo vi phạm pháp lý qua công cụ troubleshooter.

Google Legal Specific — Báo cáo vi phạm pháp lý cụ thể.

Google Legal Category 2 — Báo cáo vi phạm pháp lý danh mục 2.

Google Play — Báo cáo ứng dụng vi phạm trên Google Play Store.

ESET — Báo cáo malware đến hãng antivirus ESET.

Mozilla Firefox WebCompat — Báo cáo website không tương thích với Firefox.

AdGuard — Báo cáo quảng cáo độc hại đến AdGuard.

Netcraft — Báo cáo phishing đến tổ chức Netcraft.

US-CERT — Báo cáo đến United States Computer Emergency Readiness Team.

CRDF — Báo cáo đến Cyber Research and Defense Foundation.

Kaspersky — Báo cáo malware đến hãng antivirus Kaspersky.

Fortinet — Báo cáo đến hãng bảo mật Fortinet.

CISA — Báo cáo đến Cybersecurity and Infrastructure Security Agency.

NCSC — Báo cáo đến National Cyber Security Centre.

14.4. Danh Sách Đầy Đủ Nền Tảng Email-Based

Các nền tảng nhận báo cáo qua email:

Google Email — Địa chỉ abuse chung của Google.

Google Cloud Compliance — Báo cáo vi phạm trên Google Cloud.

Google Spam Gmail — Báo cáo spam qua Gmail.

Google Ads Abuse — Báo cáo lạm dụng Google Ads.

Google Ads Noreply — Báo cáo đến địa chỉ noreply của Google Ads.

Google Play Abuse — Báo cáo lạm dụng Google Play.

Google YouTube Abuse — Báo cáo lạm dụng YouTube.

Google Gmail Abuse — Báo cáo lạm dụng Gmail.

Microsoft — Báo cáo đến Microsoft Security.

PayPal — Báo cáo phishing liên quan đến PayPal.

Abusix — Báo cáo đến dịch vụ abuse reporting Abusix.

Acronis — Báo cáo đến hãng bảo mật Acronis.

AdminusLabs — Báo cáo đến AdminusLabs threat intelligence.

AiLabs MonitorApp — Báo cáo đến AiLabs.

AlienVault — Báo cáo đến AlienVault OTX.

AlphaSoc — Báo cáo đến AlphaSoc threat intelligence.

Antiy AVL — Báo cáo đến hãng antivirus Antiy.

Bitdefender — Báo cáo đến hãng antivirus Bitdefender.

Blueliv — Báo cáo đến Blueliv threat intelligence.

Certego — Báo cáo đến Certego security.

Chong Lua Dao — Báo cáo đến tổ chức chống lừa đảo Việt Nam.

CRDF — Báo cáo đến CRDF qua email.

Criminal IP — Báo cáo đến Criminal IP threat intelligence.

Cyble — Báo cáo đến Cyble threat intelligence.

CyRadar — Báo cáo đến CyRadar.

DNS8 — Báo cáo đến DNS8 security.

Dr.Web — Báo cáo đến hãng antivirus Dr.Web.

EmergingThreats — Báo cáo đến EmergingThreats.

Emsisoft — Báo cáo đến hãng antivirus Emsisoft.

ESTsecurity — Báo cáo đến ESTsecurity.

Feodo Tracker — Báo cáo đến Feodo Tracker botnet database.

Forcepoint ThreatSeeker — Báo cáo đến Forcepoint.

G Data — Báo cáo đến hãng antivirus G Data.

GreenSnow — Báo cáo đến GreenSnow blacklist.

Heimdal Security — Báo cáo đến Heimdal Security.

Ipsum — Báo cáo đến Ipsum threat intelligence.

Juniper Networks — Báo cáo đến Juniper Networks.

MalwareD — Báo cáo đến MalwareD.

MalwarePatrol — Báo cáo đến MalwarePatrol.

OpenPhish — Báo cáo đến OpenPhish phishing database.

Phishing Database — Báo cáo đến Phishing Database.

Và nhiều nền tảng khác từ danh sách VirusTotal vendors.

15. Nguyên Tắc Thiết Kế

15.1. Tự Động Hoàn Toàn

Tools V2 được thiết kế để vận hành không cần sự can thiệp của con người sau khi cấu hình ban đầu. Mọi quyết định — từ việc chọn proxy, chọn profile, xử lý lỗi, đến retry — đều được thực hiện tự động.

Điều này có nghĩa là:

Không có màn hình quản lý riêng cho Tools V2. Tất cả quản lý được thực hiện qua Admin Dashboard.

Khi có lỗi, hệ thống tự xử lý và retry. Chỉ khi lỗi vượt quá giới hạn retry mới cần can thiệp thủ công.

Khi server restart, hệ thống tự phục hồi trạng thái và tiếp tục công việc.

15.2. Độc Lập Và Phân Tán

Mỗi instance Tools V2 hoạt động độc lập. Nó không biết về sự tồn tại của các instance khác. Sự phối hợp giữa các instance được thực hiện hoàn toàn bởi Go API Backend.

Điều này có nghĩa là:

Thêm hoặc xóa một instance không ảnh hưởng đến các instance khác.

Một instance bị crash không làm ảnh hưởng đến toàn bộ hệ thống.

Mỗi instance có thể được cấu hình khác nhau (số lượng task, loại proxy, giới hạn browser).

15.3. Ưu Tiên Độ Tin Cậy

Hệ thống ưu tiên độ tin cậy hơn hiệu suất tối đa. Điều này thể hiện qua:

Staggered browser launch (3 giây giữa mỗi browser) để tránh spike CPU.

Retry logic với exponential backoff thay vì retry ngay lập tức.

Crash recovery tự động để không mất task.

Giới hạn đồng thời để tránh quá tải server.

15.4. Quan Sát Được

Hệ thống được thiết kế để dễ quan sát và debug:

Log chi tiết cho mỗi bước thực thi.

Log được tổ chức theo service và ngày để dễ tìm kiếm.

Endpoint /logs cho phép đọc log từ xa.

Endpoint / cung cấp snapshot trạng thái hiện tại.

Mỗi task có ID duy nhất để trace qua toàn bộ hệ thống.

16. Hành Vi Mô Phỏng Người Dùng — Chi Tiết Kỹ Thuật

16.1. Tại Sao Hành Vi Tự Nhiên Quan Trọng

Các hệ thống phát hiện bot hiện đại không chỉ kiểm tra fingerprint của trình duyệt mà còn phân tích hành vi tương tác. Một bot điển hình di chuyển chuột theo đường thẳng, click chính xác vào tọa độ, scroll đều đặn và không có sự do dự. Người dùng thực thì ngược lại — họ di chuyển chuột theo đường cong không đều, đôi khi overshoot rồi correction, scroll không đều và có những khoảng dừng ngẫu nhiên.

Google và Cloudflare sử dụng machine learning để phân tích các pattern hành vi này. Nếu hành vi quá đều đặn hoặc quá hoàn hảo, hệ thống sẽ đánh dấu là bot.

16.2. Ghost Cursor — Di Chuyển Chuột Tự Nhiên

Tools V2 sử dụng thư viện ghost-cursor để tạo ra chuyển động chuột tự nhiên:

Đường di chuyển được tạo bằng đường cong Bezier với các control points ngẫu nhiên.

Tốc độ di chuyển không đều — nhanh ở giữa đường đi, chậm lại khi gần đến đích.

Có overshoot nhỏ và correction movement khi đến gần đích.

Pause ngẫu nhiên từ 50 đến 200ms giữa các movements.

Đôi khi di chuyển chuột ra khỏi element rồi quay lại, mô phỏng sự do dự.

16.3. Scroll Behavior — Đọc Nội Dung Tự Nhiên

Khi ở lại trang sau khi click, hệ thống scroll trang theo cách tự nhiên:

Bắt đầu từ đầu trang, scroll xuống từ từ với easing function (chậm ở đầu, nhanh ở giữa, chậm lại ở cuối).

Pause tại các điểm quan trọng như headings, hình ảnh lớn, hoặc đoạn văn dài.

Đôi khi scroll ngược lên để đọc lại một đoạn, mô phỏng hành vi đọc thực.

Tốc độ scroll biến thiên theo độ dài nội dung — trang dài thì scroll nhanh hơn.

Không scroll đến cuối trang trong mọi trường hợp — người dùng thực thường không đọc hết trang.

16.4. Typing Simulation — Gõ Phím Tự Nhiên

Khi gõ từ khóa vào ô tìm kiếm:

Delay ngẫu nhiên từ 50 đến 150ms giữa mỗi ký tự, mô phỏng tốc độ gõ của người thật.

Đôi khi có typo (gõ sai ký tự) rồi backspace và gõ lại.

Pause dài hơn sau dấu cách và dấu câu.

Tốc độ gõ biến thiên — đôi khi nhanh, đôi khi chậm lại như đang suy nghĩ.

16.5. Reading Time Calculation — Thời Gian Đọc Thực Tế

Thời gian ở lại trang không phải là một con số cố định mà được tính dựa trên nội dung thực tế của trang:

Đếm số lượng từ trong nội dung chính của trang.

Tính thời gian đọc dựa trên tốc độ đọc trung bình của người Việt Nam (khoảng 200-250 từ/phút).

Thêm random variance từ 20 đến 30% để tránh pattern đều đặn.

Áp dụng giới hạn tối thiểu (30 giây) và tối đa (theo cấu hình time_on_page).

Cách tính này tạo ra thời gian ở lại trang tự nhiên hơn so với việc dùng một con số cố định.

17. Quản Lý Tài Nguyên Hệ Thống

17.1. Memory Management

Chrome là ứng dụng tiêu thụ nhiều RAM. Mỗi Chrome instance với một tab mở tiêu thụ khoảng 200-400MB RAM tùy theo nội dung trang. Khi chạy 25 instances đồng thời, tổng RAM tiêu thụ có thể lên đến 5-10GB.

Hệ thống quản lý memory bằng cách:

Đóng browser ngay sau khi task hoàn thành, không giữ browser idle.

Dọn dẹp user data directory sau mỗi phiên để giải phóng disk space.

Định kỳ kiểm tra và dọn dẹp các browser sessions cũ (quá 5 phút không hoạt động).

Sử dụng tree-kill để đảm bảo tất cả Chrome child processes được kill khi đóng browser.

17.2. CPU Management

Chrome cũng tiêu thụ nhiều CPU, đặc biệt khi render JavaScript-heavy pages. Để tránh spike CPU:

Staggered launch: Mỗi browser được khởi động cách nhau 3 giây.

Resource blocking: Block images, fonts, stylesheets không cần thiết để giảm rendering load.

Giới hạn đồng thời: CRON_TASK_LIMIT đảm bảo không có quá nhiều browsers chạy cùng lúc.

17.3. Disk Management

Mỗi Chrome instance tạo ra user data directory với cookies, cache và session data. Nếu không dọn dẹp, disk có thể đầy nhanh chóng.

Hệ thống dọn dẹp disk bằng cách:

Xóa thư mục tmp/user-data/ khi khởi động để dọn profiles từ lần chạy trước.

Dọn dẹp user data directory sau mỗi phiên.

Cleanup cron chạy lúc 00:30 hàng ngày để xóa task cũ và screenshots cũ.

Log files được tổ chức theo ngày, dễ dàng xóa log cũ khi cần.

17.4. Network Bandwidth

Mỗi phiên Chrome tải về nội dung của trang web. Với 25 instances đồng thời, băng thông tiêu thụ có thể đáng kể.

Hệ thống tối ưu bandwidth bằng cách:

Block images khi task không cần xem hình ảnh.

Block fonts và stylesheets không ảnh hưởng đến logic click.

Block tracking scripts và analytics.

Chỉ load những gì cần thiết cho việc tìm kiếm và click.

18. Tích Hợp Với Các Dịch Vụ Bên Ngoài

18.1. ZingProxy

ZingProxy là nhà cung cấp proxy chính của hệ thống. Tích hợp qua REST API:

ZING_PROXY_API_KEY: API key để xác thực.

ZING_PROXY_BASE_URL: Base URL của ZingProxy API.

Hệ thống gọi API để lấy proxy mới khi cần.

Proxy được trả về với đầy đủ thông tin: host, port, username, password, type.

18.2. Anti-Captcha

Anti-Captcha là dịch vụ giải CAPTCHA tự động:

ANTICAPTCHA_API_KEY: API key để xác thực.

ANTICAPTCHA_BASE_URL: URL API, mặc định https://api.anti-captcha.com.

ANTICAPTCHA_TIMEOUT: Timeout tối đa chờ giải CAPTCHA, mặc định 300 giây.

ANTICAPTCHA_RETRY_ATTEMPTS: Số lần retry khi giải thất bại, mặc định 3.

Dịch vụ này tính phí theo số lần giải. Cần theo dõi số dư tài khoản để tránh gián đoạn.

18.3. OpenAI

OpenAI được dùng cho hai mục đích:

Tạo nội dung báo cáo: Gọi GPT-4o-mini với prompt của từng nền tảng.

Giải CAPTCHA bằng Vision: Gọi GPT-4o-mini Vision API với screenshot CAPTCHA.

Cấu hình:

CHATGPT_API_KEY hoặc OPENAI_API_KEY: API key.

CHATGPT_MODEL hoặc OPENAI_MODEL: Model sử dụng, mặc định gpt-4o-mini.

18.4. DigitalOcean Spaces

DigitalOcean Spaces là dịch vụ object storage tương thích S3, dùng để lưu ảnh bằng chứng:

DIGITAL_OCEAN_BUCKET_NAME: Tên bucket.

DIGITAL_OCEAN_REGION: Region, mặc định sgp1 (Singapore).

DIGITAL_OCEAN_ACCESS_KEY_ID và DIGITAL_OCEAN_SECRET_ACCESS_KEY: Credentials.

DIGITAL_OCEAN_ENDPOINT: Endpoint URL.

DIGITAL_OCEAN_CDN_URL: CDN URL để serve ảnh nhanh hơn.

18.5. Cloudinary

Cloudinary là dịch vụ lưu trữ ảnh dự phòng:

CLOUDINARY_CLOUD_NAME, CLOUDINARY_API_KEY, CLOUDINARY_API_SECRET: Credentials.

CLOUDINARY_UPLOAD_PRESET: Upload preset cấu hình sẵn trên Cloudinary.

Cloudinary được dùng khi DigitalOcean Spaces không khả dụng.

18.6. Gmail SMTP

Gmail SMTP được dùng để gửi email báo cáo:

SMTP_HOST: smtp.gmail.com.

SMTP_PORT: 587.

SMTP_SECURE: false (dùng STARTTLS thay vì SSL).

SMTP_USER: Địa chỉ Gmail.

SMTP_PASS: App Password của Gmail (không phải mật khẩu thường).

Lưu ý: Phải bật 2-Step Verification trên tài khoản Gmail và tạo App Password riêng. Không thể dùng mật khẩu Gmail thông thường với SMTP.

19. Các Tình Huống Vận Hành Thực Tế

19.1. Tình Huống: Worker Không Nhận Task

Khi worker không nhận được task mới từ Go API, nguyên nhân có thể là:

Go API Backend không chạy hoặc không accessible từ worker.

API_HOST cấu hình sai.

API_KEY không khớp với cấu hình trên Go API.

Go API không có task mới để phân phối (chiến dịch đã hoàn thành hoặc chưa có chiến dịch nào).

Worker đã đạt giới hạn CRON_TASK_LIMIT và đang chờ task hiện tại hoàn thành.

Cách kiểm tra:

Xem GET / để kiểm tra task.totalProcessRunning và task.maxProcess.

Xem log: GET /logs?filePath=task/[ngày]/combined.log.

Kiểm tra kết nối Go API: curl $API_HOST/health.

19.2. Tình Huống: Tỷ Lệ Thành Công Thấp

Khi nhiều task thất bại, nguyên nhân phổ biến là:

Proxy bị block bởi Google hoặc CocCoc. Cần thay proxy pool.

Google thay đổi cấu trúc SERP, selector CSS không còn hoạt động. Cần cập nhật code.

CAPTCHA xuất hiện nhiều hơn bình thường. Kiểm tra số dư Anti-Captcha.

Domain mục tiêu không xuất hiện trong SERP cho từ khóa đã cấu hình.

Cách kiểm tra:

Xem log lỗi: GET /logs?filePath=app/[ngày]/error.log.

Xem browser crash log: GET /logs?filePath=browser_manager/[ngày]/crash.log.

Kiểm tra số dư Anti-Captcha trên dashboard của dịch vụ.

19.3. Tình Huống: Server Hết RAM

Khi server hết RAM, Chrome instances sẽ bị kill bởi OOM killer của Linux, gây ra nhiều task thất bại đột ngột.

Cách xử lý:

Giảm CRON_TASK_LIMIT và BROWSER_LIMIT_PER_PROCESS để chạy ít Chrome instances hơn.

Restart worker để dọn dẹp memory.

Xem xét nâng cấp RAM hoặc thêm server mới.

Cách phòng ngừa:

Cấu hình BROWSER_LIMIT_PER_PROCESS không vượt quá 70% RAM khả dụng chia cho 300MB.

Theo dõi memory usage qua monitoring tools.

19.4. Tình Huống: Báo Cáo Không Được Submit

Khi report tasks thất bại liên tục, nguyên nhân có thể là:

Nền tảng thay đổi cấu trúc form. Cần cập nhật adapter.

CAPTCHA không giải được. Kiểm tra Anti-Captcha API key và số dư.

AI tạo nội dung không đúng format. Cần cập nhật prompt trên Go API.

SMTP credentials sai hoặc Gmail App Password hết hạn.

Cách kiểm tra:

Xem report log: GET /logs?filePath=report/[ngày]/combined.log.

Kiểm tra screenshot bằng chứng trên Admin Dashboard để xem lỗi cụ thể.

20. Roadmap Và Hướng Phát Triển

20.1. Các Tính Năng Hiện Tại

Phiên bản 2.5.0 hiện tại hỗ trợ:

Bốn loại traffic flow: Ads, Search, Kill, Home Traffic.

Hơn 100 nền tảng báo cáo bảo mật.

Tự động giải CAPTCHA qua Anti-Captcha API và OpenAI Vision.

Mô phỏng hành vi người dùng với ghost-cursor và natural scroll.

Quản lý proxy đa nguồn.

Quản lý browser profile với session persistence.

Lưu trữ bằng chứng trên DigitalOcean Spaces và Cloudinary.

Crash recovery tự động.

Horizontal scaling không giới hạn.

20.2. Các Điểm Cần Cải Thiện

Một số điểm có thể cải thiện trong các phiên bản tương lai:

Cải thiện thuật toán phát hiện quảng cáo để thích nghi với các thay đổi của Google SERP.

Thêm hỗ trợ cho các search engine mới.

Cải thiện cơ chế phân bổ tài nguyên để tối ưu hóa throughput.

Thêm distributed tracing để dễ debug hơn trong môi trường nhiều worker.

Cải thiện cơ chế cache prompt để giảm latency khi tạo báo cáo.

Thêm metrics dashboard tích hợp để theo dõi hiệu suất theo thời gian thực.

20.3. Nguyên Tắc Khi Mở Rộng

Khi thêm tính năng mới vào Tools V2, cần tuân thủ các nguyên tắc:

Tính năng mới không được làm giảm độ ổn định của các tính năng hiện có.

Mọi tính năng mới phải có error handling và retry logic.

Mọi tính năng mới phải có logging đầy đủ để dễ debug.

Giới hạn đồng thời phải được cập nhật khi thêm loại task mới.

Tài liệu phải được cập nhật trước khi deploy lên production.

21. Phân Tích Rủi Ro Và Biện Pháp Giảm Thiểu

21.1. Rủi Ro: Proxy Bị Block Hàng Loạt

Đây là rủi ro thường gặp nhất. Google và Cloudflare liên tục cập nhật danh sách IP bị block. Khi một dải IP bị block, nhiều proxy trong pool có thể bị ảnh hưởng cùng lúc.

Biện pháp giảm thiểu:

Sử dụng proxy từ nhiều nhà cung cấp khác nhau để tránh phụ thuộc vào một nguồn.

Theo dõi tỷ lệ thành công của từng proxy và loại bỏ proxy có tỷ lệ thấp.

Rotate proxy thường xuyên, không dùng cùng một proxy quá nhiều lần trong ngày.

Sử dụng proxy từ các ISP dân dụng (residential proxy) thay vì datacenter proxy khi cần.

Có sẵn danh sách proxy dự phòng để chuyển sang khi proxy chính bị block.

21.2. Rủi Ro: Google Thay Đổi Cấu Trúc SERP

Google thường xuyên thử nghiệm các giao diện mới cho trang kết quả tìm kiếm. Khi cấu trúc HTML thay đổi, các selector CSS trong code có thể không còn hoạt động.

Biện pháp giảm thiểu:

Sử dụng nhiều selector CSS khác nhau cho cùng một element, không phụ thuộc vào một selector duy nhất.

Theo dõi tỷ lệ thành công của Ads Flow và Search Flow. Nếu giảm đột ngột, kiểm tra ngay.

Có cơ chế fallback khi không tìm thấy element mong đợi.

Cập nhật selectors kịp thời khi phát hiện thay đổi.

21.3. Rủi Ro: OpenAI API Gián Đoạn

OpenAI API đôi khi có downtime hoặc rate limiting. Khi đó, hệ thống không thể tạo nội dung báo cáo.

Biện pháp giảm thiểu:

Fallback prompts được lưu trong thư mục prompts/fallback/ để dùng khi API không khả dụng.

Cache cấu hình prompt 1 giờ để giảm số lần gọi API.

Retry với exponential backoff khi gặp rate limiting.

Theo dõi OpenAI API status page để biết trước về maintenance.

21.4. Rủi Ro: Server Crash Mất Task

Khi server crash đột ngột, các task đang chạy có thể bị mất nếu không có cơ chế recovery.

Biện pháp giảm thiểu:

Lưu trạng thái task vào MongoDB trước khi thực thi.

Khi khởi động lại, reset tất cả task PROCESSING về PENDING.

Retry limit đảm bảo task không bị retry vô hạn.

Go API có thể tạo lại task nếu worker không báo cáo kết quả trong thời gian quy định.

21.5. Rủi Ro: Chi Phí Dịch Vụ Tăng Đột Biến

Anti-Captcha API và OpenAI API tính phí theo usage. Nếu có bug gây ra vòng lặp vô hạn, chi phí có thể tăng đột biến.

Biện pháp giảm thiểu:

Đặt giới hạn ANTICAPTCHA_RETRY_ATTEMPTS để tránh retry vô hạn.

Theo dõi usage hàng ngày và đặt alert khi vượt ngưỡng.

Kiểm tra số dư tài khoản Anti-Captcha trước khi giải.

Sử dụng gpt-4o-mini thay vì các model đắt hơn.

22. So Sánh Với Các Phương Pháp Khác

22.1. Tại Sao Không Dùng HTTP Request Đơn Thuần

Cách đơn giản nhất để tạo traffic là gửi HTTP request trực tiếp đến URL mục tiêu. Tuy nhiên, cách này có nhiều hạn chế:

Google Analytics và các analytics platform phát hiện request không có JavaScript execution và không tính vào số liệu.

Không có session data, cookies hay JavaScript state — trông rõ ràng là bot.

Không thể thực hiện các hành vi phức tạp như tìm kiếm, click quảng cáo.

Dễ bị block bởi Cloudflare và các WAF khác.

Tools V2 dùng Chrome thực để tránh tất cả các vấn đề này. Chrome thực thi JavaScript, tạo session data, và hành vi của nó không thể phân biệt với người dùng thật nếu được cấu hình đúng.

22.2. Tại Sao Không Dùng Selenium

Selenium là công cụ automation browser phổ biến, nhưng có một số nhược điểm so với Puppeteer:

Selenium để lại nhiều dấu hiệu automation hơn trong browser.

Puppeteer với stealth plugin và rebrowser-puppeteer-core có khả năng bypass bot detection tốt hơn.

Bun + Puppeteer có hiệu năng tốt hơn Python + Selenium.

Ecosystem của Puppeteer phong phú hơn với các plugin như ghost-cursor.

22.3. Tại Sao Không Dùng Playwright

Playwright là công cụ mới hơn Puppeteer với nhiều tính năng tốt. Tuy nhiên:

Puppeteer có ecosystem plugin phong phú hơn, đặc biệt là puppeteer-extra và stealth plugin.

rebrowser-puppeteer-core là fork của Puppeteer được patch đặc biệt để tránh fingerprinting.

Codebase hiện tại đã được tối ưu cho Puppeteer, migration sang Playwright sẽ tốn nhiều công.

Playwright vẫn được cài đặt trong devDependencies để sử dụng cho testing.

23. Glossary — Thuật Ngữ

23.1. Thuật Ngữ Kỹ Thuật

Worker Engine: Tiến trình chạy trên máy chủ, nhận và thực thi tác vụ từ orchestrator.

Task Group: Một nhóm tác vụ liên quan được thực thi cùng nhau trong một phiên Chrome.

SERP: Search Engine Results Page — Trang kết quả tìm kiếm.

CTR: Click-Through Rate — Tỷ lệ click trên số lần hiển thị.

Bounce Rate: Tỷ lệ người dùng thoát trang ngay mà không tương tác.

Organic Traffic: Traffic từ kết quả tìm kiếm tự nhiên, không phải quảng cáo.

Direct Traffic: Traffic từ người dùng truy cập trực tiếp vào URL.

Fingerprinting: Kỹ thuật nhận dạng trình duyệt dựa trên các đặc điểm kỹ thuật.

Stealth Mode: Chế độ ẩn các dấu hiệu automation của trình duyệt.

Headless Browser: Trình duyệt chạy không có giao diện đồ họa.

Proxy Pool: Tập hợp các proxy được quản lý và luân chuyển.

Session Persistence: Lưu trữ session data để tái sử dụng giữa các lần.

Crash Recovery: Cơ chế phục hồi trạng thái sau khi hệ thống crash.

Horizontal Scaling: Tăng capacity bằng cách thêm máy chủ mới.

Vertical Scaling: Tăng capacity bằng cách nâng cấp phần cứng của máy chủ hiện có.

23.2. Thuật Ngữ Nghiệp Vụ

Ads Flow: Luồng click quảng cáo trả phí trên Google hoặc CocCoc.

Search Flow: Luồng tạo organic traffic qua tìm kiếm tự nhiên.

Kill Flow: Luồng tạo bounce rate cao cho domain đối thủ.

Home Traffic Flow: Luồng tạo direct traffic cho domain.

Report Task: Tác vụ gửi báo cáo bảo mật đến một nền tảng cụ thể.

Browser-Based Report: Báo cáo được submit qua form trên website.

Email-Based Report: Báo cáo được gửi qua email.

Proxy Webhook: URL được gọi để lấy proxy cho một task cụ thể.

Evidence Screenshot: Ảnh chụp màn hình bằng chứng sau khi hoàn thành task.

Fallback Prompt: Prompt dự phòng được dùng khi không lấy được cấu hình từ API.

23.3. Thuật Ngữ Cấu Hình

CRON_TASK_LIMIT: Số task traffic chạy đồng thời tối đa.

CRON_REPORT_LIMIT: Số report task chạy đồng thời tối đa.

BROWSER_LIMIT_PER_PROCESS: Tổng số Chrome instances tối đa.

TASK_RETRY_LIMIT: Số lần retry tối đa cho một task.

KILL_TRAFFIC_RATIO: Tỷ lệ kill traffic trong tổng số task.

HOME_TRAFFIC_RATIO: Tỷ lệ home traffic trong tổng số task.

HOME_TRAFFIC_PER_TARGET_LIMIT: Số home traffic task đồng thời cho cùng một URL.

SERVER_ID: Định danh duy nhất của worker instance.

API_HOST: URL của Go API Backend.

WEBHOOK_API_KEY: Token xác thực cho webhook từ Go API.

24. Câu Hỏi Thường Gặp

24.1. Tools V2 Có Thể Chạy Trên Windows Không?

Tools V2 được thiết kế và tối ưu cho Linux (Ubuntu 22.04 LTS). Về mặt kỹ thuật, Bun và Puppeteer đều hỗ trợ Windows, nhưng:

Một số Chromium dependencies chỉ có trên Linux.

Docker deployment chỉ hỗ trợ Linux containers.

Production deployment luôn trên Linux servers.

Để phát triển trên Windows, nên dùng WSL2 (Windows Subsystem for Linux).

24.2. Tại Sao Cần MongoDB Riêng Cho Tools V2?

Go API Backend dùng MySQL để lưu dữ liệu chính. Tools V2 cần MongoDB riêng vì:

Cần lưu trạng thái task để crash recovery mà không phụ thuộc vào Go API.

MongoDB phù hợp hơn cho dữ liệu có cấu trúc linh hoạt như task groups.

Giảm tải cho Go API — worker không cần gọi API để lưu trạng thái nội bộ.

Hoạt động độc lập khi Go API tạm thời không khả dụng.

24.3. Làm Thế Nào Để Thêm Nền Tảng Báo Cáo Mới?

Để thêm một nền tảng báo cáo mới:

Thêm giá trị mới vào enum ReportPlatform trong report-task.model.ts.

Tạo adapter mới trong src/services/report-tasks/browser-based/ hoặc email-based/.

Tạo fallback prompt trong prompts/fallback/.

Thêm cấu hình prompt trên Go API Backend.

Test với script scripts/test-single-platform.ts.

24.4. Làm Thế Nào Để Scale Khi Cần Nhiều Traffic Hơn?

Có hai cách để tăng capacity:

Vertical scaling: Tăng CRON_TASK_LIMIT và BROWSER_LIMIT_PER_PROCESS trên server hiện có. Cần đảm bảo server có đủ RAM và CPU.

Horizontal scaling: Deploy thêm instance Tools V2 trên server mới. Mỗi instance tự đăng ký với Go API và nhận task tự động.

Horizontal scaling được khuyến nghị vì nó không có single point of failure.

24.5. Tại Sao Dùng Bun Thay Vì Node.js?

Bun được chọn vì:

Khởi động nhanh hơn Node.js 3-5 lần, quan trọng khi server restart thường xuyên.

Chạy TypeScript native không cần biên dịch, giảm thời gian development.

Hiệu năng I/O cao hơn, quan trọng khi xử lý nhiều concurrent tasks.

Tích hợp sẵn nhiều tính năng (SQLite, WebSocket, test runner) không cần thêm dependencies.

Tương thích với hầu hết npm packages, không cần thay đổi nhiều code.

24.6. Làm Thế Nào Để Debug Khi Task Thất Bại?

Quy trình debug khi task thất bại:

Xem log lỗi qua endpoint /logs?filePath=app/[ngày]/error.log.

Tìm task ID trong log để trace toàn bộ quá trình thực thi.

Xem browser crash log nếu Chrome bị crash.

Kiểm tra screenshot bằng chứng trên Admin Dashboard để xem trạng thái trang tại thời điểm lỗi.

Chạy task thủ công với script test để reproduce lỗi.

Bật DEBUG=true để xem log chi tiết hơn.

Tổng quan

Thiết Kế Tổng Quan — Tools V2 Worker Engine#

1. Giới Thiệu#

2. Vị Trí Trong Hệ Thống#

2.1. Ba Thành Phần Chính#

2.2. Mô Hình Phân Tán#

2.3. Luồng Hoạt Động Tổng Quát#

3. Nghiệp Vụ Thứ Nhất — Tạo Traffic Trình Duyệt#

3.1. Mục Tiêu Nghiệp Vụ#

3.2. Tại Sao Cần Mô Phỏng Trình Duyệt Thực#

3.3. Bốn Loại Traffic Flow#

3.4. Cách Hệ Thống Tránh Bị Phát Hiện#

3.5. Quản Lý Đồng Thời#

3.6. Xử Lý Lỗi Và Retry#

4. Nghiệp Vụ Thứ Hai — Báo Cáo Bảo Mật Tự Động#

4.1. Mục Tiêu Nghiệp Vụ#

4.2. Hai Phương Thức Báo Cáo#

4.3. Vai Trò Của AI Trong Báo Cáo#

4.4. Xử Lý CAPTCHA Trong Báo Cáo#

4.5. Bằng Chứng Báo Cáo#

5. Quản Lý Proxy#

5.1. Tại Sao Proxy Quan Trọng#

5.2. Nguồn Proxy#

5.3. Cơ Chế Cấp Phát Proxy#

5.4. Các Loại Proxy Được Hỗ Trợ#

6. Quản Lý Browser Profile#

6.1. Profile Là Gì#

6.2. Tại Sao Profile Quan Trọng#

6.3. Vòng Đời Profile#

7. Lưu Trữ Bằng Chứng#

7.1. Mục Đích#

7.2. Chiến Lược Lưu Trữ#

7.3. Quy Trình Upload#

8. Tính Tự Phục Hồi#

8.1. Crash Recovery#

8.2. Stuck Task Recovery#

8.3. Retry Limit#

9. Tích Hợp Với Go API Backend#

9.1. Cách Tools V2 Nhận Tác Vụ#

9.2. Cách Tools V2 Gửi Kết Quả#

9.3. Cách Tools V2 Nhận Tác Vụ Báo Cáo#

9.4. Xác Thực Giao Tiếp#

10. Giám Sát Trạng Thái#

10.1. Endpoint Giám Sát#

10.2. Thông Tin Trạng Thái#

10.3. Đọc Log Từ Xa#

11. Các Giới Hạn Vận Hành#

11.1. Giới Hạn Đồng Thời#

11.2. Tại Sao Cần Giới Hạn#

11.3. Staggered Launch#

12. Tóm Tắt Điểm Mạnh Và Giới Hạn#

12.1. Điểm Mạnh#

12.2. Giới Hạn Cần Lưu Ý#

13. Chi Tiết Các Loại Traffic Flow#

13.1. Ads Flow — Phân Tích Chi Tiết#

13.2. Search Flow — Phân Tích Chi Tiết#

13.3. Kill Flow — Phân Tích Chi Tiết#

13.4. Home Traffic Flow — Phân Tích Chi Tiết#

14. Chi Tiết Hệ Thống Báo Cáo#

14.1. Quy Trình Tạo Báo Cáo Đầy Đủ#

14.2. Xử Lý Thất Bại Trong Báo Cáo#

14.3. Danh Sách Đầy Đủ Nền Tảng Browser-Based#

14.4. Danh Sách Đầy Đủ Nền Tảng Email-Based#

15. Nguyên Tắc Thiết Kế#

15.1. Tự Động Hoàn Toàn#

15.2. Độc Lập Và Phân Tán#

15.3. Ưu Tiên Độ Tin Cậy#

15.4. Quan Sát Được#

16. Hành Vi Mô Phỏng Người Dùng — Chi Tiết Kỹ Thuật#

16.1. Tại Sao Hành Vi Tự Nhiên Quan Trọng#

16.2. Ghost Cursor — Di Chuyển Chuột Tự Nhiên#

16.3. Scroll Behavior — Đọc Nội Dung Tự Nhiên#

16.4. Typing Simulation — Gõ Phím Tự Nhiên#

16.5. Reading Time Calculation — Thời Gian Đọc Thực Tế#

17. Quản Lý Tài Nguyên Hệ Thống#

17.1. Memory Management#

17.2. CPU Management#

17.3. Disk Management#

17.4. Network Bandwidth#

18. Tích Hợp Với Các Dịch Vụ Bên Ngoài#

Thiết Kế Tổng Quan — Tools V2 Worker Engine

1. Giới Thiệu

2. Vị Trí Trong Hệ Thống

2.1. Ba Thành Phần Chính

2.2. Mô Hình Phân Tán

2.3. Luồng Hoạt Động Tổng Quát

3. Nghiệp Vụ Thứ Nhất — Tạo Traffic Trình Duyệt

3.1. Mục Tiêu Nghiệp Vụ

3.2. Tại Sao Cần Mô Phỏng Trình Duyệt Thực

3.3. Bốn Loại Traffic Flow

3.4. Cách Hệ Thống Tránh Bị Phát Hiện

3.5. Quản Lý Đồng Thời

3.6. Xử Lý Lỗi Và Retry

4. Nghiệp Vụ Thứ Hai — Báo Cáo Bảo Mật Tự Động

4.1. Mục Tiêu Nghiệp Vụ

4.2. Hai Phương Thức Báo Cáo

4.3. Vai Trò Của AI Trong Báo Cáo

4.4. Xử Lý CAPTCHA Trong Báo Cáo

4.5. Bằng Chứng Báo Cáo

5. Quản Lý Proxy

5.1. Tại Sao Proxy Quan Trọng

5.2. Nguồn Proxy

5.3. Cơ Chế Cấp Phát Proxy

5.4. Các Loại Proxy Được Hỗ Trợ

6. Quản Lý Browser Profile

6.1. Profile Là Gì

6.2. Tại Sao Profile Quan Trọng

6.3. Vòng Đời Profile

7. Lưu Trữ Bằng Chứng

7.1. Mục Đích

7.2. Chiến Lược Lưu Trữ

7.3. Quy Trình Upload

8. Tính Tự Phục Hồi

8.1. Crash Recovery

8.2. Stuck Task Recovery

8.3. Retry Limit

9. Tích Hợp Với Go API Backend

9.1. Cách Tools V2 Nhận Tác Vụ

9.2. Cách Tools V2 Gửi Kết Quả

9.3. Cách Tools V2 Nhận Tác Vụ Báo Cáo

9.4. Xác Thực Giao Tiếp

10. Giám Sát Trạng Thái

10.1. Endpoint Giám Sát

10.2. Thông Tin Trạng Thái

10.3. Đọc Log Từ Xa

11. Các Giới Hạn Vận Hành

11.1. Giới Hạn Đồng Thời

11.2. Tại Sao Cần Giới Hạn

11.3. Staggered Launch

12. Tóm Tắt Điểm Mạnh Và Giới Hạn

12.1. Điểm Mạnh

12.2. Giới Hạn Cần Lưu Ý

13. Chi Tiết Các Loại Traffic Flow

13.1. Ads Flow — Phân Tích Chi Tiết

13.2. Search Flow — Phân Tích Chi Tiết

13.3. Kill Flow — Phân Tích Chi Tiết

13.4. Home Traffic Flow — Phân Tích Chi Tiết

14. Chi Tiết Hệ Thống Báo Cáo

14.1. Quy Trình Tạo Báo Cáo Đầy Đủ

14.2. Xử Lý Thất Bại Trong Báo Cáo

14.3. Danh Sách Đầy Đủ Nền Tảng Browser-Based

14.4. Danh Sách Đầy Đủ Nền Tảng Email-Based

15. Nguyên Tắc Thiết Kế

15.1. Tự Động Hoàn Toàn

15.2. Độc Lập Và Phân Tán

15.3. Ưu Tiên Độ Tin Cậy

15.4. Quan Sát Được

16. Hành Vi Mô Phỏng Người Dùng — Chi Tiết Kỹ Thuật

16.1. Tại Sao Hành Vi Tự Nhiên Quan Trọng

16.2. Ghost Cursor — Di Chuyển Chuột Tự Nhiên

16.3. Scroll Behavior — Đọc Nội Dung Tự Nhiên

16.4. Typing Simulation — Gõ Phím Tự Nhiên

16.5. Reading Time Calculation — Thời Gian Đọc Thực Tế

17. Quản Lý Tài Nguyên Hệ Thống

17.1. Memory Management

17.2. CPU Management

17.3. Disk Management

17.4. Network Bandwidth

18. Tích Hợp Với Các Dịch Vụ Bên Ngoài

18.1. ZingProxy