NaiveProxy インストール チュートリアル NaiveProxy 高速隠しプロキシ ツール

NaiveProxy、新世代の高速プロキシ ツール、NaiveProxy チュートリアル

インストール中 NaiveProxy ネットワーク技術の更新に伴い、従来のいくつかのプロキシツール徐々に淘汰されていくのですが、その理由は自明であり、淘汰されていく過程で、数多くの新しい技術が生まれてきました。 NaiveProxy とは何かについて詳しく見てみましょう。強力で魔法のプロキシ ツール。

NaiveProxyとは

NaiveProxy は、ノルウェー語で NaïveProxy、中国語に訳すと「ナイーブ プロキシ」と呼ばれ、以下によって設立されました。 クルツグラト Master によって開発された新しいネットワーク プロキシ テクノロジー。Chrome のネットワーク スタックを使用してトラフィックを偽装し、強力なプライバシー保護機能と低い検出性を備えています。パフォーマンスとセキュリティを確保するには、Chrome ネットワーク スタックを再利用することがベスト プラクティスです。

NaiveProxy は キャディー Web サーバーのフォワード プロキシ プラグインは非常に強力です。では、キャディとは何でしょうか？

キャディとは

Caddy は、HTTP/2 をサポートする Golang で書かれたオープンソース Web サーバーです。 Golang 標準ライブラリを使用して HTTP 機能を提供します。 Caddy の注目すべき機能は、HTTPS がデフォルトで有効になっていることです。これは、追加の構成なしで HTTPS 機能を提供する最初の Web サーバーです。

著者の Matt Holt は 2014 年 12 月に Caddy の開発を開始し、2015 年 4 月に最初のバージョンをリリースしました。リリースから 1 年で、GitHub では 20,000 回以上ダウンロードされ、4,500 個のスターを獲得しました。

Caddy 支持各种 Web 技术，提供静态编译的二进制文件，支持 i386、amd64 和 ARM 架构上的 Windows、Mac、Linux、Android 和 BSD 操作系统。

Caddy 自動 HTTPS を備えた高速かつスケーラブルなマルチプラットフォーム HTTP/3 Web サーバー

キャディ公式サイト：https://caddyserver.com/

GitHub プロジェクトのアドレス:https://github.com/caddyserver/caddy

Caddyについてはあまり紹介しませんが、Caddyについてもっと知りたいネチズンは、Caddyの公式ウェブサイトとプロジェクトページにアクセスして確認してください。 NaiveProxy について話を続けましょう

NaiveProxy と他のツールの違いは何ですか?

NaïveProxy は、Chromium のネットワーク スタックを使用して、強力な検閲耐性と低い検出可能性でトラフィックを偽装します。 Chrome のスタックを再利用することで、パフォーマンスとセキュリティのベスト プラクティスも確保されます。

Cronet も同様に Chromium のネットワーク スタックから派生したライブラリですが、その正式バージョンは Android と iOS に限定されています。 NaïveProxy の Cronet フォークは、ネイティブ API のバイナリ バージョンを提供し、複数のプラットフォームをサポートし、cgo および cronet-go バインディングを使用した Go アプリケーションの作成をサポートします。

Chromium のネットワーク スタックを使用すると、次のトラフィック攻撃を軽減できます。

• サイトのフィンガープリント/トラフィック分類: HTTP/2 でのトラフィックの再多重化によって軽減されます。
• TLS パラメータ フィンガープリント: Chrome のネットワーク スタックの再利用による失敗。
• アクティブ プロービング: アプリケーション フロントエンドによって無効にされます。つまり、アプリケーション層ルーティングを使用してプロキシ サーバーを共通のフロントエンド サーバーの背後に隠します。
• 長さに基づくトラフィック分析: 長さのパディングによって軽減されます。

 

NaiveProxy は Chrome のネットワーク スタックを使用し、Chrome と標準フロントエンド (Caddy、HAProxy など) 間の通常の HTTP/2 トラフィックはまったく同じです。また、フロントエンドは、認証されていないユーザーおよびアクティビティ プローブをバックエンド HTTP サーバーに再ルーティングするため、プロキシの存在を検出できなくなります。

