Cách theo dõi tỷ lệ thành công của Turnstile Solver trong Python

Tóm tắt nhanh

• Giám sát kết quả giải Turnstile, việc xác thực token và việc hoàn tất thao tác trong ứng dụng như các kết quả riêng biệt.
• Mã taskId của CapSolver xác nhận việc tạo task; phản hồi ready kèm token đúng như mong đợi xác nhận kết quả từ solver.
• Phân tích widget của Cloudflare và log của solver đếm các sự kiện khác nhau, nên không được so sánh phần trăm nếu chưa thống nhất định nghĩa.
• Đo riêng thời gian đến khi có kết quả từ solver và thời gian đến khi ứng dụng có kết quả cuối cùng, bao gồm cả lỗi và các lần thử chưa có kết luận.
• Chỉ sử dụng bằng chứng từ Siteverify khi bạn vận hành ứng dụng được bảo vệ hoặc có quyền truy cập hợp lệ vào log xác thực của nó.
• Dùng một bản ghi cho mỗi lần thử trong phần tổng hợp bằng Python, và chỉ tính một lần cho mỗi quy trình (workflow) khi báo cáo tỉ lệ hoàn tất ứng dụng, kể cả khi có retry.

Một tác vụ trình duyệt chạy theo lịch nhận được token Turnstile, nhưng trang không bao giờ tới được màn hình xác nhận như mong đợi. Bảng điều khiển của solver thì trông vẫn “xanh”, trong khi đội vận hành vẫn thấy job thất bại. Họ nên tin con số nào?

Cả hai quan sát đều có thể đúng. Solver đã trả về một kết quả; ứng dụng thì chưa xác nhận đã hoàn tất. Các chỉ số hữu ích cho Cloudflare Turnstile solver cho thấy nơi hai kết quả đó tách nhau. CapSolver cung cấp phản hồi của tác vụ giải, trong khi workflow trình duyệt của bạn và, nếu có, backend của ứng dụng được bảo vệ cung cấp phần bằng chứng còn lại. Hướng dẫn này giải thích cần ghi lại những gì cho một tích hợp đã có và đã được cấp quyền, và cách tóm tắt một bản xuất log đã được ẩn thông tin bằng Python. Tài liệu tập trung vào việc giám sát thực tế cho các nhóm QA và các dịch vụ tự động hoá doanh nghiệp, với giả định là không có quyền truy cập vào phân tích riêng tư của website bên thứ ba.

Xác định những gì bảng điều khiển Turnstile của bạn thực sự quan sát được

Phạm vi giám sát phụ thuộc vào việc bạn kiểm soát website được bảo vệ, client tự động, hay cả hai.

Chủ sở hữu ứng dụng có thể kiểm tra hoạt động widget, việc xác thực ở phía server và thao tác cuối cùng của ứng dụng. Một dịch vụ tự động hoá làm việc trên một hành trình client đã được chấp thuận có thể chỉ thấy phản hồi của solver và kết quả trong trình duyệt. Hãy thống nhất với khách hàng xem bằng chứng backend nào có sẵn trước khi gắn nhãn một kết quả là “đã xác thực”.

Phân tích kết quả challenge của Cloudflare mô tả các challenge được phát hành và được giải, bao gồm cả kết quả tương tác và không tương tác. Đó là các quan sát ở mức widget. Chúng không phải là báo cáo trực tiếp về số task mà solver CAPTCHA bên ngoài của bạn đã chấp nhận hoặc hoàn thành.

Giữ Turnstile widget tách biệt với full-page Cloudflare challenge trong báo cáo. Nếu đội ngũ chưa chắc chắn đã gặp checkpoint nào, hãy dùng hướng dẫn nhận diện Turnstile và Cloudflare challenge trước khi gom nhóm các lần thử. Gộp chung các loại challenge khác nhau sẽ khiến thay đổi về khối lượng công việc trông giống như thay đổi về chất lượng solver.

