Kris e35f1d64cf feat: 初始化项目，添加完整的微信云部署方案与面板实现

包含以下核心内容：
1.  完整的Docker容器化部署方案，支持多架构amd64/arm64
2.  自研Web管理面板，包含登录认证、实例管理、权限控制
3.  微信实例容器镜像，内置中文字体与输入法修复
4.  飞牛OS应用打包适配
5.  完整的文档与运维指南

2026-07-05 03:50:30 +08:00

3.9 KiB

Raw Blame History

设备伪装与风控应对

返回 ← README

背景

微信 Linux 端会采集设备指纹做风控。容器/虚拟化环境若指纹异常（尤其是大量实例共用同一指纹），会被判定为"设备农场 / 非真实设备"，表现为：登录后立即被以安全原因强制退出，再次登录仍被踢，循环无法使用。

注意：虚拟化本身不等于风险——高校、企业大量使用云桌面 / 瘦客户端 / 虚拟机，都是虚拟化的真实办公设备。问题出在指纹不像一台独立的真实设备（最典型：所有实例共用一个 machine-id）。本项目的目标就是让每个实例看起来像一台普通、独立的 Linux 桌面。

本项目默认做了什么

以下措施默认全部开启，每个实例自动生效（新建实例 / 升级实例后）：

措施	说明	开关
唯一且持久的 machine-id	每个实例首启生成专属 machine-id，存入数据卷，重启/升级/重建都不变。解决"全网实例共用镜像里烤死的同一个 machine-id"这一最致命信号。	恒开
真实的 hostname	内部主机名伪装成"个人电脑"样式（如 `lenovo-pc-372`），不再是 `woc-wx-<hex>` 这种容器/服务器特征。每实例不同、稳定不变。	恒开
移除 `/.dockerenv`	删掉 Docker 注入的容器标记文件。	恒开
真实网卡 MAC	用常见网卡厂商 OUI（Intel/Realtek 等）+ 由实例 id 稳定派生的后三段，替代容器默认带"本地管理位"的 MAC（`02/26/ee…` 开头 = 明显非真实硬件）。每实例不同、稳定不变。	恒开
os-release 伪装成 deepin	`/etc/os-release` 显示为 deepin 23（微信官方支持的发行版；Deepin 基于 Debian，与本镜像用户态一致，不自相矛盾）。	`WOC_SPOOF_OS`，默认 1，设 0 恢复 Debian

实现位置：docker/woc-identity.sh（启动钩子 /custom-cont-init.d/00-woc-identity，root 身份、在微信启动前执行）+ panel/server/src/docker.ts（hostname / MAC / 开关透传，建容器时设置）。

手动「重置设备 ID」

若某个微信账号已经被风控标记、升级后仍登录即被踢，可以给它换一个全新的设备身份（相当于换一台新电脑）：

管理页 → 该实例卡片 →「安全」→「重置设备 ID 并重启」

会生成一个新的唯一 machine-id 并重启该实例，之后重新扫码登录。仅对已升级到新镜像的实例可用（旧镜像无设备身份模块，会提示先「升级实例」）。

已被标记账号的恢复

设备指纹是面向未来的：换了干净的唯一指纹后，新的登录才会以新设备身份示人。
已被风控标记的账号可能有冷却期，换设备 ID + 重新登录后不一定立刻恢复，需观察一段时间。
建议先拿非主力账号验证，确认稳定后再迁主号，避免主号反复触发风控。

局限与风险（务必知悉）

这是"尽力而为"，不是保证。 风控是持续对抗：腾讯会不断增加新的检测维度（如 X 服务器厂商串、无 GPU 软渲染、SMBIOS 缺失、行为特征等），本项目只能覆盖已知的、可控的指纹。
有封号风险。 在非官方环境运行微信本身违反其使用条款；是否使用、用于何种账号，请自行评估。强烈建议不要用主力/重要账号承担试验风险。
若伪装后仍被频繁踢，可尝试：WOC_SPOOF_OS=0 恢复真实 Debian（排除 os 伪装反而被交叉校验的可能），或反馈 issue 一起排查更深层信号。

调参

.env（复制自 .env.example）：

WOC_SPOOF_OS=1   # 1=伪装成 deepin（默认），0=显示真实 Debian

machine-id / hostname / dockerenv 三项无开关、恒定开启（它们没有合理的关闭理由）。

3.9 KiB Raw Blame History Unescape Escape