Cách giảm hiệu quả tình trạng khóa tài khoản cho dịch vụ relay AI

Wokey Team · 2026-06-27

Các nhà cung cấp mô hình vừa tiến hành một đợt khóa tài khoản quy mô lớn — rộng đến mức ngay cả người dùng cá nhân sử dụng hợp lệ cũng bị vạ lây.

Nếu bạn đang vận hành một dịch vụ relay, hoặc đang chọn một dịch vụ như vậy, điều này đáng để suy nghĩ nghiêm túc: bị khóa tài khoản là chuyện may rủi, hay là chuyện kiến trúc?

Câu trả lời của tôi là vế sau. Tỷ lệ bị khóa không phải ngẫu nhiên — nó do kiến trúc quyết định.

Hãy nhìn bao quát hơn. Khi nhà cung cấp xác định một tài khoản có đang bị chia sẻ hay bán lại hay không, họ thường xem các tín hiệu sau:

• Thay đổi IP và loại IP — yêu cầu của bạn đột nhiên nhảy từ IP dân cư sang IP trung tâm dữ liệu, hoặc nhảy qua các vị trí địa lý khác nhau.
• Hành vi bất thường — tần suất gọi, mức đồng thời và phân bố thời gian rõ ràng không giống một người dùng đơn lẻ.
• Nhiều tài khoản dùng chung một điểm thoát — yêu cầu của hàng chục tài khoản cùng đổ qua một nhóm IP.
• Dấu vân tay client bất thường — header yêu cầu, dấu vân tay TLS và đặc điểm thiết bị không khớp với một client bình thường.

Cộng dồn các tín hiệu này lại, hệ thống kiểm soát rủi ro của nhà cung cấp sẽ gắn cờ tài khoản của bạn.

Nhưng nếu hỏi tín hiệu nào có trọng số lớn nhất và dễ phát hiện nhất — tôi cho rằng đó là IP.

Lý do rất đơn giản: IP là tiêu chí sàng lọc nằm ở lớp ngoài cùng và tốn ít chi phí nhất. Một yêu cầu đến từ IP dân cư so với IP trung tâm dữ liệu thuộc về hai mức rủi ro hoàn toàn khác nhau trong mắt hệ thống kiểm soát rủi ro. ASN trung tâm dữ liệu + IP nhảy liên tục + vị trí địa lý bất thường — khi ba yếu tố này xuất hiện cùng lúc, gần như là đang nói thẳng với hệ thống kiểm soát rủi ro rằng "đây không phải người dùng bình thường".

Thật lòng mà nói, kiến trúc của các dịch vụ relay thông thường dẫm thẳng lên quả mìn này: mọi yêu cầu đều thoát ra từ máy chủ của relay, với hàng chục tài khoản dùng chung một nhóm IP trung tâm dữ liệu. Dù bạn cân bằng tải hay xoay vòng pool proxy thế nào, điểm thoát về bản chất vẫn là một phòng máy chủ. Tôi đã xem giải pháp của các nhà vận hành relay khác — họ xoay vòng proxy rất chăm chỉ, nhưng chỉ cần tra nhanh ASN là thấy tất cả đều là nhà cung cấp đám mây. Đổi mặt nạ, nhưng vẫn là gương mặt ấy.

Đó là lý do có người đổi qua ba dịch vụ relay và cứ hai tuần lại bị khóa tài khoản ở mỗi nơi — không phải xui xẻo, mà vì dịch vụ nào cũng có cùng một kiến trúc.

Vậy làm sao để giữ IP không thay đổi?

Nếu bạn là người dùng cá nhân, đã có một cách làm khá phổ biến: triển khai một gateway hợp nhất như New API hoặc One API trên NAS ở nhà, hoặc dùng các công cụ như sam-to-API, và cho mọi API của nhà cung cấp đi qua đó. Điện thoại, laptop, bất kỳ client nào gọi mô hình — không cái nào gọi thẳng đến nhà cung cấp. Thay vào đó, chúng đi qua thiết bị ở nhà, rồi thiết bị này chuyển tiếp đến API của nhà cung cấp. Như vậy, dù bạn gọi mô hình nào, IP thoát mà nhà cung cấp nhìn thấy luôn là IP mạng gia đình của bạn — không khác gì đang ngồi ở nhà dùng bình thường.

Còn khi ra ngoài thì sao? Hãy dùng các công cụ mạng mesh như Tailscale hoặc WireGuard để đưa lưu lượng từ điện thoại hay laptop về NAS ở nhà trước, rồi mới đi ra từ nhà. Dù bạn ở quán cà phê, văn phòng hay trên tàu, yêu cầu vẫn thoát ra từ mạng gia đình. Nhà cung cấp không bao giờ thấy IP của bạn nhảy chỉ vì bạn đổi Wi-Fi hay bật dữ liệu di động.