Ghi lại yêu cầu gửi tới solver và kết quả cuối cùng của nó

Chỉ số kết quả solver nên đếm các task trả về lời giải như mong đợi, sử dụng một tập các lần thử đã gửi được định nghĩa rõ ràng.

Tài liệu chính thức về API CapSolver Turnstile mô tả AntiTurnstileTaskProxyLess, với websiteURL và websiteKey là các đầu vào bắt buộc. Metadata tuỳ chọn bao gồm các giá trị action và cdata của widget. Hãy ghi lại một định danh an toàn cho cấu hình đã dùng, để có thể so sánh việc thay đổi input với các lỗi sau này.

CapSolver dùng createTask để gửi task và getTaskResult để lấy kết quả cuối cùng. Kết quả Turnstile đã được tài liệu hoá bao gồm status: ready và solution.token. Một mình taskId chưa phải là lời giải hoàn thành. Tài liệu tham chiếu lấy kết quả giải thích cách xử lý phản hồi mà tích hợp hiện tại của bạn lẽ ra đã thực hiện.

Để giám sát, hãy giữ riêng ID workflow và ID task của solver. Một thao tác trình duyệt được chấp thuận có thể tạo ra nhiều hơn một lần thử giải. Đếm riêng các lần thử đó cho chỉ số solver, nhưng chỉ đếm workflow gốc một lần khi báo cáo tỉ lệ hoàn tất workflow.

Giữ các lỗi và task chưa hoàn thành luôn hiển thị

Chọn một thời hạn quan sát cho mỗi “cohort” lần thử và báo cáo cùng nhau các task thành công, thất bại và chưa có kết luận. Một cohort nghĩa là cùng một nhóm yêu cầu đã chọn, ví dụ các task gửi đi trong một giờ nhất định cho một workflow đã được chấp thuận.

Để có tỉ lệ kết quả mang tính bảo thủ, chia số kết quả solver thành công cho tất cả các lần thử đã gửi trong cohort đó. Đồng thời hiển thị số task chưa có kết luận; tỉ lệ kết quả đo trong khi còn nhiều task đang chạy mới chỉ là tạm thời. Nếu bạn tính riêng tỉ lệ trên số task đã hoàn tất, hãy ghi rõ mẫu số hẹp hơn đó.

Nhóm các lỗi khi tạo task và khi lấy kết quả theo các mã lỗi đã được CapSolver tài liệu hoá. Một cấu hình bị từ chối và một lần giải thất bại cần các cuộc điều tra khác nhau. Cả hai đều có thể ảnh hưởng đến dịch vụ mà khách hàng của bạn trải nghiệm, nhưng chúng nên được giữ các nguyên nhân riêng biệt.

Tách riêng việc xác thực token khỏi việc hoàn tất trong trình duyệt

Xác thực token đo xem backend của ứng dụng được bảo vệ có chấp nhận token Turnstile qua Siteverify hay không.

Chỉ số xác thực token của Cloudflare đếm các request Siteverify và phản hồi với success: true hoặc success: false. Khi các bản ghi đó có sẵn, hãy báo cáo số phản hồi hợp lệ chia cho tất cả phản hồi Siteverify trong cohort được chọn. Giữ các lỗi mạng không có phản hồi ở một nhóm riêng, có thể nhìn thấy được.

Thuật ngữ token giải thích vai trò chung của token. Trong workflow này, việc nhận được token là một sự kiện trung gian. Ứng dụng vẫn phải xác thực token và hoàn tất thao tác của riêng nó.

Khi dịch vụ của bạn không kiểm soát website

Hãy dùng một kết quả ứng dụng có thể quan sát được, chẳng hạn như trang xác nhận mong đợi hoặc bản ghi được phép mà bạn yêu cầu. Gắn nhãn đây là “workflow đã hoàn tất”, cùng với luận cứ xác nhận việc hoàn tất đó.