フロントエンド サーバーには、HTTP Authorization ヘッダーに基づいて HTTP/2 トラフィックをルーティングできる、よく知られたリバース プロキシを使用できます。これにより、プロキシの存在がアクティブに検出されなくなります。既知のものには、forwardproxy プラグインを備えた Caddy や HAProxy などがあります。

現在、主流のプロキシ ツールは TLS に http/1.1 を使用し、NaiveProxy で使用される送信プロトコルは http2 と http3 です。

http2とhttp1の違い

HTTP/1.1 はテキストベースの形式を使用しており、さまざまなテキスト表現やシナリオがあり、堅牢性が不十分です。 HTTP/2 は、0 と 1 の組み合わせのみを使用するバイナリ形式を使用します。バイナリ送信が選択され、プロトコル解析の実装は便利で堅牢です。
HTTP 接続は時間の経過とともに自動的に調整され、最初は接続の最大速度が制限され、データが正常に転送されると時間の経過とともに転送速度が増加します。この調整は TCP スロースタートと呼ばれます。この調整により、バースト的で持続時間が短い HTTP 接続が非常に非効率になります。 HTTP/2 では、TCP 接続を効果的に使用して多重化を通じてすべてのデータ ストリームが同じ接続を使用できるため、高帯域幅が真の意味で HTTP のパフォーマンス向上に役立ちます。
HTTP/2 は、アプリケーション層とトランスポート層の間にバイナリ フレーミングを追加し、HTTP/1.1 のパフォーマンス制限を突破し、送信パフォーマンスを向上させ、低遅延と高スループットを実現します。
HTTP/2 は、HPACK アルゴリズムを使用して各要求接続のヘッダー フィールドを圧縮し、ネットワーク オーバーヘッドを削減します。 HPACK アルゴリズムにより、送信する必要があるヘッダー フィールドのサイズを削減できます。通信する双方の当事者がヘッダー フィールド テーブルを確立し、維持します。フィールド テーブルでは、繰り返される文字列を表すために小さいインデックス番号が使用されます。ハフマン コーディングは、データを圧縮するために使用されます。これにより、ヘッダー フィールドの繰り返しが回避され、送信に必要なサイズも削減されます。

HTTP/2 の主な機能は何ですか?

バイナリフレーム化
HTTP/2 のすべてのパフォーマンス強化の中心には、次の図に示す新しいバイナリ フレーム層があります。これは、他のすべての機能とパフォーマンスの最適化の基盤であり、HTTP メッセージがどのようにカプセル化され、クライアントとサーバー間で送信されるかを定義します。

HTTP/2 は、HTTP のアプリケーション セマンティクスを変更しません。HTTP リクエスト メソッド、ステータス コード、ヘッダー フィールド、その他のルールを引き続き使用し、主に HTTP のメッセージ送信形式を変更します。 HTTP/1.1 プロトコルでは、プレーン テキストの区切り文字として改行が使用されますが、HTTP/2 では、送信されるすべての情報が小さなメッセージとフレームに分割され、バイナリ形式でエンコードされます。これらのフレームは、特定のデータ ストリーム内のメッセージに対応し、すべて多重化されます。 TCP 接続内で。

優先順位付け
HTTP メッセージを多くの独立したフレームに分解することで、複数のデータ ストリームでフレームを再利用することができ、クライアントとサーバーがこれらのフレームの送信と送信をインターリーブする順序が重要なパフォーマンス決定要因になります。 HTTP/2 では、各データ フローに関連付けられた重みと依存関係を持たせることができ、データ フローの依存関係と重みの組み合わせにより、ブラウジング パフォーマンスを向上させるための重要な機能であるリソースの優先順位が明確に表現されます。 HTTP/2 プロトコルを使用すると、クライアントがいつでもこれらの優先順位を更新できるようになり、依存関係を変更したり、ユーザー インタラクションやその他のシグナルに基づいて重みを再分配したりできるため、ブラウザーのパフォーマンスがさらに最適化されます。

