快手扫码登录的特点：双端协议分离
快手 web 端（www.kuaishou.com）的扫码登录走 passport 体系，但和抖音/B站不同，快手的二维码内容不是 URL 而是自定义文本，且确认环节的风控参数更多。整体流程同构，细节有坑。
流程拆解
第一步：获取二维码
POST https://passport.kuaishou.com/.../qrcode/generate (或 GET，以抓包为准)返回二维码内容串和 qrToken（有的版本叫 sid/token）。二维码内容形如 kuaishou://scanlogin?token=xxx——快手 App 扫码后解析这个伪协议。
第二步：轮询
POST https://passport.kuaishou.com/.../qrcode/poll
Body: qrToken=xxx状态码：等待扫码 / 已扫码（返回扫码用户头像昵称，待确认）/ 已确认 / 已过期。
第三步：确认后落地
确认后响应种下 web 端登录 cookie（kuaishou.server.web_st、kuaishou.server.web_ph 等）——注意快手的 web cookie 是分域名的，www.kuaishou.com 和 live.kuaishou.com 的登录态要分别激活。
token 刷新机制：快手的长会话设计
快手登录态的特点是双 token 制（类似 OAuth 的 access/refresh）：
web_st（短效 access token）：有效期短（小时级），过期后用 refresh 换新的web_ph（长效 refresh 凭证）：有效期长，用来刷新 web_st
刷新接口：
POST https://passport.kuaishou.com/.../token/refresh
Body: 带 web_ph 和旧 web_st工程意义：维护登录态池时，定时任务刷 web_st 而不是过期后重新扫码。刷新接口的风控比登录接口宽松得多。
精髓：四个实战坑
- cookie 分域激活。拿到 passport 域的 cookie 后，要访问一次目标业务域（如直播域）的激活接口，业务域 cookie 才落地。直接拿 passport cookie 调业务接口会 401
- 设备参数贯穿全程。二维码生成、轮询、刷新都要带设备标识（
deviceId/did），且要一致——轮询时换设备标识，确认后 cookie 绑定的是另一个设备，直接异常 - 二维码有效期短（约 2 分钟），轮询逻辑要处理过期自动重生成
- App 确认环节的滑块。新设备/异地 IP 的确认请求会触发滑块验证——协议模拟确认环节时，设备档案的"干净程度"决定要不要过验证码
协议模拟的完整架构
class KuaishouSession:
def __init__(self, device_id):
self.s = requests.Session()
self.device_id = device_id # 固定设备标识
def qr_login(self):
token, qr_content = self._generate_qr()
show_qrcode(qr_content) # 展示给用户扫
if self._poll(token):
self._activate_domains() # 分域激活
return True
def keepalive(self):
# 定时任务：每 2 小时刷一次 web_st
while True:
time.sleep(7200)
try:
self._refresh_token()
except Exception:
self._relogin() # 刷新失败重登总结
- 快手扫码流程同构但 cookie 分域，业务域要单独激活
- 双 token 制：web_st 短效 + web_ph 长效，定时刷新维持登录态
- 设备标识全程一致，是风控校验的暗线
- 确认环节可能触发滑块，设备档案质量决定通过率
交流微信：run1255