Đừng suy diễn phản hồi Siteverify chỉ từ widget “xanh”, mã trạng thái HTTP thành công, hoặc việc challenge biến mất. Nếu khách hàng không cung cấp bằng chứng xác thực, hãy báo cáo token validation là không có sẵn. Việc chỉ rõ một quan sát bị thiếu hữu ích hơn là trình bày một tỉ lệ ước lượng như thể là một số đo thực.

Khi báo cáo cho khách hàng, hãy giữ nguyên lý do lỗi ban đầu nếu kết quả cuối cùng vẫn chưa rõ. “Solver đã trả về token; không quan sát được xác nhận trước thời hạn” cho kỹ sư tiếp theo biết nên bắt đầu từ đâu.

Nhập mã khuyến mãi CapSolver của bạn

Tăng ngân sách tự động hoá của bạn ngay lập tức!
Dùng mã CAP26 khi nạp tiền vào tài khoản CapSolver để nhận thêm 5% tiền thưởng trên mỗi lần nạp — không giới hạn.
Nhập mã ngay trong Bảng điều khiển CapSolver

Đo độ trễ tại đúng bước xảy ra chậm trễ

Giám sát độ trễ cần phân biệt thời gian chờ solver, độ trễ khi bàn giao token và tổng thời gian workflow.

Bắt đầu bộ đếm solver khi client gửi yêu cầu task, và dừng khi client nhận được kết quả mong đợi hoặc lỗi cuối cùng. Điều này đo thời gian trôi qua mà client quan sát được, bao gồm độ trễ mạng và việc polling. Nó không tách riêng thời gian xử lý nội bộ của nhà cung cấp.

Theo dõi riêng khoảng thời gian từ lúc nhận token đến khi gửi request của ứng dụng. Một job trình duyệt phải chờ trong hàng đợi sau khi giải xong có thể tạo ra vấn đề token ngay cả khi solver phản hồi rất nhanh.

Tài liệu tham chiếu xác thực phía server của Cloudflare nêu rằng token Turnstile hết hạn sau 300 giây và chỉ dùng được một lần. Tài liệu đó cũng giải thích các lỗi xác thực và các trường phản hồi cần kiểm tra, bao gồm hostname và action mong đợi. Dấu thời gian bạn nhận token hữu ích cho việc chẩn đoán độ trễ khi bàn giao; nó không phải là bằng chứng chính xác về thời gian sống còn lại của token.

Hiển thị median và một phân vị đuôi chậm hơn, chẳng hạn p95, cho các lần thử hoàn tất có thể so sánh được. Thêm cả số lượng mẫu và số lượng timeout bên cạnh. Một biểu đồ độ trễ chỉ tính các lần thành công có thể trông nhanh hơn khi các request chậm nhất đều đã timeout và biến mất khỏi phép tính.

Giữ cho các thử nghiệm nội bộ, cloud worker, các họ trang khác nhau và các phiên bản tích hợp khác nhau có thể phân biệt được. So sánh cùng một workflow trước và sau một lần triển khai trước khi đổ lỗi cho thay đổi từ nhà cung cấp toàn cầu.

Dùng một dashboard nhỏ với mẫu số (denominator) rõ ràng

Một dashboard ban đầu hữu ích sẽ kết nối mỗi chỉ số với một sự kiện bạn có thể kiểm chứng.

Đây là các định nghĩa ở cấp ứng dụng được đề xuất, không phải tuyên bố rằng mọi trường đều được cung cấp trong phản hồi API của CapSolver. Chỉ tính những gì log và bản ghi thanh toán của bạn hỗ trợ. Khi mẫu số cho chỉ số “chi phí trên mỗi thao tác hoàn tất” bằng 0, hãy hiển thị là không có dữ liệu thay vì cố ép thành một con số gây hiểu nhầm.

Tính tỉ lệ thành công Turnstile bằng Python

Python có thể tóm tắt một bản xuất đã được ẩn thông tin từ tích hợp solver hiện tại của bạn mà không cần gửi thêm yêu cầu giải nào.