ヘッダー圧縮
各 HTTP 要求または応答には、リソース属性を記述するヘッダー情報が含まれます。 HTTP/1.1 ではテキスト形式でメッセージ ヘッダーを送信するため、Cookie をメッセージ ヘッダーに含めるたびに数百から数千バイトを繰り返し送信する必要があり、多くのリソースを消費します。

HTTP/2 では、HPACK アルゴリズムを使用してヘッダー フィールドを圧縮し、送信されるヘッダー フィールドをエンコードしてヘッダー フィールドのサイズを削減します。同時に、出現するヘッダー フィールドを記録するために、インデックス テーブルが両端で維持されます。その後、送信プロセス中に、記録されたヘッダー フィールドのインデックス番号を送信できます。相手側がデータを受信した後、送信することができます。インデックス番号から対応する値を見つけます。

多重化
多重化により、単一の HTTP/2 接続を通じて複数の要求/応答メッセージを同時に開始できるようになり、複数の TCP 接続に依存せずにマルチストリームの並列処理が実現されます。HTTP/2 は、HTTP プロトコル通信の基本単位を 1 つずつフレームに削減します。フレームは論理ストリーム内のメッセージに対応し、メッセージは同じ TCP 接続上で双方向に並行して交換されます。

HTTP/2 はバイナリ フレーミング層に基づいており、共有 TCP 接続に基づいてリクエストと応答を同時に送信できます。 HTTP メッセージは独立したフレームに分解され、メッセージ自体のセマンティクスを破壊することなくインターリーブされて送信され、ストリーム識別子とヘッダーに基づいて相手側で再組み立てされます。多重化技術により、旧バージョンの HTTP のメッセージ ヘッダー ブロッキング問題を回避し、送信パフォーマンスを大幅に向上させることができます。

HTTP/2サーバープッシュ
HTTP 2.0 の強力な新機能は、サーバーがクライアント要求に対して複数の応答を送信できることです。サーバーは、クライアントからの明示的な要求なしでリソースをクライアントにプッシュします。サーバーは事前に複数の応答を返し、クライアントのリクエストに基づいて追加のリソースをクライアントにプッシュします。次の図に示すように、クライアントはストリーム 1 をリクエストし、サーバーはストリーム 1 のメッセージを返しながらストリーム 2 とストリーム 4 をプッシュします。

サーバー プッシュは、クライアントが要求する前にデータを送信するメカニズムです。 HTTP/2 では、サーバーはクライアントのリクエストに対して複数の応答を送信できます。リクエストがホームページから送信された場合、サーバーはクライアントがこれらを使用することを認識しているため、ホームページのコンテンツ、ロゴ、スタイル シートで応答することがあります。これにより、冗長なデータ送信手順が削減されるだけでなく、ページの応答が高速化され、ユーザー エクスペリエンスが向上します。

HTTP3とは何ですか

HTTP/3 は、HTTP プロトコルの 3 番目のメジャー バージョンです。以前の HTTP/1.1 および HTTP/2 とは異なり、HTTP/3 では TCP プロトコルは放棄され、代わりに UDP プロトコルに基づく QUIC プロトコルを使用して実装されます。

この変更は主に、HTTP/2 に存在する行頭ブロックの問題を解決することを目的としています。 HTTP/2 は単一の TCP 接続で多重化を使用するため、TCP 輻輳制御の影響を受け、少量のパケット損失により TCP 接続全体のすべてのフローがブロックされる可能性があります。

