Pixelscan 検出ガイド：リスクスコアと checking proxy usage の意味

要点：Pixelscan のリスクスコアはネットワーク・ブラウザ・リーク・整合性の4種のシグナルから合成される。どれか1つでも自己矛盾すれば、リスク判定は押し上げられる。checking proxy usage はスキャン中のステータス表示にすぎず、最終結論はたいていプロキシ特徴の検知で、主因は IP 側にある。データセンターのアドレス帯、使い込まれて落ちた評価、時刻や言語が出口と合わないこと。まずネットワークを直し、それからブラウザ設定を調べる。 典型的な場面：プロキシを紐付けた直後に検査を走らせると、ページは checking proxy usage で止まり、赤寄りの判定が出たところで、どちらから直すべきか分からなくなる。

環境を検査するには、まず環境そのものが必要になる。その役目を引き受けるのが MostMate だ。AI フィンガープリントブラウザであり、アカウントごとに独立したブラウザ環境を割り当てられる。設定が正しいかどうかは、検出サイトで検証する。Pixelscan はその中でもハードルが高い部類に属する。

場面は見慣れたものだ。プロキシの紐付けを終えて Pixelscan を開くと、プログレスバーが checking proxy usage で数秒止まり、最後に赤寄りの判定が出る。多くの人はまず指紋パラメータをいじる。一通り変えてもスコアは動かず、原因は実のところブラウザ側ではなくネットワーク側にある。この記事ではレポートを上から下まで分解し、リスクスコアの合成方法、この表示が何を見ているか、問題が出たときにどちらを先に直すかを明確にする。

Pixelscan が測っているもの：1回のスキャンを構成する4種のシグナル

Pixelscan の公式説明ページ は、1回のスキャンを4面に分けて捉える。ネットワーク面は IP、ASN、TLS バージョンといった接続情報を記録する。ブラウザ面は Canvas、WebGL、User-Agent、Client Hints といった指紋シグナルを収集する。リーク面は WebRTC と DNS の2項目の検査を行う。整合性面はネットワークとブラウザの宣言を突き合わせ、食い違う箇所に印を付ける。4種のシグナルは最後に信頼スコアへ合成され、問題のリストが添えられる。

多くの検出サイトはこの4面のうち1面しか見ていない。Pixelscan のハードルが高いのは、この突き合わせの部分だ。単一のシグナルが正常でも加点はなく、シグナル同士が足を引っ張り合って初めて減点する。単純な IP 検索よりプラットフォームのリスク管理に近い発想なのも、ここに理由がある。

レポートの読み方：6種の結論が6種の問題に対応する

結論は表1枚に圧縮済み。モジュールで行を探すだけだ。

新しい UI では検出が独立したモジュールに分かれている。古いチュートリアルにある「ページ全体が緑」「最後の項目が赤」といった表現は、現在の画面と合わないことがある。レポートはモジュール名と、その横に表示される説明文を基準に読む。色は参考程度に留める。

checking proxy usage：この表示が確認しているもの

スキャンが進む間、ページには数条のステータスメッセージが順番に現れる。checking proxy usage が対応するのはプロキシ判定の工程だ。表示それ自体は結果を意味しない。レポートに落ちる結論は、たいてい Proxy Detected になる。トリガーは次の3か所だ。

1. IP 評価の問題。出口アドレスがデータセンター系 ASN の帯域に属するか、過去の乱用でブラックリストに載っている。検出サイトはアドレス帯の単位で直接マークを付ける。

2. 宣言どうしの矛盾。ブラウザの時刻帯、言語、位置が出口 IP の所在地と合っていない。ドイツのノードに切り替えたブラウザが、東九区の時刻を使い続けている、という具合だ。

3. 経路のリーク。WebRTC か DNS が代理経路を通っていない。実アドレスとプロキシアドレスが同時に現れ、偽装はひとりでに崩れる。

前の2類は IP 側の問題であり、ブラウザパラメータをいくら変えても解決しない。評価の記録は使い込まれてきた過去の履歴で、パラメータをどれだけ綺麗にしても、アドレス帯そのものの特徴は残る。3類目の塞ぎ方は、WebRTC 設定の専用記事 に項目ごとの解説がある。