Ví dụ này chỉ dùng thư viện chuẩn của Python 3; không cần cài gói hoặc thông tin xác thực API. Nó đo lường các bản ghi bạn cung cấp. Nó không thu thập task trực tiếp, không xác thực token và không tự đo hiệu năng của nhà cung cấp.

Chuẩn bị một dòng cho mỗi lần thử giải

Xuất một snapshot tại thời điểm hết hạn quan sát đã xác định. Dùng một attempt_id nội bộ ngay cả khi việc tạo task thất bại trước khi API trả về task ID. Bao gồm mọi lần thử trong cohort workflow bạn đã chọn, kể cả tạo task thất bại và các task vẫn đang chờ tại thời điểm snapshot. Đừng xuất mỗi lần poll thành một lần thử riêng.

Các trường CSV dưới đây là một schema báo cáo ở cấp ứng dụng, không phải tham số API của CapSolver:

• solver_result: dùng ready chỉ sau khi tích hợp của bạn nhận được kết quả ready thành công kèm token mong đợi; dùng failed cho lỗi cuối cùng và pending cho công việc chưa có kết luận tại thời điểm snapshot.
• validation: dùng passed hoặc failed chỉ cho phản hồi xác thực backend đã quan sát được. Dùng unknown khi không có bằng chứng, xác thực chưa chạy, hoặc chưa có phản hồi. Giữ chi tiết lỗi truyền tải trong log chẩn đoán riêng.
• workflow_completed: dùng yes chỉ khi kết quả ứng dụng mong đợi đã được xác nhận. Dùng cùng workflow_id giữa các lần retry.

Lưu tập dữ liệu minh hoạ này thành attempts.csv. Năm bản ghi này là ví dụ tự nghĩ ra, không phải quan sát thực tế hay kết quả benchmark:

attempt_id,workflow_id,solver_result,validation,workflow_completed
a1,w1,ready,passed,yes
a2,w2,failed,unknown,no
a3,w2,ready,passed,yes
a4,w3,ready,failed,no
a5,w4,pending,unknown,no

Chạy phần tổng hợp

Lưu đoạn script sau thành summarize_turnstile.py. Kiểm tra trùng ID giúp ngăn bản xuất chứa các dòng poll lặp lại âm thầm làm tăng số đếm.

import csv
import json
import sys
from collections import Counter


def summarize(path):
    with open(path, newline='', encoding='utf-8') as handle:
        rows = list(csv.DictReader(handle))
    seen = set()
    completed = set()
    workflows = set()
    solver = Counter()
    validation = Counter()
    for row in rows:
        attempt = row['attempt_id'].strip()
        workflow = row['workflow_id'].strip()
        if not attempt or attempt in seen or not workflow:
            raise ValueError('Use unique, nonempty attempt IDs and nonempty workflow IDs')
        if row['solver_result'] not in {'ready', 'failed', 'pending'}:
            raise ValueError('Invalid solver_result')
        if row['validation'] not in {'passed', 'failed', 'unknown'}:
            raise ValueError('Invalid validation')
        if row['workflow_completed'] not in {'yes', 'no'}:
            raise ValueError('Invalid workflow_completed')
        seen.add(attempt)
        workflows.add(workflow)
        solver[row['solver_result']] += 1
        validation[row['validation']] += 1
        if row['workflow_completed'] == 'yes':
            completed.add(workflow)

    def percent(numerator, denominator):
        return round(100 * numerator / denominator, 2) if denominator else None

    observed_validation = validation['passed'] + validation['failed']
    return {
        'attempts': len(rows),
        'solver_ready': solver['ready'],
        'solver_failed': solver['failed'],
        'solver_pending': solver['pending'],
        'solver_result_rate_pct': percent(solver['ready'], len(rows)),
        'validation_observed': observed_validation,
        'validation_unknown': validation['unknown'],
        'validation_pass_rate_pct': percent(validation['passed'], observed_validation),
        'workflows': len(workflows),
        'workflows_completed': len(completed),
        'workflow_completion_rate_pct': percent(len(completed), len(workflows)),
    }