QUIC (Quick UDP Internet Connection) は、Google が開発した実験的なネットワーク転送プロトコルで、Web ページの転送を高速化するように設計されています。 2018 年 10 月 28 日のメーリング リストのディスカッションで、インターネット技術特別委員会 (IETF) HTTP および QUIC ワーキング グループの議長であるマーク ノッティンガム氏は、「明確に識別するため、HTTP-over-QUIC の名前を HTTP/3 に変更する」という正式な要求を出しました。それは HTTP セマンティクスの別のバインディングとして...QUIC との違いを人々が理解できるようにするためです。」そして、草案が完成して公開されると、QUIC ワーキング グループは HTTP ワーキング グループから継承されます。 [その後の数日間の議論で、Mark Nottingham の提案は IETF メンバーに受け入れられ、2018 年 11 月に HTTP-over-QUIC を HTTP/3 として正式に承認しました。

2019 年 9 月に、HTTP/3 サポートが Cloudflare と Google Chrome (Canary ビルド) に追加されました。 Firefox Nightly のサポートは 2019 年秋以降に追加される予定です。

2022 年 6 月 6 日、IETF は HTTP/3 を RFC9114 として正式に標準化しました。

http3、udp の quic プロトコルに基づく UDP は「コネクションレス」であり、「ハンドシェイク」や「ウェーブ」をまったく必要としないため、TCP よりも高速です。同時に naiveproxy は Chrome のネットワークスタックを再利用するため、トラフィックの完全な隠蔽を実現し、同時に http3 の高速通信を実現します。

NaiveProxy のセットアップ

もっと身近に、naiveproxy サービスを構築しましょう。naiveproxy は http3 の quic プロトコルを直接有効にします。443 ポートが占有されることを心配する必要はありません。UDP ポートと TCP ポートは競合しません。

NaiveProxy プロジェクトのアドレス:https://github.com/klzgrad/naiveproxy

NaiveProxy の構築手順

• サーバー側にNaiveProxyサーバー(Caddy)を構築する
• NaiveProxy クライアントをローカルに構築する

NaiveProxyを設定する前の準備

NaiveProxy は TLS トラフィックを使用するため、最初にドメイン名を申請し、登録する必要があります。

外部ドメイン名の無料登録: .tk .ml .ga .cf .gq

それから申請してください 暗号化しましょう 無料のTLS証明書。

SSL 証明書ロボットの無料アプリケーション: Certbot は https ドメイン名証明書の自動更新を迅速に申請します

其次是你需要一台独立的云主机，如果你还没有免费的云主机，可以去谷歌云、亚马逊云、微软云进行免费申请。

推奨される使用方法アマゾンクラウド, 毎月 100G のトラフィック、1 年間無料。AWS EC2 Amazonクラウドサーバーを無料で申し込む

Go言語をインストールする

Go公式Webサイトのダウンロードアドレス：https://go.dev/dl/

Go 言語のインストールチュートリアル:Go言語のインストールとGo言語開発環境の構築

インストールする前に、まず使用してください lscpu サーバーの CPU アーキテクチャを確認してください。

Intel と AMD のメーカーは X86 アーキテクチャに基づく CPU を使用していますX86 アーキテクチャは複雑な命令セットを使用します。つまり、命令は 1 ステップで完了しますが、アームは単純化された命令セットを使用します。つまり、命令は複数の命令で完了します。
X86 アーキテクチャはパフォーマンスに優れていますが、消費電力と電圧が高く、主にデスクトップやサーバーに使用されます。
ただし、ARM アーキテクチャは消費電力と電圧が低いものの、シングルコアのパフォーマンスは X86 ほど良くなく、主にモバイル デバイスで使用されます。
近年、X86 アーキテクチャはゆっくりと発展しましたが、ARM アーキテクチャは大幅に進歩し、モバイル デバイスからデスクトップ コンピュータやサーバー (m1 チップなど) に移行しました。

Arm アーキテクチャ CPU: https://go.dev/dl/go1.19.2.linux-arm64.tar.gz

x86 アーキテクチャ CPU: https://go.dev/dl/go1.19.2.linux-amd64.tar.gz

go 言語インストール パッケージをサーバーにダウンロードし、次の場所に解凍します。 /usr/ローカル/ ディレクトリ内にあります。

wget https://go.dev/dl/go1.19.linux-amd64.tar.gz tar -zxvf go1.19.linux-amd64.tar.gz -C /usr/local/

Go言語はインストール不要で解凍できます。 /etc/プロファイル ファイルに変数を追加します。

echo import PATH=$PATH:/usr/local/go/bin >> /etc/profile ソース /etc/profile go version

インストール後に使用する 行くバージョン インストールが成功したかどうかを確認するコマンド

GO 言語のバージョンが正常に表示されればインストールは成功です。

NaïveProxy と Caddy をインストールする

Naiveproxy は Web サービス プロキシ ツールであり、VPN とは本質的に異なります。Naiveproxy はフォワード プロキシ サーバーと併用する必要がありますが、caddy は自動 TLS 機能を備えた HTTPS サーバーです。

以下のインストールコマンドを実行します インストール前に、サーバーからgithubまでのネットワークがスムーズであることを確認する必要があります。コンパイルにはある程度の時間がかかり、サーバーの CPU パフォーマンスが重要となるため、しばらくお待ちください。

注: forwardproxy はサードパーティのプラグインであり、caddy 自体には含まれていません。以下は、forwardproxy と naive を統合した caddy です。

必ず forwardproxy および naive プラグインを使用して caddy をインストールしてください。それ以外の場合は、これら 2 つの caddy プラグインを個別にインストールする必要があります。

インストール後も使用可能キャディ リスト モジュール | grep forward_proxy表示するコマンド。

xcaddy プロジェクトのアドレス:https://github.com/caddyserver/xcaddy

go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest ~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy@caddy2=github.com/klzgrad/forwardproxy@naive cp caddy /usr/ bin/ /usr/bin/caddy version setcap cap_net_bind_service=+ep /usr/bin/caddy # は setcap コマンドを使用して /usr/bin/caddy を設定します。非 ROOT ユーザーは 1024 未満のポートを開始できます。

注: このコマンドを使用できます。 setcap -r /usr/bin/caddy 追加の権限をクリアします。

コンパイルが完了したら、caddy フォルダーを /usr/bin ディレクトリにコピーし、コンパイルが成功したかどうかを確認します。バージョン番号が表示されればコンパイルは成功です。

BBRアクセラレーションモジュールの最適化

新しいバージョンの Linux システムには BBR アクセラレーション モジュールが付属しているため、次のコマンドを直接実行して元の BBR アクセラレーションを有効にすることができます。コマンドは次のとおりです。

bash -c 'echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf' bash -c 'echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf' sysctl -p

キャディの構成

上記をインストールしたら、次にキャディを設定します

まず、ドメイン名 A レコードを、それが配置されているサーバーの IP アドレスに解決します。次に、SSL ドメイン名証明書を申請します。

# Caddyfile mkdir /etc/caddy/ を保存する新しいディレクトリを作成します。 # VI コマンドを使用して、/etc/caddy/ ディレクトリに新しい Caddyfile 構成ファイル vi /etc/caddy/Caddyfile を作成します。

強力なパスワードを生成するには、次のコマンドを入力して、サーバー上に強力なパスワードの文字列を自動的に生成します。

cat /dev/urandom | tr -dc a-zA-Z0-9 | head -c32; echo;

以下のテンプレートを使用して、次の変更を加えます。

• yourname を NaiveProxy 認証用に選択したユーザー名に置き換えます。
• パスを生成された強力なパスワードに置き換えるか、カスタム パスワードを作成します。
• example.com をドメイン名とホスト名に置き換えます。
• Let's Encrypt の通知を受信するには、youremail@example.com を実際のメール アドレスに置き換えます。

Caddy では、サーバー上にプロキシ Web サイトを構築する方法が 2 つあり、1 つは Web サイトのファイルをサーバーに保存する方法、もう 1 つは他の Web サイトにリバース プロキシする方法です。

Naive のマルチユーザー バージョンを作成する場合は、forward_proxy モジュールをコピーできます。 Basic_auth のユーザーパスワードを別のパスワードに変更するだけです。

サーバー上に新しい Web サイトを作成します。

:443、example.com tls youremail@example.com ルート { forward_proxy { Basic_auth あなたの名前 パス Hide_ip Hide_via Probe_resistance } file_server { root /var/www/html } }

他の Web サイト アドレスへのリバース プロキシ ドメイン名:

:443、example.com tls youremail@example.com ルート { forward_proxy { Basic_auth yourname pass Hide_ip Hide_via Probe_resistance } reverse_proxy https://example2.com { header_up Host {upstream_hostport} } }

キャディの公式リバース プロキシ ドキュメント:https://caddyserver.com/docs/caddyfile/directives/reverse_proxy

ドメイン名 SSL 証明書を構成するには、いくつかの方法があります。

1. 証明書発行者への手動申請
   証明書発行者から証明書を手動で申請し、Caddy 構成で証明書とキー ファイルのパスを指定します。
   tls /path/example.com.crt /path/example.com.key
2. ホスト自動適用方法
   ターゲット ドメイン名 (例: example.com) がローカル マシンに解決されている場合、Caddy2 は起動後に ACME HTTP 経由で証明書を自動的に申請しようとします (デフォルトの証明書発行者は let's encrypt です)。
   利点: シンプルな構成、
   構文は次のとおりです。次の電子メール パラメーターは、申請者の電子メール アドレスを CA に通知するためのものです。
   TLSメール
3. DNS自動適用方法
   Let's encrypt は、ドメイン名サービス プロバイダーが提供するドメイン名解決レコード API を使用して、ドメイン名の所有権を確認します。
   利点: パブリック IP アドレスは必要なく、DNS 解決レコードを通じて検証を完了できます。さらに、Web サイトで CDN が有効になっている場合は、この方法を使用する必要があります。
   短所: 設定が面倒で、いくつかの環境変数を設定する必要があり、また、DNS サービス プロバイダーに対応するプラグインをダウンロードする必要があります (プラグインにより、DNS サービス プロバイダー API を呼び出すキャディのプロセスが簡素化されます)。キャディファイルの構文:
   TLS {
   
   }

設定ファイルを変更した後、キャディを起動します。キャディを開始する前に、まず設定ファイルをフォーマットする必要があります。フォーマットしないとエラーが報告されます。 caddy fmt –「/etc/caddy/Caddyfile」を上書きします 注文

# フォーマット設定ファイル caddy fmt --overwrite /etc/caddy/Caddyfile # 開始設定ファイル caddy run --config /etc/caddy/Caddyfile

ブラウザにドメイン名を入力するとWebサイトが正常に開くようになり、キャディが正常に起動したら、次に自己起動ファイルを設定し、再起動してサーバーを再起動します。

キャディ構成デーモン (起動時に自動的に開始):https://github.com/klzgrad/naiveproxy/wiki/Run-Caddy-as-a-daemon

共通コマンド

# バックグラウンドでキャディを開始 caddy start --config /etc/caddy/Caddyfile # フロントエンドでキャディを開始 caddy run --config /etc/caddy/Caddyfile # キャディを停止 stop # 設定ファイルをリロード caddy reload --config / etc/ caddy/Caddyfile # CA 証明書をローカル ディレクトリにインストールします caddy trust # Caddyfile をフォーマットします caddy fmt --overwrite /etc/caddy/Caddyfile # 標準 Caddyfile を json 形式の同等の設定ファイルに変換します この設定ファイルは通常は使用されませんcaddyadapt --config /etc/caddy/Caddyfile --pretty

サーバー接続が成功したら、自動開始構成ファイルを手動で作成します。キャディを開始するコマンドを使用しないように注意してください。

vi /etc/systemd/system/naive.service

以下を貼り付けます ナイーブサービス ファイル後 :wq 保存して vi 編集モードを終了します。

[ユニット] 説明=Caddy ドキュメント=https://caddyserver.com/docs/ 後=network.target network-online.target Requires=network-online.target [サービス] Type=notify User=root Group=root ExecStart=/ usr/bin/caddy run --environ --config /etc/caddy/Caddyfile ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile TimeoutStopSec=5s LimitNOFILE=1048576 LimitNPROC=512 PrivateTmp=true ProtectSystem= full AmbientCapabilities=CAP_NET_BIND_SERVICE [インストール] WantedBy=multi-user.target

起動ファイルが作成されたら、キャディを起動します。

#daemon-reload 新しいユニット構成ファイルをロードします。 systemctl daemon-reload #enable はユニット構成ファイルのソフト リンクを作成します。 systemctl enable naive #start 構成ファイルを開始します。 systemctl start naive #status 構成ファイルの現在のステータスを確認します。 systemctl status naive

お気に入りの設定ファイルの現在のステータスを確認します。緑色のライトは、キャディが正常に開始されたことを示します。

Caddy がポート 80 および 443 でリッスンしているかどうかを確認します。

ss -tulpn | grep キャディ

これを行うには、PC で Google Chrome を開いてコンソールにアクセスします。例: https://www.example.com

この時点で Naive は構成されています。別の Naive 構成ファイルを試したい場合は、次の JSON メソッドを使用して Naive 構成ファイルをカスタマイズすることもできます。

Jsonカスタム構成ファイル

公式を見るJSON 構成構造

Caddyfile 構成ファイルを作成するだけでなく、Caddyfile 構成ファイルを json ファイルに変換することもできます。変換された json ファイルは、一時的なテストに使用したり、naive.service ファイル内のパスを変更することで永続的な構成ファイルとして使用したりできます。以下にカスタムjson設定ファイルを掲載していますので、テストしたい方はテストにご利用ください。

# /etc/caddy/caddy_server.json { "admin": { "disabled": true }, "apps": { "http": { "servers": { "srv0": { "listen": [ ":443 " ], "ルート": [ { "ハンドル": [ { "ハンドラー": "サルート", "ルート": [ { "ハンドル": [ { "auth_user_deprecated": "ユーザー名", "auth_pass_deprecated": "パスワード " , "handler": "forward_proxy", "hide_ip": true, "hide_via": true, "probe_resistance": {} } ] }, { "match": [ { "host": [ "ドメイン名" ] } ] , "handle": [ { "handler": "file_server", "root": "/var/www", "index_names": [ "index.html" ] } ], "terminal": true } ] } ] } ], "tls_connection_policies": [ { "match": { "sni": [ "ドメイン名" ] } } ], "automatic_https": { "disable": true } } } }, "tls": { "証明書" : { "load_files": [ { "certificate": "/etc/letsencrypt/live/ドメイン名/fullchain.pem", "key": "/etc/letsencrypt/live/ドメイン名/privkey.pem" } ] } } } }

また、構成ファイルを実行する前に事前にフォーマットする必要があります。そうしないと、エラーが報告されます。

#形式設定ファイル caddy fmt --overwrite "/etc/caddy/caddy_server.json" caddy run --config "/etc/caddy/caddy_server.json"

NaiveProxy クライアントを構成する

NaiveProxy によって提供される公式クライアントに加えて、Q2ray など、インターネット上で NaiveProxy をサポートするサードパーティ クライアントが多数あります。

NaiveProxy 公式クライアント

Naive クライアントは、Windows、Linux、Mac、Android などを幅広くサポートしています。最も重要なことは、Openwrt をサポートしており、クライアントをルーターに組み込むことができることです。

Naive クライアントのダウンロード アドレス:https://github.com/klzgrad/naiveproxy/releases

Windows プラットフォームのクライアント構成と接続速度を見てみましょう。

Windows バージョンのクライアントをダウンロードし、解凍して開きます。 config.json 書類。

config.json このファイルは非常に単純で、コードが 5 行と括弧が 2 行だけです。

• Listen は変更する必要はありません。本機のプロキシポートはデフォルトで 1080 です。 127.0.0.1 を 0.0.0.0 に変更することもできます
• proxy は、上で設定したサーバーのユーザー パスワードとドメイン名です。 HTTP3 を使用する場合は、https:// を quic:// に変更します。
• log ログ ファイル。入力する必要はありません。変更された行を削除すると、クライアントの DOS ウィンドウにログが表示されなくなります。

NaiveProxy クライアントの開始後、Google Chrome ブラウザを使用して通常にアクセスできるようにするには、socks5 ネットワーク プロキシを構成する必要があります。

こちらはGoogle ChromeプラグインSwitchyOmegaです！

プロキシ SwitchyOmega

SwitchyOmegaとは

Proxy SwitchyOmega を使用すると、複数のプロキシ設定を簡単かつ迅速に管理および切り替えることができます。 Google Chrome App Store で SwitchyOmega を検索し、オンラインで直接インストールします。インストール パッケージをダウンロードし、代替ダウンロード アドレスから Chrome 拡張機能アプリケーションをオフラインでインストールすることもできます。
プロキシ SwitchyOmega の代替ダウンロード アドレス: https://github.com/FelisCatus/SwitchyOmega/releases

• Chromium または Chromium ベースのブラウザを使用している場合: Chrome App Store からインストールしてください。
• Mozilla Firefox またはその他の Mozilla ベースのブラウザーのユーザー: Mozilla アドオンからインストールしてください。

この拡張機能は SwitchySharp のアップグレード バージョンであり、SwitchyPlus または Proxy Switchy を置き換えることができます。SwitchyOmega が最初にインストールされると、SwitchySharp が存在するかどうかがチェックされ、存在する場合は、手動で構成することなく設定が自動的にアップグレードされます。 Google Play ストア以外のバージョンを使用している場合、または自動的にアップグレードできない場合は、SwitchySharp で設定ファイルを手動でエクスポートし、それを SwitchyOmega にインポートして、互換性のある構成を実現できます。 SwitchyOmega にアップグレードした後は、SwitchySharp を無効にしてください。

ご質問がある場合は、アイコンを [右クリック] してメニューの [フィードバックの問題] を選択してください。開発者が時間内に問題を解決できるようになります。

バージョン 2.x の新機能:
* アンロードされた要素を自動的に検出し、ポップアップ メニューから 1 回クリックするだけでプロキシ設定を有効にします。
* ユーザー名とパスワードの検証を必要とするプロキシ サーバーをサポートします。
* より柔軟なエージェント構成: エージェント シナリオ モード、複数の自動切り替えモード、および複数のルール リスト。
* 多彩な切り替え条件の種類を追加し、オリジナルの切り替え条件を改善しました。
* PAC スクリプトの生成と切り替えのパフォーマンスの最適化。
* ユーザー エクスペリエンスを向上させるための新しいオプション ページとドロップダウン メニュー。
* 多くのバグ修正と改善。より完全にテストしてください。

特別な注意事項: Chrome の制限により、同時にプロキシ設定を制御できる拡張機能は 1 つだけです。通常、Chrome は後でインストールされた拡張機能を優先します。競合中に SwitchyOmega が優先権を獲得した場合、「システム プロキシ」モードに切り替えて他の拡張機能に優先権を返し、問題を解決できます。この拡張機能の設定が他のプロキシ関連または広告関連の拡張機能によって上書きされた場合、問題は解決できず、優先順位を上げる唯一の方法は SwitchyOmega を再インストールすることです。

Google Chrome ブラウザ SOCKS5 プロキシを介したアクセスは非常に高速です。以下では、Google Cloud Test によって構築された Naive サービスを使用しています。速度テスト Web サイトでは、ダウンロードとアップロードの速度が理想的です。個人のプライバシー保護の観点から、設定が簡単な公式クライアントのご利用をお勧めします。他のサードパーティ クライアントが適切に構成されていない場合、ローカル オペレータのネットワーク スロットリング メカニズムがトリガーされる可能性があります。

Naive クライアント + Google Chrome + SwitchyOmega ブラウザ プラグインで、ついにインターネットへのプロキシ アクセスが実現しました。クライアントの設定が少し面倒な気がします。どの程度隠せるか、個人のプライバシーを保護できるかは人それぞれです。

声明: この記事は、インターネット技術の経験を交換するためにのみ使用されます。記事のすべてのコンテンツはインターネットからのものです。このサイトは技術記事のみを収集および整理します。法律に違反することなく、個人のプライバシーを可能な限り保護します。危険を冒してネットワーク プロキシ テクノロジを使用して違法な活動を行わないでください。インターネット上のほとんどすべての活動は透過的に行われます。