Vì sao gian hàng Shopee sạch vẫn bị yêu cầu xác minh khi dùng chung máy tính?
Một gian hàng sai, hai gian hàng sạch cũng dừng lại
Chị Lan bán đồ bếp ở Đà Nẵng, ba gian chia theo nồi chảo, dụng cụ cắt, hộp đựng thực phẩm. Tối 12/11 chị gửi cho tôi tấm ảnh màn hình Seller Center, giọng rối ríu: "Gian nồi chảo em đăng trùng mẫu nên bị giới hạn hiển thị, em nhận lỗi. Nhưng hai gian kia chẳng vi phạm gì, sao cũng bắt xác minh, đơn đang chờ giao mà không xuất được?"
Tôi hỏi lại đúng một câu: ba gian chị mở bằng gì? Chị bảo cùng một laptop, cùng một Chrome, chỉ khác ba số điện thoại, thi thoảng đổi sang cửa sổ ẩn danh cho "đỡ lẫn cookie". Có tuần nhân viên mới mở cả ba trên máy của quán, rồi đăng nhập lại bằng đúng trình duyệt chị dùng ở nhà. Nghe tới đây là tôi hiểu.
Chị nghĩ mỗi gian là một hồ sơ riêng vì mỗi cái có tài khoản và mã số thuế riêng. Phía hệ thống thì chia theo cái nó đo được, không phải cái mình khai. Tôi gợi ý tách từng gian ra một hồ sơ riêng trong BitBrowser, nơi cookie và vùng lưu trữ không giao nhau giữa các hồ sơ, rồi mới tính chuyện giải trình. Nhưng muốn sửa tới gốc, phải hiểu cái cụm liên kết dựng lên thế nào.
Hệ thống không chấm từng tài khoản, nó chấm cả cụm
Shopee không ra quyết định bằng một luật đơn kiểu "IP này xấu thì đình chỉ". Nó dựng một đồ thị. Mỗi tài khoản là một nút, mỗi tín hiệu dùng chung là một cạnh nối: cùng thiết bị, cùng địa chỉ mạng, cùng dải ASN, cùng tài khoản nhận tiền, cùng địa chỉ lấy hàng, cùng một bức ảnh sản phẩm, cùng khung giờ đăng nhập. Một nút có vấn đề thì độ tin cậy của cả cụm kéo xuống theo độ dày của các cạnh.
Nên câu trả lời không phải "hai gian kia bị phạt oan", mà là "hai gian kia đang nằm chung cụm". Đây cũng là lý do tài khoản mới tinh, chưa bán đơn nào, vẫn bị yêu cầu xác minh ngay lần đầu: tài khoản sạch, nhưng cái máy và đường mạng nó bước vào đã có lịch sử.
Cái gọi là liên kết được tính ra sao
Sàn lấy một giá trị băm của bộ thông số thiết bị làm định danh. Hai tài khoản cùng trả về một định danh là tự động có một cạnh nối, dù dùng hai địa chỉ mạng khác nhau. Thêm một cạnh nếu cùng dải ASN, thêm nữa nếu ảnh sản phẩm trùng sau khi nén. Cạnh càng nhiều, điểm gom cụm càng cao; vượt ngưỡng thì hệ thống không cần kết luận ai vi phạm, chỉ áp biện pháp theo mức rủi ro của cụm.
Dễ hiểu lầm là thứ tự xử lý. Không phải cứ có liên kết là đình chỉ ngay, mà thường đi từ nhắc xác minh, giới hạn hiển thị một phần, bổ sung giấy tờ, tạm giữ ký quỹ, rồi mới đến đình chỉ. Chị Lan đang ở bước hai của hai gian "sạch", vẫn còn đất giải trình. Nhưng cứ tiếp tục đăng nhập cả ba trên cùng máy lúc chờ là các cạnh nối lại được xác nhận mỗi ngày.
Vì sao cửa sổ ẩn danh không cắt được sợi dây đó
Ẩn danh chỉ xóa cookie và lịch sử lúc đóng cửa sổ. Nó không đổi card đồ họa, danh sách font, số luồng CPU, độ sâu màu, cũng không tách được IndexedDB và bộ nhớ đệm HTTP theo từng tài khoản. Nguy hiểm hơn là WebRTC: một trang gọi RTCPeerConnection có thể đọc địa chỉ IP nội bộ qua dòng candidate trong SDP. Đổi IP bên ngoài mà chừa chỗ này thì hai gian vẫn "nhìn thấy" nhau từ trong mạng LAN.
Với Seller Center, token phiên nằm trong cookie của tên miền bán hàng, kèm vài giá trị ở localStorage giữ trạng thái giao diện. Token hết hạn hoặc bị coi là bất thường thì hệ thống bắt xác minh bằng OTP của chủ shop, mấy chục đơn chờ giao đứng im đúng cái cảnh chị Lan kể. Thứ cần tách không chỉ là IP mà là toàn bộ vùng lưu trữ của một phiên.
Một hồ sơ riêng trong BitBrowser cấp cho mỗi gian một thư mục dữ liệu riêng và bộ thông số thiết bị nhất quán riêng, gán địa chỉ mạng theo hồ sơ, kể cả tự điền múi giờ và ngôn ngữ theo IP. Nó cắt đúng các cạnh nối sinh ra từ việc dùng chung máy, và không chạm vào lịch sử đơn hàng hay nội dung chị đăng bán.
Cấu hình lại từ đầu, và đoạn mã để kiểm tra
Tôi bảo chị dừng cả ba gian một buổi rồi dựng lại: một gian, một hồ sơ, một địa chỉ mạng cố định, một người phụ trách chính. Đặt tên theo ngành hàng và khu vực để sau còn tra được. Không nạp cookie mua sẵn, không đăng nhập "cho nhanh" bằng trình duyệt thường dù chỉ một lần. Đoạn Python dưới đây tạo hồ sơ theo bảng nội bộ qua Local API, theo tài liệu doc.bitbrowser.net.
import requests
API = "http://127.0.0.1:54345/browser/create"
#Bảng nội bộ của đội vận hành, không phải dữ liệu đăng ký tài khoản
shops = [
("NoiChao-DN-01", "203.0.113.11", 1080),
("DungCu-DN-02", "203.0.113.12", 1080),
("HopDung-DN-03", "203.0.113.13", 1080),
]
for name, host, port in shops:
payload = {
"name": name,
"groupName": "KH_Lan_DaNang",
"proxyInfo": {
"proxyMethod": "custom",
"proxyType": "socks5",
"proxyHost": host,
"proxyPort": port,
},
"browserFingerPrint": {
"coreProduct": "chrome",
"isIpCreateTimeZone": True,
"isIpCreateLanguage": True,
},
}
r = requests.post(API, json=payload, timeout=20)
print(name, r.status_code, r.json().get("data", {}))
Ba địa chỉ mạng, ba thư mục dữ liệu, cùng múi giờ Asia/Ho_Chi_Minh và ngôn ngữ vi-VN vì cả ba bán tại Việt Nam. Chị bật thêm xác thực hai lớp và bốn cấp quyền, để người phụ mới không mở nhầm hồ sơ của gian khác. Khi nghỉ việc, hồ sơ được chuyển lại chủ sở hữu, xóa bộ nhớ đệm, có nhật ký đính kèm.
Nhìn lại, và vài điều có thể đoán trước
Ba ý chị Lan mang về: hệ thống chấm cả cụm, sợi dây nối chủ yếu đến từ thiết bị và vùng lưu trữ chứ không chỉ từ IP, còn phần nghiệp vụ như ảnh sản phẩm hay lịch sử đơn thì không công cụ nào gỡ giúp. Tách hồ sơ là điều kiện cần để vận hành đa gian cho gọn, không phải tấm khiên cho một quy trình đang sai.
Tôi đoán các sàn Việt Nam sẽ đẩy mạnh đối chiếu chéo: không chỉ so thiết bị với mạng, mà so chuỗi hành vi theo thời gian, quan hệ giữa các gian trong cùng một kho, cả tín hiệu khâu giao nhận. Càng về sau, thứ có giá trị không phải một mẹo cấu hình mà là khả năng trình bày rõ ai làm gì, trên hồ sơ nào, lúc nào. Nhật ký sẽ quan trọng ngang địa chỉ mạng.
Ai đang cầm từ ba gian trở lên, cứ lập một bảng nhỏ: tên hồ sơ, địa chỉ mạng, múi giờ, người phụ trách, khung giờ, cách thu hồi quyền, rà mỗi quý. Và đọc quy chế sàn trước khi mở thêm gian, vì lúc có sự cố, cái cứu được bạn là hồ sơ giải trình chứ không phải phần mềm.
All rights reserved