if __name__ == '__main__':
    print(json.dumps(summarize(sys.argv[1]), indent=2))

Chạy script từ thư mục chứa cả hai file:

python3 summarize_turnstile.py attempts.csv

Kết quả mẫu:

{
  "attempts": 5,
  "solver_ready": 3,
  "solver_failed": 1,
  "solver_pending": 1,
  "solver_result_rate_pct": 60.0,
  "validation_observed": 3,
  "validation_unknown": 2,
  "validation_pass_rate_pct": 66.67,
  "workflows": 4,
  "workflows_completed": 2,
  "workflow_completion_rate_pct": 50.0
}

Ba trong số năm lần thử đã tạo ra kết quả từ solver, nên tỷ lệ có kết quả solver của mẫu là 60%. Hai trong ba lần xác thực được quan sát đã vượt qua, cho tỷ lệ 66,67%. Hai trong bốn quy trình công việc (workflow) duy nhất đã hoàn tất, cho tỷ lệ 50%. Lần thử thất bại và lần thử lại thành công cho w2 được tính là hai lần thử nhưng chỉ là một workflow đã hoàn tất.

Số lượng đang chờ xử lý khiến kết quả 60% chỉ là tạm thời. Hãy dựng lại snapshot sau khi công việc còn dang dở kết thúc; không thêm một hàng khác với cùng ID lần thử. Nếu không có hàng nào hoặc không có lần xác thực nào được quan sát, tỷ lệ tương ứng là null chứ không phải một giá trị 0 giả tạo.

Đối với báo cáo theo khoảng thời gian, hãy chọn các workflow trước rồi bao gồm các lần thử liên quan của chúng cho đến thời hạn quan sát. Lọc tuỳ tiện theo từng hàng lần thử có thể bỏ sót một lần thành công trước đó hoặc một lần thử lại sau đó và làm thay đổi mẫu số workflow. Giữ một số đếm riêng cho các workflow đủ điều kiện nhưng không bao giờ đạt đến bước gửi cho solver; đoạn script nhỏ này không thể đếm các thao tác bị thiếu trong đầu vào của nó.

Việc tính toán cục bộ trong ví dụ có thể được tái tạo mà không cần thông tin xác thực. Để giám sát dịch vụ của bạn, hãy thay thế mẫu bằng các bản ghi đã được ẩn thông tin nhạy cảm từ tích hợp thực tế của bạn và ghi rõ tập người dùng (cohort) cũng như thời hạn quan sát của bản xuất dữ liệu. Tránh đưa vào khóa API, token thô, cookie, hoặc nội dung biểu mẫu cá nhân.

Chuyển thay đổi chỉ số thành một cuộc điều tra cụ thể

Hãy điều tra giai đoạn đầu tiên mà kết quả đã thay đổi, sử dụng cùng một cohort workflow xuyên suốt.

Nếu lỗi tạo task tăng, hãy kiểm tra cấu hình và thông tin xác thực trước khi tăng số lần retry. Nếu kết quả solver vẫn ổn định nhưng lỗi xác thực tăng, hãy xem lại các nhóm lỗi xác thực và thời điểm bàn giao token. Nếu xác thực vẫn ổn định nhưng tỉ lệ hoàn tất ứng dụng giảm, hãy kiểm tra bước kiểm tra cuối (final assertion), phản hồi biểu mẫu, hoặc dữ liệu đầu ra được phép.

Ví dụ, một nhà cung cấp QA có thể nhận thấy bản phát hành của khách hàng thêm một thao tác nền giữa thời điểm nhận token và gửi biểu mẫu. So sánh hữu ích là độ trễ bàn giao và kết quả xác thực của riêng khách hàng đó trước và sau bản phát hành. Một phần trăm thành công tổng hợp trên tất cả khách hàng có thể che khuất hành trình đang bị ảnh hưởng.

