日本語
VLESS + Reality ガイド: セキュアプロキシセットアップ
キーワード
このガイドを始める前に、説明が必要になる可能性が高い主要な用語を以下に示します。
| キーワード | 定義 |
|---|---|
| 🔐 VLESS | V2Ray/Xrayエコシステムの軽量プロキシプロトコルで、UUIDでユーザーを認証し、通常はRealityなどの最新ステルストランスポートと組み合わせて使用されます。 |
| 🔀 プロキシ vs VPN | プロキシは通常、アプリケーショントラフィックをサーバー経由で転送しますが、従来のVPNはデバイスまたはシステム用の完全な仮想ネットワークトンネルを作成します。 |
| 🎭 Reality | Xrayのステルストランスポートメカニズムで、ブラウザのようなTLSフィンガープリントと特別なキーベースの検証を使用して、トラフィックを通常のHTTPSに非常に近く見せます。 |
| 🔍 DPI（ディープパケットインスペクション） | パケットパターン、ハンドシェイク、プロトコルフィンガープリントを分析して、VPNやプロキシなどのトラフィックを識別およびブロックするネットワークフィルタリング技術です。 |
| 🖥️ VPS | レンタルして遠隔制御できる仮想プライベートサーバーで、VLESS + Realityセットアップのホストマシンとして機能します。 |
| ⚙️ 3x-ui | Xray用のウェブベースの管理パネルで、JSONを手動で編集することなく、インバウンド、ユーザー、Realityの設定を作成できます。 |
| 🚀 Xray | 3x-uiの下で実行されるコアプロキシエンジンで、VLESS、Reality、ルーティング、クライアント接続を実際に処理します。 |
| 🆔 UUID | 各クライアントに割り当てられ、VLESSの主な認証値として使用される一意の識別子です。 |
| 🌐 SNI | Server Name Indication、どのホスト名がリクエストされているかをサーバーに伝えるTLSフィールドで、Reality対象設定と正しく一致する必要があります。 |
| 🧬 x25519キーペア | Realityで使用される公開鍵/秘密鍵ペアで、承認されたクライアントが接続を完了でき、不要なプローブは異なる方法で処理されます。 |
| 🔑 公開鍵 vs 秘密鍵 | 公開鍵はクライアントと共有されて接続できるようにしますが、秘密鍵はサーバーのみに留まり、決して公開されてはいけません。 |
| 🧭 uTLSフィンガープリント | ブラウザを模倣するTLSクライアントフィンガープリント（例：chrome）で、接続を通常のブラウザトラフィックに見せるために使用されます。 |
| 📡 インバウンド | Xray/3x-uiのサーバー側リスナー設定で、プロトコル、ポート、トランスポート、セキュリティ設定を含む、クライアントがどのように接続するかを定義します。 |
| ⚡ BBR | Googleから提供されるTCP輻輳制御アルゴリズムで、一部のVPSネットワークパスでスループットと応答性を向上させることができます。 |
| ✅ ACME検証 | Let’s Encryptなどの証明書サービスで使用される公開検証ステップで、サーバーまたはドメインに到達可能であり、証明書をリクエストする権限があることを確認します。 |
2026年のVLESS VPN with Reality Stealth設定ガイド
よくある悩みです。VPNサーバーをセットアップして、すべてが完璧に動作しているのに、ある朝目覚めるとそれがブロックされていることに気づきます。昨日は接続できていたのに、今日は失敗します。あなた側に変更はないのに、突然何も機能しなくなります。これは仮定の話ではなく、2026年の従来型VPNプロトコルを使用する現実です。深いパケット検査技術は進化し、適切に暗号化されたトラフィックさえも識別してブロックできるようになりました。
解決策は異なる暗号化アルゴリズムでも、より高速なプロトコルでもありません。ネットワーク上でトラフィックがどのように見えるかについて、根本的に異なるアプローチです。VLESSとRealityステルスプロトコルを組み合わせることで、2026年に利用可能な最も効果的な自己ホスト型アプローチの1つとなり、プロキシトラフィックを通常のHTTPSトラフィックにより近く見せることができます。このガイドでは、3x-uiコントロールパネルを使用してVLESS + Realityサーバーをデプロイする方法を、このアプローチがなぜ機能するのかを理解することから、デバイス上で動作する接続を持つまで、段階的に説明します。
問題：標準VPNがブロックされる理由
シンプルなOpenVPNやWireGuardサーバーが数ヶ月、あるいは数年にわたって確実に機能していた時代は終わりました。Deep Packet Inspection（DPI）技術は劇的に進化し、もはや暗号化されていないトラフィックを検出するだけではありません。最新のDPIシステムは、ネットワークトラフィックの複数の特性を検査して、VPN接続を驚くほどの精度で識別します。
標準的なOpenVPNまたはWireGuardを使用して接続する場合を考えてみてください。トラフィックは暗号化されていますが、それでも認識可能な形状を持っています。OpenVPNは、通常のブラウザセッションのように見えないTLSハンドシェイクとトラフィックパターンを露出させることがよくあります。WireGuardはTLSを使用しませんが、そのUDPベースのハンドシェイクとパケット動作は、フィルタリングされたネットワーク上で十分に特徴的で目立つものです。これは、間違った国コードを持つパスポートを持つようなものです。ドキュメント自体は有効ですが、詳細は正当な旅行者と一致しません。
2026年では、このブロッキングはこれまで以上に速く発生します。新しくデプロイされたVPNが検出される前に数ヶ月間機能していたかもしれない時代は終わりました。現在、新しいサーバーは稼働開始から数日、あるいは数時間以内に識別される可能性があります。ブロッキングはより広範囲に及び、ISPレベル、企業ネットワークレベル、そして一部の管轄区域では国家ファイアウォールレベルで発生します。トラフィックを暗号化するだけでなく、トラフィックを完全に別のものに見せかけるソリューションが必要です。
VLESS とは？プロトコル解説
VLESS は「VMess Less」の略で、その名前はデザイン哲学を直接反映しています。V2Ray プロジェクトの元々のデフォルトトランスポートプロトコルであった VMess プロトコルの、より軽量でシンプルな後継として作成されました。VMess が暗号化、認証、トランスポートを 1 つの密結合システムにバンドルしていたのに対し、VLESS は不要なレイヤーを削ぎ落とし、クリーンでステートレスなトランスポートプロトコルを実現しています。
重要な区別はここです：VLESS はプロキシとして機能し、完全な VPN トンネルではありません。このプロトコルはトラフィックをサーバー経由にリダイレクトするのであって、完全な仮想ネットワークインターフェースを作成するわけではありません。ほとんどのユーザーにとってこの区別は学術的なものですが、機能的な結果は VPN から期待するものと全く同じです：トラフィックはサーバーの IP アドレスから発信されているように見えます。しかし、このプロキシアーキテクチャは、軽量なプロトコルオーバーヘッドがステルスメカニズムが干渉なく動作することを可能にするため、VLESS が Reality とうまく機能する理由そのものです。
プロキシ設計はまた、従来の VPN プロトコルと比較してオーバーヘッドが少ないことを意味します。管理するカーネルレベルのトンネルインターフェースはなく、必要以上の追加暗号化レイヤーはなく、このプロトコルは最初から最新の TLS ベースのステルスメカニズムと連携するように設計されました。このシンプルさは制限ではなく機能です。つまり、問題が発生する可能性が少なく、検出される可能性のあるフィンガープリントも少ないということです。
現実を理解する：ステルス技術
Reality は VLESS を単なるプロキシプロトコルから、通常の暗号化ウェブトラフィックと区別するのが非常に難しいものへと変換します。このメカニズムはシンプルさにおいて優雅です。何をしているかを隠そうとするのではなく、Reality はあなたのトラフィックを完全に別のものに見せかけます。
Reality は TLS ハンドシェイクレベルで動作する技術を通じてこれを実現します。クライアントがサーバーに接続すると、uTLS ライブラリを使用して Chrome、Firefox、または別の一般的なブラウザのフィンガープリントを複製する TLS ClientHello を送信します。サーバーは x25519 キーペアを中心に構築された Reality のキーマテリアルとクライアントパラメータを使用して接続を検証します。クライアントが予期された Reality 値を提示すれば、接続は VLESS プロキシとして進行します。提示しない場合—DPI システムまたはアクティブプローブがサーバーにヒットするときに起こることです—トラフィックは www.microsoft.com や www.apple.com などの正当なターゲットウェブサイトに転送されます。プローブシステムにとって、あなたのサーバーは明らかなプロキシエンドポイントではなく、通常のウェブサイトに見えます。
これは制服を着ているようなものと考えてください。国境警備員が車両を検査するとき、登録、ナンバープレート、運転手の外見に基づいて正当に見える車は詳細に検査しません。あなたのトラフィックは大企業の制服を着ているため、ネットワークインスペクタはそれが実は別のものであることを明かすであろう詳細な検査なしにそれを通します。uTLS フィンガープリントは変装であり、x25519 キー交換はあなたのクライアントだけが知っている秘密の握手です。
重要なポイント：これが機能するために独自のドメインは必要ありません。以前のステルス方法では、ドメインを所有し Let’s Encrypt 証明書を取得する必要があり、これは記録と追加の複雑さを生み出しました。Reality に必要なのは VPS IP アドレスだけです。ターゲットウェブサイト（Microsoft、Apple、Google）はほぼ 100% のアップタイムを持ち、最新の TLS 1.3 プロトコルをサポートしており、この技術の完璧なアンカーとなります。
ポート 443 はこの変装が最も良く溶け込む機会を与えます。標準 HTTPS トラフィックは通常ポート 443 を使用するため、Reality をそのポートに保つことで接続は通常のウェブブラウジングにはるかに近く見えます。他のポートは技術的には機能する可能性がありますが、デフォルトの日常的な HTTPS トラフィックの形状と一致しなくなるため、変装を弱めます。
よくある誤解
VLESS + Realityを初めて探索する際に、多くの人がつまずく3つの誤解に対処しましょう。
「VLESSはVPNである」 技術的には、VLESSはVPNではなくプロキシプロトコルです。TUN/TAPインターフェース、仮想ネットワークアダプタ、ルーティングテーブルの操作はありません。しかし、ユーザーの機能的な観点からは、VPNから期待できるものと全く同じものを提供します。つまり、インターネットトラフィックはサーバーのIPアドレスから発信されているように見えます。この区別はネットワークエンジニアにとっては重要ですが、エンドユーザーにはほとんど関係ありません。
「Realityはドメインが必要である」 これは、自分で所有するドメインとLet’s Encryptの証明書を使用していた初期のステルス技術には当てはまりました。Realityは特に、あなたが管理するドメインなしで動作するように設計されました。ブラウザフィンガープリント模倣とx25519キー認証を使用しており、登録、管理、更新の必要がありません。一度設定すれば、継続的に動作します。
「これはハッキング不可能である」 ハッキング不可能なものは何もありません。Realityは、通常のHTTPSトラフィックのように見えるため、検出とブロッキングに対して高い耐性があります。しかし、DPI技術の将来の改善、潜在的なプロトコルフィンガープリント、または標的型攻撃に対して免疫はありません。2026年現在、最も一般的なネットワークフィルタリング形式に対して利用可能な最高の保護を提供します。これを堅牢なソリューションとして扱い、魔法の盾ではなく考えてください。
始める前に必要なもの
任意のプロバイダーから VPS が必要です（例：AvaHost）。同様のサービスもすべて問題なく動作します。典型的なシングルユーザーのパフォーマンスの場合、1 CPU コアと 1GB RAM の基本プランで十分です。サーバーは Ubuntu 22.04 LTS または 24.04 LTS を実行する必要があります。これらのバージョンは、必要なネットワーク機能のカーネルサポートをすぐに備えています。
Root SSH アクセスは必須です。コマンドラインを介してサーバーに接続し、特権コマンドを実行できる必要があります。ほとんどの VPS プロバイダーはデフォルトでこれを提供しています。デプロイ後に IP アドレス、ユーザー名（通常は root）、パスワードまたは SSH キーを受け取ります。
クライアントアプリケーションについては、デバイスに応じて以下が必要です：Android 用の v2rayNG、Windows 用の v2rayN、macOS 用の V2Box または Streisand、iOS 用の Shadowrocket または FoXray。これらについては、このガイドの後半のクライアントアプリケーションセクションで詳しく説明します。
Reality メソッドの大きな利点の 1 つは、制御するドメインが不要であることです。多くのステルスセットアップでは、1 つを登録して管理する必要がありますが、Reality は VPS IP から直接動作し、正当な TLS 宛先の外観を借用できます。
法的考慮事項に関する簡単な注記：このガイドで説明されている技術は、正当なプライバシーとアクセスのニーズを対象としています。インターネットフィルタリング法は管轄区域によって大きく異なります。これらのツールの使用が、お住まいの地域の適用法に準拠していることを確認してください。
サーバー準備: BBR と基本設定
前提条件の確認が完了したので、サーバーを準備しましょう。このフェーズでは、ソフトウェアをインストールする前に VPS を最適化し、最初から最大限のパフォーマンスを確保します。
💡 ヒント: デプロイ前に BBR を使用してください — 制約のあるリンクや高遅延リンクではスループットと遅延が大幅に改善されることがよくあります。
まず、システムパッケージを更新します。これにより、最新のセキュリティアップデートと必要な依存関係が確保されます:
apt update && apt upgrade -y
このステップは VPS プロバイダーとネットワーク速度によって 1～5 分かかる場合があります。一部のプロバイダーはデプロイ時にイメージを事前更新しているため、一部のシステムでは迅速に完了する可能性があります。
次に、Google BBR 輻輳制御を有効にします。BBR (Bottleneck Bandwidth and Round-trip propagation time) は Google の輻輳制御アルゴリズムです。パケット損失を主な信号として依存するのではなく、利用可能な帯域幅とラウンドトリップ時間をより直接的にモデル化しようとするため、一部の VPS リンクではスループットと応答性が向上する可能性があります。
# Verify BBR module is available
lsmod | grep tcp_bbr
何も表示されない場合は、モジュールを手動でロードします:
modprobe tcp_bbr
次に、BBR を永続的に有効にするための sysctl 設定を作成します:
cat >> /etc/sysctl.d/99-bbr.conf << 'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
設定を適用します:
sysctl -p /etc/sysctl.d/99-bbr.conf
BBR がアクティブであることを確認します:
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
アクティブなアルゴリズムとして bbr が表示されるはずです。
一部のシステムでは BBR を有効にした後の再起動が有益です — モジュールが正しくロードされ、すべてのネットワーク最適化が有効になることを保証します:
reboot
ポート 443 に到達可能であることを確認してください。3x-ui インストーラーの組み込み Let’s Encrypt フローをパネルに使用する予定がある場合は、80/tcp も許可してください — このポートは ACME 証明書検証に使用され、パネル自体には使用されません。VPS プロバイダーがクラウドファイアウォールまたはセキュリティグループレイヤーも備えている場合は、そこでも同じポートを許可してください。Ubuntu では、最も安全なパスは通常 UFW です。
# If this is a remote VPS and you're enabling UFW for the first time, allow SSH before enabling the firewall
ufw allow OpenSSH
# Allow HTTPS-style Reality traffic
ufw allow 443/tcp
# Allow ACME validation for the 3x-ui panel's built-in Let's Encrypt setup
ufw allow 80/tcp
# Review rules, then enable only if UFW is not already active
ufw status
ufw enable
⚠️ 警告: ポート 443 は通常の HTTPS トラフィックと一致するため、強く推奨されます。他のポートは技術的には機能する可能性がありますが、自然に混在しにくく、セットアップがフラグされやすくなります。
サーバーは最適化され、3x-ui インストールの準備ができました。
3x-ui パネルのインストール
インストーラーを実行する前に、見落としやすい要件に注意してください。インストーラーの組み込み Let’s Encrypt セットアップでパネルの SSL 証明書を発行したい場合、80/tcp がパブリックインターネットから到達可能である必要があります。この ACME 検証ポートは、セットアップ中に選択するパネルポートとは別です。
インストールコマンドを実行します：
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)
現在のバージョンのインストーラーは、多くのチュートリアルで示されている古い番号付き Install / Update / Uninstall メニューで始まりません。代わりに、スクリプトはすぐにインストールを開始し、不足している依存関係をインストールし、最新リリースをダウンロードしてから、パネルセットアップのプロンプトを表示します。
典型的なインストールフローは次のようになります：
- カスタムパネルポートを設定するか、インストーラーにランダムなポートを生成させるかを選択します。
- インストーラーにランダムなユーザー名、パスワード、および webBasePath を生成させます。
- パネル SSL を設定する方法を選択します：
- 1 = ドメイン用の Let’s Encrypt
- 2 = サーバー IP 用の Let’s Encrypt
- 3 = 既存の証明書を使用
- 組み込み Let’s Encrypt フローを使用する場合は、証明書プロンプトを完了します。
⚠️ 重要： パネルポートは ACME 検証ポートと同じものではありません。パネルを 13525 などのランダムポートで実行しながら、Let’s Encrypt が証明書を検証できるようにパブリック 80/tcp を開く必要があります。
重要なルールは簡単です：古いチュートリアルからコピーした仮定ではなく、独自のインストーラーが出力した正確な認証情報、パス、および URL を使用してください。
最終的な出力は次のようになります：
Username: GENERATED_USERNAME Password: GENERATED_PASSWORD Port: 13525 WebBasePath: RANDOM_PATH Access URL: https://YOUR_SERVER_IP:13525/RANDOM_PATH
サービスが実行されていることを確認します：
systemctl status x-ui
このチェックは重要です。ステータス出力のウェブサーバー行を特に確認してください：
- Web server running HTTPS … が表示される場合、パネル SSL は正常に機能しています。
- Web server running HTTP … が表示される場合、パネルは正常にインストールされましたが、SSL セットアップは完了しませんでした。
独自のインストールで生成された正確な URL、ユーザー名、およびパスワードを使用してパネルにアクセスします。パスが /panel であると仮定しないでください。また、独自のインストールで明示的に記載されていない限り、認証情報が admin/admin であると仮定しないでください。
💡 ヒント 1： 現在のパネル設定を再度表示し、アクセス URL を出力するには、CLI で “x-ui” コマンドを実行し、メニュー出力から番号 10 “View Current Settings” を選択します。
💡 ヒント 2： アクセス URL が読み込まれない場合は、VPS ファイアウォールで 3x-ui パネルポートが開いていることを確認してください。たとえば、パネルがポート “13525” で実行されている場合は、”ufw allow 13525/tcp” で許可します。13525 を 3x-ui パネル用に設定した実際のポートに置き換えてください。
インストーラーが完了しても systemctl status x-ui が HTTP を表示する場合
最も一般的な原因は、Let’s Encrypt 検証中に 80/tcp がパブリックインターネットから到達可能ではなかったことです。この場合、パネルはインストールして起動することができますが、証明書の発行に失敗します。
まずファイアウォールを修正します：
ufw allow 80/tcp
ufw status
VPS プロバイダーがクラウドファイアウォールまたはセキュリティグループレイヤーを持っている場合は、そこでも 80/tcp を許可してください。次に、3x-ui 管理スクリプトからパネル証明書セットアップを再実行します：
x-ui
IP ベースのパネル証明書の場合は、以下を選択します：
- 19 → 6 (Get SSL for IP Address)
ドメインベースのパネル証明書の場合は、以下を選択します：
- 19 → 1 (Get SSL (Domain))
証明書が発行された後、再度確認します：
systemctl status x-ui
続行する前に、ステータス出力が Web server running HTTPS … を表示していることを確認してください。
💡 ヒント： 生成された認証情報とパネル URL をすぐに保存してください。また、証明書の発行に失敗した場合、インストーラーの概要は誤解を招く可能性があることに注意してください。最終ブロックが HTTPS URL を出力しても systemctl status x-ui が HTTP を表示している場合は、サービスステータス出力を信頼し、先に進む前に SSL を修正してください。
VLESS + Reality インバウンドの設定
これは VPN のようなシステムが実際に作成される重要な設定ステップです。3x-ui パネル内で、Inbounds → Add Inbound に移動します。
以下のようにフィールドを設定します：
| フィールド | 値 | 注記 |
|---|---|---|
| Protocol | VLESS | ドロップダウンから選択 |
| Listen IP | 0.0.0.0 | デフォルト / すべてのインターフェース |
| Port | 443 | 最も自然な HTTPS カモフラージュのために推奨 |
| Client → Authentication | 空のままにする / デフォルト | この基本的なセットアップでは Get New keys を使用しないでください |
| Client → decryption | none | VLESS に必須 |
| Client → encryption | none | デフォルトのままにします |
| Client → Flow | xtls-rprx-vision | Client サブセクションで設定します。このフィールドがまだ表示されていない場合は、まず Transmission を TCP (RAW) に、Security を reality に設定してください。 |
| Transmission | TCP (RAW) | 直接 TCP トランスポートを使用 |
| Security | reality | セキュリティオプションから選択 |
| uTLS | chrome | 一般的なブラウザフィンガープリントを使用 |
| Target | www.microsoft.com:443 | フォールバック / プローブ用の安定した TLS 1.3 ターゲット |
| SNI | www.microsoft.com | Target と一致させたままにします |
| Short IDs | 生成するか、パネルのデフォルトを使用 | 生成された値の 1 つをクライアントにコピーします |
| SpiderX | / | シンプルなデフォルト |
| Public Key | Get New Cert で生成 | これをクライアントにコピーします |
| Private Key | Get New Cert で生成 | サーバーのみに保持します |
📋 注記： Total Flow、Traffic Reset、Duration、Fallbacks、Proxy Protocol、HTTP Obfuscation、Sockopt、External Proxy、Show、Xver、Max Time Diff、Min Client Ver、Max Client Ver、Sniffing、および ML-DSA フィールドなど、その他の表示されているフィールドは、この基本的なセットアップではデフォルトのままにしてください。
最後に、Save をクリックしてインバウンドを作成します。
⚠️ 警告： ポート 443 は通常の HTTPS トラフィックと一致するため、最適なデフォルトです。変更した場合、インバウンドは機能する可能性がありますが、通常のトラフィックとしてうまく混在しなくなります。
⚠️ 警告： Reality ターゲットは TLS 1.3 をサポートする必要があります。Microsoft、Apple、Google は安全な選択肢です。TLS 1.3 をサポートしていないターゲットを使用すると、Reality は失敗します。このプロトコルは TLS 1.3 ハンドシェイク用に特別に設計されているためです。
これらの値が重要な理由：ポート 443 は最も信頼できる HTTPS プロファイルを提供し、安定した TLS 1.3 ターゲットはプローブが正当な場所に到達する場所を提供し、chrome フィンガープリントはクライアント側をインターネット上で最も一般的なブラウザフィンガープリントの 1 つと一致させます。シンプルに始めて、1 つの動作パスを取得してから、複数のターゲットが必要な場合は後で拡張します。
3x-uiでのユーザー管理
インバウンドを設定したら、デバイスが認証に使用するユーザー接続を作成する必要があります。3x-uiで、Inbounds → [VLESSインバウンドメニューをクリック] → Add Clientに移動します。
各ユーザーには一意のUUID（自動生成）、識別用のメール、およびオプションのトラフィック/有効期限制限が付与されます。クライアントを作成すると、パネルは接続に必要な値を生成します：サーバーアドレス、UUID、フロー、公開鍵、短いID、およびSNI関連の設定です。
選択したインバウンドのプラス（「+」）記号を押すと、ユーザーリストが表示されます。
クライアントのエクスポート
単一のクライアントの接続詳細をエクスポートするには、まずインバウンド行を展開してクライアントテーブルを表示します。クライアント行で、クライアントごとの2つのエクスポートアクションを使用します：
- QRアイコン → QRモーダルを開く
- 情報アイコン → 詳細モーダルを開く
これらは最初の2つの共有方法に対応しています。
QRコード：クライアントのQRアイコンをクリックします。サブスクリプションが有効な場合、QRモーダルに2つのQRコードが表示される場合があります：
- Subscription → クライアントのサブスクリプションURLのQR
- Client QR（クライアントメールまたは識別子（例：example@mail.com）でラベル付け）→ 直接VLESS Reality URIのQR
サブスクリプションQRは、自動更新をサポートするクライアントに便利です。クライアントQRは、その特定のクライアント用の1回限りの直接インポートです。
共有リンク / URL：クライアントの情報アイコンをクリックします。詳細モーダルで、2つのテキストエクスポートタイプが表示される場合があります：
- Subscription URL → 更新可能なサブスクリプションエンドポイント
- URL → そのクライアント用の直接VLESS Reality URI
デスクトップインポート用にURLセクションの横にあるコピーボタンを使用します。
最低限、使用可能な直接Reality URIには、次のような入力された値が含まれている必要があります：
type=tcp encryption=none security=reality sni=www.microsoft.com fp=chrome pbk=YOUR_PUBLIC_KEY sid=YOUR_SHORT_ID spx=/ flow=xtls-rprx-vision
pbk=はReality公開鍵であり、直接VLESS URIに属します。サブスクリプションURL自体は通常pbk=を含みません。これはフェッチエンドポイントのみであり、返されたコンフィギュレーションに実際のRealityパラメータが含まれているためです。
一部の3x-uiバージョンでは、pbk=が空の場合があるReality共有リンクバグがありました。直接URIにpbk=またはsid=がない場合は、盲目的に信頼しないでください。その場合は、代わりに手動設定を使用してください。
手動設定：個別の「手動設定」エクスポートボタンはありません。実際には、手動設定とは、クライアントアプリに値を直接入力するか、生の値から最終的なVLESS Reality URIを自分で構成して検証することを意味します。必要な値を以下から収集します：
- 情報モーダル：サーバーアドレス、ポート、UUID、フロー、および直接URI
- インバウンドのReality設定：SNI、公開鍵、短いID、フィンガープリント（chrome）、および必要に応じてSpiderX（/）
異なるデバイスまたは異なる人向けに複数のユーザーを作成できます。各UUIDは独立しているため、1人のユーザーのアクセスを取り消しても、他のユーザーには影響しません。
Xrayの手動設定（概要）
グラフィカルインターフェースを使用せず、Xray設定を直接編集したいユーザーもいます。標準的なLinux 3x-uiインストールでは、アクティブなランタイム設定は/usr/local/x-ui/bin/config.jsonに書き込まれるため、ここで検査したり、一時的な手動変更を加えたりできます。
そのファイルはパネルの信頼できる情報源ではなく、生成されたランタイムアーティファクトとして扱ってください。3x-uiはデータベースバックアップ設定からconfig.jsonを再構築するため、Xrayが再起動されたときやパネルで変更を保存したときに、手動編集が上書きされる可能性があります。
編集する前に、バックアップを作成してください：
cp /usr/local/x-ui/bin/config.json /usr/local/x-ui/bin/config.json.bak
手動編集は迅速なテストやデバッグに役立つことがありますが、不正なJSONはXrayの起動を停止させる可能性があります。3x-uiがニーズを満たしている場合は、永続的な変更にはパネルを使用し、config.jsonの直接編集は高度なケースのみに限定してください。
プラットフォーム別クライアントアプリケーション
サーバーに接続するには、デバイスにクライアントソフトウェアが必要です。以下が利用可能なオプションです：
| プラットフォーム | 推奨アプリ | 備考 |
|---|---|---|
| Windows | v2rayN | システムトレイ統合機能付きGUIクライアント |
| macOS | V2Box、Streisand | V2Boxは無料；StreisandはApp Storeで利用可能 |
| Android | v2rayNG、NekoBox | 両方ともGitHubおよびF-Droidで利用可能 |
| iOS | Shadowrocket、FoXray、V2Box | Shadowrocketは有料；FoXrayの利用可能性は地域により異なる場合があります |
Windowsの場合、v2rayNが推奨される選択肢です。積極的にメンテナンスされており、クリーンなインターフェースを備え、Reality設定にネイティブ対応しています。モバイルの場合、v2rayNGとV2Boxの両方がQRコードインポートに対応しており、セットアップが迅速です。
📋 注意： Appleプラットフォームのクライアント利用可能性は頻繁に変更されます。リストされたアプリがお客様の地域で利用できない
最初のクライアントを接続する
v2rayNを使用してWindowsクライアントを接続する手順を説明します。他のプラットフォームでも同様のプロセスですが、ここでは完全な例を示します。
ステップ1: v2rayNをダウンロード
https://github.com/2dust/v2rayN/releasesにアクセスして、現在のWindowsデスクトップビルドをダウンロードします。2026年現在、最も簡単なオプションは通常v2rayN-windows-64-desktop.zip（またはリリースページに表示されている現在のデスクトップパッケージ相当）です。
ステップ2: 抽出して実行
ZIPをフォルダに抽出します（例：C:v2rayN）。v2rayN.exeを実行します。最近のデスクトップビルドは通常自己完結型なので、通常は別の.NETデスクトップランタイムをインストールする必要はありません。アプリケーションはシステムトレイに表示されます。
ステップ3: 設定をインポート
この接続では、3x-uiから直接VLESS URLを使用します。サブスクリプションURLではなく、vless://で始まるものです。エクスポートされたRealityリンクにpbk=やsid=などの必要な値が不足している場合は、前の3x-uiセクションに戻り、インバウンド設定から手動値を使用してください。
v2rayNで、ウィンドウの左上にあるConfigurationメニューを開きます。最も簡単な方法は、3x-uiから直接VLESS URLをコピーしてから、Configuration → Import Share Links from clipboardを選択することです。ほとんどのビルドでは、Ctrl+Vを押すだけでも可能です。アプリが値を貼り付けられるように、必ず直接VLESS URLをコピーしておいてください。
クリップボードインポートが希望のオプションでない場合は、QRコードまたは手動インポートも使用できます。
ステップ4: 接続
クライアントがインポートされた後、Windowsクライアントとサーバー間のトンネルをアクティブにするには、v2rayN UIの下部にある「Enable tunnel」を押します。
ステップ5: 確認
ブラウザを開いてhttps://whatismyipaddress.com/またはhttps://ip.sbにアクセスします。表示されるIPアドレスは、ローカルIPではなくサーバーのIPである必要があります。これにより、トラフィックがVPN経由でルーティングされていることが確認されます。
セットアップの検証
接続検証により、すべてが期待通りに機能していることを確認します。ブラウザでIPアドレスを確認する以上に、実行する価値のある追加テストがいくつかあります。
IPアドレスチェック: 接続中に https://whatismyipaddress.com/ または https://ip.sb にアクセスしてください。表示されるIPアドレスは、自宅またはローカルネットワークのIPではなく、VPSサーバーのIPと一致する必要があります。
DNSリークテスト: https://dnsleak.com または https://browserleaks.com/dns にアクセスしてテストを実行してください。適切に設定されたクライアントは、プロキシがアクティブな間、通常のローカルDNSリゾルバーを公開しないようにする必要があります。
一般的な問題と解決方法
問題 原因 解決方法 接続できない ポート 443 がブロックされている ファイアウォールを確認: ufw allow 443/tcp とクラウドプロバイダーコンソール パネルが開かない URL が間違っているか古い /panel の想定 インストーラーが出力した正確な HTTPS URL を使用してください インポートされたリンクが接続しない Reality リンクに pbk または sid がない リンクを検査するか、手動クライアント設定に切り替えてください 接続タイムアウト SNI が間違っている クライアント設定で SNI が一致することを確認してください (www.microsoft.com) TLS エラー フィンガープリントが間違っているか Reality 値が一致していない フィンガープリントを chrome に設定し、SNI、公開鍵、短い ID を再確認してください 速度が遅い BBR が有効になっていない サーバー準備セクションに従って BBR を再度有効にしてください 「サーバーからの応答がありません」 ファイアウォールがブロックしている サーバーファイアウォールとクラウドプロバイダーのセキュリティグループの両方を確認してください 次のステップと高度なオプション
VLESS + Reality VPNが正常に動作するようになりました。ここから、いくつかの改善が可能です:
バックアップインバウンドを慎重に追加する: フォールバックが本当に必要な場合は、VMess + WebSocketなどのセカンダリインバウンドを追加できます。ただし、インバウンドを追加するたびに複雑性が増し、セキュリティと トラブルシューティングの対象が1つ増えることを忘れずに。
複数ユーザーへのスケーリング: 3x-uiで家族やデバイス用の追加クライアントを作成します。各クライアントは一意のUUIDを取得し、使用状況を個別に追跡できます。
パフォーマンスチューニング: BBRはすでに有効になっていますが、TCP/UDP最適化、ネットワークバッファチューニング、サーバー側のTCPチューニングを探索して、わずかな改善を実現できます。
代替SNIターゲット: Microsoft/Apple/Googleは信頼性が高いですが、一部のユーザーはwww.oracle.comまたは他のターゲットを好みます。原理は同じです—有効なTLS 1.3証明書を持つすべてのサイトが機能します。
パネルセキュリティ: 可能であればパネルポートを自分の管理者IPに制限し、手動で選択した場合は認証情報をローテーションし、Fail2Banをインストールしてパネルをブルートフォース攻撃から保護することを検討してください。
結論
VLESS + Realityは、従来のVPNプロトコルよりも優れた偽装が必要な場合、2026年の強力なセルフホスト型オプションです。その利点は魔法のような不可視性ではなく、トラフィックが高度にフィルタリングされたネットワーク上のOpenVPNやWireGuardスタイルの接続よりも、通常の暗号化されたウェブトラフィックにはるかに近く見えるという点です。メンタルモデル（ブラウザのようなTLSフィンガープリンティング、Realityキーマテリアル、信頼できるターゲット、標準的なHTTPSポート）を理解していれば、セットアップのデプロイ、デバッグ、保守がはるかに簡単になります。ここからの自然な次のステップは、パネルセキュリティの強化、クライアントデバイスの追加、および自分の環境に最適なターゲットとクライアントアプリの検証です。ホスティングについては、AvaHostのようなプロバイダーがVLESS + Realityセットアップを実行するための安定した基盤を提供し、信頼性の高いアップタイムと簡単な管理を保証します。
関連投稿
