推奨設定：有効にすべきもの、触らずにおくべきもの

設定が原因だと突き止めたブロックの大半は、偽装が足りなかったからではなく、偽装しすぎたことが原因でした。このページは私たちの計測結果の要約です。使う価値のある設定、得られるものより失うもののほうが大きい設定、そしてどんな設定でも解決できない少数の問題をまとめています。

まずはここから

このページでほかに何も読まないとしても、まずはこの構成から始めてください。変えても安全な軸だけを変え、レンダリング、TLS、ブラウザのバージョンはそのままにします。

import { launch } from "clearcote";

const browser = await launch({
  lightStealth: true,        // metadata identity only — rendering, TLS and version stay real
  fingerprint: "account-42", // picks this identity's metadata bundle; keep it stable per identity
  proxy: { server: "http://gateway:8080", username: "u", password: "p" },
  geoip: true,               // timezone + languages + the address WebRTC reports follow the proxy exit
  humanize: true,            // trusted native input; navigator.webdriver stays false
});

Python でも同じ API を snake_case で使えます（light_stealth、fingerprint、geoip、humanize）。軸を追加するときは意図的に 1 つずつ、しかもホストのどの部分がそれを裏付けるのか説明できる場合に限ってください。以下の表のいくつかの行（r12 の個別制御、記録済みの人間の動きによる humanize、socks5Udp、サードパーティ Cookie とプロキシのスイッチ）は、ライセンスビルド（「GitHub で無料」または Pro）が対象です。オープンビルドではこれらは無視されます。humanize は生成した軌跡にフォールバックし、パスワード付きの SOCKS5 プロキシでは接続が拒否されます。

原則：偽装とは、ホストが裏付けなければならない主張である

検知とは、珍しい値を探すことではありません。探しているのは矛盾、つまり 1 台のマシンで同時には成り立たない 2 つのシグナルです。誰も偽装していないありふれた値は、何とも矛盾しません。裏付けのない偽装値はそれ自体が陽性のシグナルになり、しかも隠そうとした元の値よりも強いシグナルになります。

したがって、オプションを有効にする前に問うべきなのは「この値はもっともらしいか？」ではなく、「このマシンのどこに問い合わせればそれを裏付けられるか、そしてその答えは一致するか？」です。画面サイズはレンダリングサーフェスと照合されます。GPU 文字列は、その GPU が生成するピクセルと照合されます。名乗っている OS は、そのプラットフォームが解決するフォントと照合されます。ホストがその主張を裏付けられないなら、正直な値のほうが安全です。仕組みについては「検知の仕組み」を参照してください。

推奨すること

避けるべきこと

ここに挙げたものはどれも一般的な注意事項ではなく、実際に問題が起きることを私たちが計測で確かめたものです。

プロキシ

結果を左右する度合いは、たいていどのブラウザフラグよりもプロキシのほうが大きいのに、最もデフォルトのまま放置されがちなのもプロキシです。

• 出口 IP を固定する。アイデンティティごとに 1 つの出口 IP を、セッションの間ずっと維持します。フローの途中で IP が変わるセッションは、フィンガープリントがどれほど良くても自己矛盾を起こします。
• 地域をペルソナに合わせ、タイムゾーンと言語は手動で設定するのではなく、geoip: true に導出させてください。
• 認証付きプロキシはエンジンに任せる。HTTP(S) プロキシのパスワード認証にはブラウザ自身が応答するため（ライセンスビルド 151 r19 以降、Python & Node の SDK）、ページキャッシュは有効なままで、リクエストにインターセプトの痕跡も付きません。パスワード付きの SOCKS5 も、ライセンスビルドではそのまま使えます。ユーザー名とパスワードは別々のフィールドで渡してください。transparentProxy: true（152 r22 以降）は、リクエストヘッダーと接続タイミングからプロキシの存在を隠します。
• WebRTC のトレードオフを理解する。Chromium はメディアを HTTP プロキシや SOCKS プロキシ経由では決して送信しません。そのため何もしなければ、ピア間のトラフィックは実際の回線から出ていき、リレーに本当のアドレスを読み取られてしまいます。そこで SDK は、プロキシを経由せずに出ていく WebRTC の UDP をブロックします。オープンビルドでは geoip / webrtcIp を指定するとこのブロックが解除されますが、ライセンスビルドではブロックが維持されます。ブロックは geoip: true（または webrtcIp）と組み合わせてください。そうすれば、ページからは本物の Chrome が生成するのと同じ候補が、プロキシのアドレスを報告する形で見えます。組み合わせない場合、WebRTC は何も収集せず、ブロックされているように見えます。SOCKS5 プロキシ経由でピア接続を実際に機能させるには、socks5Udp: true を設定する（ライセンスビルド。プロバイダーが UDP リレーを許可している必要があります）か、ブラウザのプロキシを使わずにフルトンネル（WireGuard/OpenVPN）を使い、args で独自の --webrtc-ip-handling-policy を渡してください。それ以外の場合は、デフォルトのブロックポリシーのままにしてください。

設定では解決できない部分

最もよく読み取られる項目の中には、その上で動かすブラウザではなく、借りているマシンによって決まるものがあります。

思い込まずに確認する

このページの主張はすべて、ブラウザの内部から計測できます。設定済みのセッションで audit を開き、一致しないと判定された行を確認してください。これは上記の問題を見つけるのに私たちが使ったのと同じツールで、現在の構成がこれらの推奨事項のうちどれに反しているかを教えてくれます。