調査順序：まずネットワークを正し、それからブラウザへ

レポートが赤寄りのときは、ネットワーク側から着手するのが最も効果的だ。順序は次のとおりだ。

1. 出口 IP の種類と評価を確認する。データセンター帯なら住宅系アドレスへ交換する。アドレス帯の特徴がアカウントへどう波及するかは、IP ブロックとプロキシ品質 の記事で分解している。

2. ブラウザの宣言を IP に追従させる。時刻帯、言語、位置を出口の都市に揃える。MostMate の環境設定 はプロキシ情報から推奨パラメータを提示できる。細かく調整する段階になってから、高度な設定を開いて手動で項目ごとに変えればよい。

3. リーク経路を塞ぐ。WebRTC と DNS の両方が代理経路を通っていることを確認する。両方漏れていれば、最初の2歩は無に等しい。

4. もう一度検査する。ネットワーク側が綺麗になった後で残る赤項目は、初めてブラウザパラメータの問題と特定できる。一つ前の節の表と照らし合わせながら、項目ごとに処理を進める。

一通り直したら再検査だ。動かすのは一度に1か所。

スコアよりも見る価値のある3つの落とし穴

• 1回の高スコアを長期の通行証と見なす。スコアが映すのはその回のセッションであり、出口 IP を替えれば、WebRTC の挙動が変われば、判定も動く。公式の説明には、綺麗なスコアは訪問者の身元の証明にならないと明記されている。検査は定例の動作にしたい。環境を新規作成したら検査、プロキシを替えたら検査、定期的に抜き取り検査。プロキシの二段階セルフチェック の記事は、この一連の動作を手順に分解したものだ。
• 過剰な偽装。レポートの Masked マークはパラメータが改変されたことを示す。変えすぎると、かえって自動化ツールの特徴に近づく。目指すのは普通で自己整合の取れた指紋であり、パラメータを積み上げるより互いに噛み合わせるほうが効く。
• シークレットモードで検出を防ぐ。シークレットモードが抑えるのはローカルの記録だけだ。指紋パラメータはそのまま露出する。スコアは良くならない。

よくある質問

checking proxy usage から動かないのは故障か。

一概にそうとは言えない。このメッセージが長く留まるのは、たいてい IP 情報データの返送を待っているからだ。公式の説明によれば、評価データは任意加入のサードパーティ製サービスから来る。データソースが揃わない場合、採点はエラーではなくダウングレードで応える。結果が返ってこないなら、ページを更新してもう一度スキャンし直せばよい。

住宅 IP に替えたのに proxy と出るのはなぜか。

住宅帯にも履歴がある。前の利用者に乱用されたアドレス、ブラックリストに載ったことのあるアドレスは、判定がそのまま維持される。DNS リクエストが代理経路を通っていなくても、同じことが起きる。調査順序に沿って、DNS と評価の2項目を別々に確認してみることだ。

検査のたびに結果が違うのは正常か。

正常だ。スコアはセッション全体で決まる。出口 IP、WebRTC の挙動、データソースの可用性、どれか1つが変われば判定も動く。同じ端末で前後2回走らせて差が出るのは、常態といえる。

リスクスコアはどの程度で合格か。

Pixelscan は統一された合格ラインを公表していない。判定はスコアの数字ではなく結論の文言を基準に読む。実務での目安は、主要な業務環境を Consistent かつ Proxy Detected なしに保つことだ。さらに同時期にある環境群の普段の水準と比べて、絶対値ではなく相対的な変化を見る。

おわりに

Pixelscan の価値はあのスコアそのものではなく、矛盾の示し方にある。ネットワークとブラウザの宣言が食い違えば、レポートは食い違った位置をそのまま指し示す。これはまさに複数アカウント環境が解決すべきシグナル整合性の問題に対応する。検査通過は起点にすぎない。各環境のシグナルを長期的に一致させ続けるには、環境の分離と設定の規律が頼みの綱になる。Pixelscan 以外にも、ニッチな検出サイトのまとめ のツールを流れに沿って補完検査に使える。各社の重点はまちまちだ。

追加の出費は要らない。MostMate のダウンロード から始めて、環境を作り、プロキシを紐付け、検査を一巡すれば、流れは整う。