Cách làm này đã được kiểm chứng kỹ trong cộng đồng fnOS và giới tự host AI, với rất nhiều hướng dẫn và người thực hành. Với người dùng cá nhân, đây hiện là giải pháp cố định IP đáng tin cậy nhất.

Nhưng cách này chỉ giải quyết vấn đề của một người.

Một dịch vụ relay quản lý tài khoản của hàng chục, hàng trăm Provider. Bạn không thể đến nhà từng người để lắp NAS và cấu hình gateway. Bạn cần một giải pháp có hệ thống, cho phép mỗi Provider cài một node nhẹ và kết nối với nền tảng — yêu cầu vẫn thoát ra từ mạng của chính Provider, nhưng việc phân phối đơn và định tuyến lưu lượng do nền tảng xử lý tập trung.

Kiến trúc này được gọi là thoát phía Provider (provider-side exit) — yêu cầu thoát ra từ mạng của chính Provider, không phải từ máy chủ của relay.

Một phép so sánh: cách dùng NAS giống như tự mở một cửa hàng ven đường — bạn giao hàng từ nhà, tự lo nhập hàng, chọn hàng và nhận đơn. Provider Node giống như tham gia một nền tảng nhượng quyền — bạn vẫn giao hàng từ nhà, nhưng đơn hàng do nền tảng phân phối cho bạn. Địa chỉ giao hàng không đổi; thứ thay đổi là ai đang phân phối đơn.

Đây chính là việc Wokey Provider Node làm.

Cài đặt rất đơn giản — chỉ một lệnh, hỗ trợ macOS, Linux, Windows và Docker. Sau khi cài, mở bảng điều khiển cục bộ, liên kết tài khoản Wokey và nhập thông tin xác thực gói đăng ký trên máy. Khi node khởi động, nó duy trì một kết nối WebSocket với nền tảng Wokey. Nền tảng đẩy yêu cầu của người dùng sang, và node gửi yêu cầu đến API của nhà cung cấp ngay tại máy. Toàn bộ quá trình thoát ra từ IP của chính Provider — với nhà cung cấp, điều này giống hệt việc Provider dùng gói đăng ký của mình một cách bình thường.

Các nhà cung cấp hiện được hỗ trợ gồm OpenAI/Codex, Anthropic/Claude, Zhipu, Kimi, DeepSeek, Gemini, xAI và nhiều hơn nữa.

Sau khi tự vận hành kiến trúc này, điều tôi nhận ra rõ nhất là: nó không "chống lại" cơ chế kiểm soát rủi ro — nó đơn giản là không bao giờ chạm đến các điều kiện tiên quyết để bị phát hiện rủi ro. Từ góc nhìn của nhà cung cấp, đây chỉ là một người dùng bình thường ở nhà dùng gói đăng ký của mình, không có gì bất thường cần giải thích.

Toàn bộ dự án là mã nguồn mở theo giấy phép Apache-2.0, với danh sách trắng điểm thoát được ghi cứng trong mã nguồn. Nó an toàn không phải vì tôi nói vậy — mà vì từng dòng mã đều có thể kiểm tra.

Tất nhiên, tôi sẽ không khẳng định rằng thoát phía Provider đảm bảo không bao giờ bị khóa tài khoản. IP chỉ là một yếu tố — tần suất gọi, mô hình đồng thời và phân bố thời gian cũng có thể kích hoạt kiểm soát rủi ro. Không giải pháp nào có thể đảm bảo tỷ lệ bị khóa bằng không.

Nhưng logic thì rõ ràng: nếu bạn chưa xử lý tín hiệu lớn nhất, mọi tối ưu khác đều là xây nhà trên cát.

Chìa khóa để giảm tỷ lệ bị khóa là khiến cách bạn sử dụng không thể phân biệt với bình thường. Giữ IP không đổi là phần quan trọng nhất. Người dùng cá nhân có giải pháp cá nhân; dịch vụ relay cần một cách tiếp cận thoát phía Provider có hệ thống.

Khi cuộc cạnh tranh giữa các relay đi đến hồi kết, vấn đề sẽ không còn là ai có nhiều mô hình hơn hay giá thấp hơn — mà là kiến trúc của ai khiến nhà cung cấp không thể nhận ra bạn là relay. Dịch vụ bạn đang dùng ngay lúc này — yêu cầu thoát ra từ mạng của ai?