Cách tách hồ sơ trình duyệt cho nhiều tài khoản Zalo OA trên một máy tính
Anh Tuấn Phạm, 29 tuổi, ở Cầu Giấy Hà Nội, điều hành sáu tài khoản Zalo OA và hai tài khoản cá nhân cho chuỗi ba cửa hàng phụ kiện điện thoại. Bài toán của anh không phải là thiếu tài khoản, mà là chỗ Zalo Web chỉ giữ một phiên đăng nhập cho mỗi trình duyệt: mở tab thứ hai là phiên trước bị ghi đè, còn đăng xuất rồi đăng nhập lại giữa lúc đang chat với khách thì mất phiên, có lần còn bị yêu cầu xác minh lại.
Nguyên nhân nằm ở kiến trúc chứ không phải lỗi cấu hình: phiên Zalo Web gắn với device token, cookie và localStorage, nên mở nhiều tài khoản Zalo trên một máy bằng cùng một trình duyệt là điều kỹ thuật không khả thi. Bài viết bóc tách cơ chế đó rồi đi qua ba lớp giải pháp: tách theo hồ sơ trình duyệt, tách theo thiết bị thật có quản lý tập trung từ xa, và tách theo cloud phone Android.
Anh Tuấn Phạm, 29 tuổi, đứng ở tầng ba một tòa nhà nhỏ trên đường Trần Đăng Ninh, Cầu Giấy. Bên trong là ba mươi mét vuông, một kệ kính cường lực, một bàn thu ngân và mấy chục sạc cẩm USB-C xếp theo tên hàng. Chuỗi của anh có ba cửa hàng: cửa hàng chính ở Cầu Giấy, một cửa hàng nhỏ gần chợ Hoàng Hoa Thám và một chi nhánh ở Dịch Vọng.
Bán phụ kiện điện thoại thì khách hợp Zalo nhanh hơn nói chuyện điện thoại, đặc biệt với người lớn tuổi không rành chuyện đặt hàng qua Shopee. Từ năm ngoái anh đăng ký Zalo OA cho mỗi chi nhánh, mỗi chi nhánh hai tài khoản: một tài khoản mang tên cửa hàng để tư vấn và báo giá, một tài khoản lo phần hậu mãi, đơn hàng và bảo hành. Tổng cộng sáu tài khoản OA, cộng thêm hai tài khoản cá nhân là của anh và em trai.
Sáng thứ hai tuần trước, chính xác là 9 giờ 12 phút, anh Tuấn đang đứng ở quầy cửa hàng Dịch Vọng trả lời một khách về ống lưu sạc nhanh 20W. Khách nhắn: “Anh Tuấn ơi, sạc Type-C này còn hàng không, em lấy hai chiếc.” Anh đang định mở tài khoản OA của chi nhánh Hoàng Hoa Thám để gửi bảng giá cho khách thì đột nhiên màn hình trắng xóa, tài khoản đang chat với khách báo đã đăng xuất.
Anh làm đúng những gì anh đã làm cả trăm lần: bấm đăng nhập lại, quét mã QR, nhập mã OTP gửi về số điện thoại đã đăng ký của tài khoản OA. Lần này Zalo không cho vào ngay mà hiện màn hình yêu cầu xác minh lại tài khoản, phải chờ thêm. Hai mươi phút trôi qua trong khi khách đứng đợi ở quầy và nhắn thêm bốn tin. Buổi sáng hôm đó có khoảng bốn mươi khách chờ tin nhắn.
Chuyện đó đẩy anh Tuấn đi tìm hiểu kỹ thuật, vì trước đó anh chỉ nghĩ đây là Zalo “bắt quá chặt”. Thử cửa sổ ẩn danh thì tình hình y hệt, tab thứ hai vẫn ghi đè phiên của tab thứ nhất. Dùng Edge và Chrome song song thì được hai phiên, nhưng cửa hàng có sáu tài khoản thì phải sáu trình duyệt, máy chậm đi rõ rệt và nhân viên không nhớ nổi tài khoản nào đang nằm ở cửa sổ nào. Một lần nữa, anh mua thêm một máy tính cũ để gửi cho em trai ở nhà giữ, rồi phát hiện mỗi lần đổi ca là mất thời gian xin lại mã OTP.
Đến lúc anh hiểu ra một điều: đây không phải lỗi cấu hình, mà là giới hạn kiến trúc của Zalo Web. Một trình duyệt chỉ chứa được một phiên đăng nhập Zalo Web, và các phiên gắn với nhau bằng device token cùng cookie trong localStorage. Câu hỏi “mở nhiều tài khoản Zalo trên một máy” bằng cách bấm thêm tab đơn giản là không có đáp án kỹ thuật. Muốn chạy sáu tài khoản cùng lúc, phải tách ở tầng hồ sơ trình duyệt hoặc tầng thiết bị.
Sau hai tuần thử nghiệm với các công cụ quản lý đa tài khoản, cuối cùng anh chọn BitBrowser để tách mỗi tài khoản Zalo OA vào một hồ sơ trình duyệt riêng, mỗi hồ sơ một địa chỉ IP riêng tại Việt Nam và một múi giờ khớp với địa chỉ đó. Sáu tài khoản OA chạy song song trên một máy tính, nhân viên chuyển ca bằng cách bấm vào biểu tượng cửa sổ tương ứng, không còn phải đăng xuất đăng nhập lại giữa lúc đang nói chuyện với khách.
Bài toán còn lại của anh Tuấn Phạm là chi phí và ca trực. Với sáu tài khoản thì tách hồ sơ trình duyệt đã đủ dùng, nhưng khi chuỗi cửa hàng mở thêm chi nhánh thứ tư, việc trả lời tin nhắn ngoài giờ làm và xử lý lúc máy chủ chính bị treo trở thành bài toán riêng. Đó là lúc điện thoại đám mây bắt đầu tỏ ra hợp lý hơn chiếc điện thoại thật nằm trên bàn.
Vấn đề thật sự nằm ở đâu
Trước khi đổi công cụ, cần hiểu đúng nguyên nhân. Phiên đăng nhập Zalo Web không nằm ở tầng giao diện mà nằm ở tầng lưu trữ phía trình duyệt, và mỗi tài khoản Zalo Web đều được sinh ra từ bộ ba dữ liệu sau.
• Cookie phiên: cookie đăng nhập do máy chủ Zalo cấp, chứa mã định danh phiên và thông tin thiết bị đã đăng nhập.
• Device token: mảng định danh thiết bị sinh ra ở phía máy khách, lưu trong localStorage và IndexedDB của hồ sơ trình duyệt, rồi được gửi kèm lên máy chủ.
• Dấu vân tay trình duyệt: kết quả Canvas, WebGL, AudioContext, danh sách font, chuỗi trình duyệt và thông số phần cứng, dùng để mô tả “máy này là ai”.
Khi đăng nhập tài khoản thứ hai trong cùng một hồ sơ trình duyệt, máy chủ Zalo nhận về một device token mới cùng cookie mới và ghi đè trạng thái cũ. Phiên của tài khoản thứ nhất không còn hợp lệ, nên tab cũ hiện thông báo đăng xuất và lịch sử trò chuyện tải lại cũng không còn trọn vẹn.
Cơ chế này áp dụng như nhau với cửa sổ ẩn danh. Cửa sổ ẩn danh có cookie riêng, nhưng vẫn chạy trong cùng tiến trình trình duyệt, cùng địa chỉ IP, cùng hệ thống font và cùng phần cứng. Người dùng thường nghĩ rằng cửa sổ ẩn danh đã là “một máy mới”, nhưng với Zalo thì đó vẫn là cùng một máy.
Đây cũng là lý do nhiều người đổi sang giải pháp theo hướng khác mà vẫn không giải quyết được: cài Zalo trên nhiều máy ảo Android để chạy song song, nhưng máy ảo lộ các dấu hiệu riêng, chẳng hạn thuộc tính build, bootloader và cảm biến giả. Hoặc mở nhiều tài khoản trên cùng một chiếc điện thoại thật: bản thân ứng dụng Zalo trên Android cũng chỉ giữ một tài khoản đăng nhập tại một thời điểm, nên lựa chọn này về mặt kỹ thuật không khả thi.
Kết luận của tầng phân tích này khá rõ ràng: muốn có nhiều tài khoản Zalo song song trên một máy, phải tạo ra nhiều hồ sơ thực sự độc lập, mà hồ sơ độc lập thì bắt đầu từ tầng lưu trữ trình duyệt trở lên.
Ba lớp công nghệ phía sau
Lớp A — tách theo hồ sơ trình duyệt
Đây là lớp phổ biến và hợp lý khi số tài khoản nằm trong khoảng bốn đến mười. Mỗi tài khoản Zalo được gán một hồ sơ trình duyệt riêng, và mỗi hồ sơ có thư mục lưu trữ riêng cho cookie, localStorage, IndexedDB, cache và dữ liệu biểu mẫu. Thêm vào đó là dấu vân tay riêng (Canvas, WebGL, AudioContext, font, User-Agent, số nhân CPU, RAM), địa chỉ IP riêng, múi giờ và ngôn ngữ khớp với IP.
Vì mỗi hồ sơ là một tiến trình trình duyệt riêng biệt, nên sáu tài khoản mở song song với nhau rất ổn định. Đây cũng là lý do trình duyệt quản lý đa tài khoản như BitBrowser ra đời: nó đóng gói sẵn phần việc tạo hồ sơ theo mẫu, gắn proxy riêng theo từng hồ sơ, tự điền múi giờ và ngôn ngữ theo vị trí IP, rồi cho nhập hàng loạt từ file Excel tối đa 1.000 cửa sổ mỗi lần. Có cả Local API để điều khiển hồ sơ bằng mã, chạy được với Selenium, Playwright hay Puppeteer qua giao thức CDP.
Điểm cần lưu ý là một hồ sơ chỉ nên dùng cho một tài khoản, đổi lại không bao giờ bật chung một địa chỉ IP cho hai tài khoản cùng lúc.
Lớp B — tách theo thiết bị thật, quản lý tập trung từ xa
Lớp này giữ nguyên bản chất “điện thoại thật”: mỗi tài khoản gắn với một máy Android vật lý, và người vận hành điều khiển từ xa thay vì phải ngồi trước màn hình từng máy. Cách quản lý tập trung có thể là một máy tính ảo trên cloud như BitCloudPC, kết hợp bộ đồng bộ chuột bàn phím, đồng bộ tab và chia sẻ màn hình.
Ưu điểm rõ ràng là tín hiệu thiết bị thật: chuỗi UA, màn hình, cảm biến và ứng dụng nền đều tự nhiên. Nhược điểm nằm ở vận hành: tốn chi phí thiết bị, dễ thất lạc hoặc hư hỏng, và một tài khoản vẫn không thể đăng nhập đồng thời trên hai máy. Với quy mô nhỏ, đây vẫn là lựa chọn ổn định và dễ kiểm soát.
Lớp C — tách theo cloud phone Android
Đây là lớp dành cho đội phản hồi ngoài giờ làm hoặc cần chạy suốt ngày. BitCloudPhone, thành phần điện thoại đám mây trong cùng hệ sinh thái của BitBrowser, cung cấp máy ảo Android chạy trên cụm phần cứu thật, mô phỏng thông số của một chiếc điện thoại thật: chipset, ngôn ngữ, múi giờ, vị trí, nhà mạng, thông tin SIM và cảm biến. Danh mục hơn 600 nhà mạng toàn cầu, mô phỏng được IMEI và MAC, cài sẵn Google Play, hỗ trợ ADB, cho bật hoặc tắt root tùy chọn, cài gỡ mở đóng app và xóa dữ liệu ứng dụng.
Tính năng được người bán quan tâm là “tạo máy mới một chạm”: thao tác này khởi tạo lại môi trường máy và sinh ra thông số thiết bị mới, giúp làm mới danh tính thiết bị mà không phải cài lại ứng dụng từ đầu. Chi phí tính theo công suất tạm thời: bật máy là bắt đầu tính, tắt máy mới ngừng tính, có thêm gói công suất cố định theo tháng cho lịch trực đều đặn. Khi làm việc bằng API cần lưu ý giới hạn một request mỗi giây và các lệnh bật tắt dạng bất đồng bộ nên phải kiểm tra lại trạng thái sau khi gọi.
Ba lớp này không thay thế nhau, chúng xếp chồng theo quy mô.
Cấu hình thực tế
Một hồ sơ Zalo chỉ cần sáu thông số đúng là chạy ổn định. Bảng dưới đây là giá trị gợi ý cho tài khoản đặt ở Việt Nam.
Dưới đây là mẫu cấu hình một hồ sơ Zalo, dùng làm tham chiếu khi dựng hồ sơ trình duyệt. Trong BitBrowser, các tham số này nằm trong nhóm browserFingerPrint của từng cửa sổ, nên có thể nhập hàng loạt từ file Excel thay vì khai từng tài khoản một. Các giá trị dưới đây là ví dụ minh hoạ, cần đối chiếu với tài liệu Local API chính thức tại doc.bitbrowser.net trước khi áp dụng.
{
"name": "ZALO-OA-HN-CG-01",
"groupId": "zalo-oa-ha-noi",
"proxyMethod": "custom",
"proxyConfig": {
"proxyType": "SOCKS5",
"host": "113.161.72.10",
"port": 1080,
"proxyUserName": "ten_dang_nhap",
"proxyPassword": "mat_khau"
},
"browserFingerPrint": {
"coreProduct": "chrome",
"coreVersion": "112",
"ostype": "Windows",
"osVersion": "10",
"ua": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36",
"timeZone": "Asia/Ho_Chi_Minh",
"languages": "vi-VN,vi",
"webrtc": "disabled",
"canvas": "noise",
"webGL": "noise",
"audioContext": "noise",
"hardwareConcurrency": "8",
"deviceMemory": "8"
}
}
Trước khi giao ca trực, anh Tuấn chạy một đoạn kiểm tra nhỏ để chắc chắn không có hai tài khoản nào dùng chung một địa chỉ IP trong ca đó.
// Kiem tra trung IP giua cac ho so truoc khi giao ca truc
const profiles = [
{ name: 'ZALO-OA-HN-CG-01', ip: '113.161.72.10' },
{ name: 'ZALO-OA-HN-CG-02', ip: '113.161.72.10' },
{ name: 'ZALO-OA-HN-HHT-01', ip: '14.225.10.4' }
];
const seen = new Map();
for (const p of profiles) {
if (seen.has(p.ip)) {
console.log('Trung IP giua ' + seen.get(p.ip) + ' va ' + p.name + ' (' + p.ip + ')');
} else {
seen.set(p.ip, p.name);
}
}
Checklist triển khai cho đội CSKH, theo đúng thứ tự anh Tuấn làm lần đầu:
• Bước 1. Lập danh sách đầy đủ tài khoản: tài khoản OA nào của chi nhánh nào, tài khoản cá nhân nào thuộc ai, ai là người trực chính. Tài khoản nào không rõ chủ sở hữu thì xử lý trước khi làm bước sau.
• Bước 2. Tạo một hồ sơ riêng cho từng tài khoản, đặt tên theo quy ước như bảng tham số ở trên, gom theo nhóm chi nhánh để nhân viên nhìn ra ngay.
• Bước 3. Gắn proxy Việt Nam cho từng hồ sơ, bật tự khớp múi giờ và ngôn ngữ theo vị trí IP, rồi bấm kiểm tra kết nối để chắc chắn IP thực tế đúng quốc gia.
• Bước 4. Đăng nhập một lần cho mỗi tài khoản, hoàn tất xác thực hai lớp gồm mã OTP và xác nhận thiết bị, sau đó đóng hẳn trình duyệt thay vì chỉ đóng tab.
• Bước 5. Không dùng lại cookie, không xuất và nhập cookie chéo giữa các tài khoản, không dùng chung một tài khoản trên hai máy cùng lúc. Nếu cần bàn giao cho nhân viên mới thì dùng cơ chế chia sẻ hồ sơ trình duyệt có mật khẩu và hạn 7 đến 30 ngày.
• Bước 6. Ghi nhật ký vận hành: thời điểm mở hồ sơ, ai mở, tài khoản nào, dùng IP nào. Đây là dữ liệu để điều tra khi có khiếu nại từ khách hàng.
• Bước 7. Rà soát hằng tuần: tài khoản nào bị giới hạn chức năng, có hồ sơ nào trùng IP, có tài khoản nào bị đăng xuất ngoài dự kiến, và tài khoản nào đã lâu không có hoạt động để đưa vào kế hoạch bảo trì.
So sánh và chọn cách nào
Cùng một bài toán “mở nhiều tài khoản Zalo trên một máy” nhưng bối cảnh khác nhau thì lựa chọn khác nhau. Bảng dưới đây rút ra từ cách anh Tuấn cấu hình và từ kinh nghiệm của các đội vận hành tương tự.
Một vài điểm thực tế đáng biết trước khi chốt công cụ. Gói miễn phí hiện gồm 10 môi trường, đủ cho phần lớn chuỗi cửa hàng nhỏ; việc đổi gói không được hoàn tiền theo thỏa thuận dịch vụ, nên thử hết gói miễn phí trước khi nâng cấp. mọi gói đều có API, RPA và tính năng cộng tác nhóm, không khóa theo gói.
Rào tuân thủ và giới hạn thật của Zalo
Tách hồ sơ trình duyệt chỉ giải quyết phần kỹ thuật. Phần còn lại là điều khoản dịch vụ và quy chuẩn cộng đồng, nơi phần lớn rủi ro thực tế nằm.
Quy định cộng đồng của Zalo nghiêm về nội dung thương mại: cấm quảng cáo sai sự thật, phải dán nhãn rõ nội dung thương mại, cấm spam và hành vi gây rối. Quy định này áp dụng cho cả tài khoản OA lẫn tài khoản cá nhân dùng để bán hàng, và việc có bao nhiêu tài khoản không thay đổi nghĩa vụ này.
Bên cạnh đó, chính sách của TikTok và Shopee cấm dùng kênh khác để dẫn lưu lượng trái phép ra khỏi nền tảng. Nếu nội dung quảng cáo trên Zalo chỉ là bản sao của bài đăng bán hàng trên sàn thì không có vấn đề, nhưng nếu dùng Zalo như đường đi riêng để kéo khách rời hệ sinh thái thì rủi ro nằm ở phía nền tảng sàn, chứ không phải ở Zalo. Cách an toàn là dùng công cụ chính thức mà sàn cung cấp.
Cuối cùng, Zalo OA có giới hạn riêng: tài khoản OA gắn với một tên miền phụ, có hạn mức tin nhắn theo gói, và chịu chính sách quảng cáo riêng của hệ sinh thái OA. Nhiều người kỳ vọng cứ tách hồ sơ trình duyệt là sẽ tăng được số tin nhắn gửi, nhưng hạn mức nằm ở phía máy chủ chứ không nằm ở phía máy khách. Không công cụ nào loại bỏ được rủi ro một tài khoản bị hạn chức năng; điều công cụ làm được là giảm rủi ro gom nhóm do dùng chung hồ sơ trình duyệt, còn phần còn lại vẫn phụ thuộc vào việc tuân thủ điều khoản dịch vụ và quy chuẩn cộng đồng của nền tảng.
Nhìn lại bài toán của anh Tuấn, hướng đi của các nền tảng trong hai năm qua đã đổi rõ rệt. Trước đây hệ thống chủ yếu nhìn vào thiết bị: cùng dấu vân tay, cùng địa chỉ IP, cùng hồ sơ trình duyệt thì bị gom nhóm. Giờ hệ thống dịch chuyển sang xác thực danh tính thật và quản lý sự kiện đăng nhập, tức là hệ thống quan tâm một tài khoản đã đăng nhập ở đâu, vào lúc nào, từ thiết bị nào, còn có những phiên nào khác cùng tồn tại hay không.
Hệ quả thực tế là công cụ vận hành cũng phải thay đổi theo. Một bộ công cụ chỉ tạo ra nhiều danh tính dựng sẵn thì sẽ ngày càng khó đứng vững, vì phía nền tảng không còn hỏi “máy này là gì” mà hỏi “tài khoản này do ai dùng và dùng như thế nào”. Điều đòi hỏi bây giờ là một hồ sơ vận hành nhất quán: mỗi tài khoản một hồ sơ trình duyệt riêng, địa chỉ IP ổn định, nhật ký ai làm gì lúc nào, và nhịp hoạt động tự nhiên chứ không phải lịch trình máy móc giống nhau ở mọi tài khoản.
Đội nào chuẩn hóa vận hành sớm, việc đưa thêm chi nhánh hay thêm tài khoản sẽ rút xuống còn một dòng cấu hình, thay vì một cuộc hỏi han dài về cách đăng nhập an toàn. Còn với người bán nhỏ như anh Tuấn, lời khuyên vẫn là bắt đầu từ cái gần nhất: tách hồ sơ trình duyệt, giữ IP ổn định, ghi lại mọi thao tác, và để mỗi tài khoản gắn với một con người thật.
All Rights Reserved