Hãy xem những tình huống như vậy là các hướng điều tra, không phải bằng chứng về nguyên nhân. Kiểm tra một số nhỏ các lỗi đã được ủy quyền kèm dấu thời gian trước khi thay đổi tích hợp. Giữ số lần retry trong giới hạn và bảo tồn lần thử ban đầu để các lần retry không làm tăng giả tỉ lệ hoàn tất.

Cloudflare cung cấp sitekey và secret key dùng để thử nghiệm nhằm kiểm tra triển khai trong môi trường kiểm soát. Hãy dùng chúng để kiểm tra các nhánh pass và fail của ứng dụng của riêng bạn. Đừng đưa các bài thử với token giả vào báo cáo hiệu suất solver thực tế: chúng kiểm tra hành vi ứng dụng, không phải chất lượng giải trong môi trường production.

Tránh lưu trữ token lời giải thô, khóa API, cookie, hoặc nội dung trang không cần thiết trong log giám sát. Thông thường, định danh workflow, định danh task, dấu thời gian, nhóm kết quả, và nhãn cấu hình an toàn sẽ là điểm xuất phát tốt hơn.

Bắt đầu từ kết quả mà khách hàng của bạn cần

Hãy bắt đầu theo dõi Turnstile với ba câu hỏi riêng biệt: solver có trả về kết quả không, ứng dụng có xác thực token ở nơi có bằng chứng đó không, và thao tác đã được phê duyệt có hoàn tất không?

Chỉ thêm độ trễ và chi phí sau khi các kết quả đó đã có định nghĩa ổn định. Một tích hợp CapSolver đang tồn tại có thể cung cấp các sự kiện solver-task; ứng dụng của bạn cung cấp bằng chứng hoàn tất. Giữ cho ranh giới này rõ ràng giúp việc khắc phục sự cố và báo cáo cho khách hàng dễ dàng hơn mà không cần xây dựng một hệ thống giám sát quá cỡ.

FAQ

H: Tôi nên theo dõi trước những chỉ số Cloudflare Turnstile solver nào?

Hãy theo dõi tỷ lệ có kết quả solver, mức độ hoàn tất workflow, và thời gian đến khi có kết quả mà khách hàng quan sát được. Thêm kết quả xác thực Siteverify khi bạn vận hành backend được bảo vệ hoặc có quyền truy cập hợp lệ vào log của nó. Luôn hiển thị cả những lần thất bại và các lần thử chưa có kết quả.

H: Một task CapSolver ở trạng thái sẵn sàng có nghĩa là website đã chấp nhận token không?

Không. Một task sẵn sàng với token như mong đợi chỉ xác nhận rằng solver đã cho kết quả. Việc xác thực trên website và thao tác ứng dụng cuối cùng là các bước tiếp theo cần có bằng chứng riêng.

H: Tôi có thể đo lường tỷ lệ thành công khi xác thực token trên một website mà tôi không vận hành không?

Chỉ khi chủ sở hữu cung cấp bằng chứng xác thực được ủy quyền. Nếu không, hãy báo cáo kết quả trình duyệt mà bạn có thể quan sát và đánh dấu xác thực backend là không khả dụng.

H: Tại sao xác thực Turnstile có thể thất bại sau khi solver phản hồi rất nhanh?

Việc dùng lại token, gửi trễ, hoặc vấn đề triển khai vẫn có thể ảnh hưởng đến xác thực. Hãy kiểm tra lỗi thực tế và thời điểm trong ứng dụng; việc chuyển token nhanh không chứng minh rằng mọi bước sau đó đều đúng.

H: Các tỉ lệ thành công trong ví dụ có phải là cam kết về hiệu năng không?

Không. Các con số ví dụ minh họa các mẫu số khác nhau. Hãy đo lường các workflow đã được ủy quyền của riêng bạn trong những điều kiện tương đương, và giữ lưu lượng dùng test-key tách biệt khỏi các quan sát trong môi trường production.