統合・プロトコル
HTTP、HTTPS、SOCKS5、およびゲートウェイがそれぞれで何を行うのか。
標準プロトコル、カスタム クライアントなし。このページは、通信上で何が起こっているかを知る必要がある人のための正確な行動です。
チートシート#
| ターゲット | クライアントのプロキシ URL | 港 |
|---|---|---|
http:// そして https:// URL | http://USER:PASS@res.proxy-cyber.com:9000 | 9000 |
| TCP 経由のすべて、出口でホスト名が解決される | Socks5h://USER:PASS@res.proxy-cyber.com:9001 | 9001 |
| 同じ、マシンによって解決されたホスト名 | Socks5://USER:PASS@res.proxy-cyber.com:9001 | 9001 |
| 専用アドレス、HTTP(S) | http://USER:PASS@203.0.113.42:8000 | 8000 |
| 専用アドレス、SOCKS5 | 靴下5h://USER:PASS@203.0.113.42:8001 | 8001 |
HTTP#
平野の場合 http:// クライアントが絶対 URI と Proxy-Authorization ゲートウェイはそのヘッダーを取り除き、出口を介して要求を中継し、応答をストリーミングして戻します。キープアライブを備えた HTTP/1.1 がサポートされています。キープアライブ接続は終了を維持します (「 回転).
HTTPS#
のために https:// クライアントが送信するターゲット CONNECT host:443 そしてゲートウェイは出口から生のトンネルを開きます。 TLS ハンドシェイクは、そのトンネルを介してクライアントとターゲットの間で行われます。ゲートウェイは何も復号化、検査、または再署名することはなく、検証する証明書はターゲットのものです。トンネル内でネゴシエートされる HTTP/2 および HTTP/3-over-TCP フォールバックは、直接動作する場合と同様に機能します。
ソックス5#
- ユーザー名/パスワード認証を伴う RFC 1928 (RFC 1929)、またはホワイトリストに登録されたアドレスからの認証なし。
CONNECT25 を除く任意の TCP ポートに送信します。BINDそしてUDP ASSOCIATEはサポートされていません。UDP も受信接続もありません。- ホスト名 (アドレス タイプ 0x03) を送信して、出口がそれを解決するようにします。
socks5h://は、curl、Python、および Node を意味します。クライアントがローカルで解決して IP を送信する場合、リクエストは引き続き機能しますが、DNS ルックアップはユーザー側で行われます。 - 非 HTTP TCP プロトコルおよび SOCKS のみを使用するクライアントの場合は、SOCKS5 を選択します。 Web トラフィックの場合、HTTP ポートは同等です。
ヘッダー#
ゲートウェイは削除します Proxy-Authorization そして Proxy-Connection そして何も追加しません: いいえ Via、いいえ X-Forwarded-For、いいえ X-Real-IP。ターゲットが受信するのは、出口デバイスが送信するリクエストと同じであり、これがネットワークのポイントです。セット User-Agent, Accept-Language 残りは出口の国に合わせてください。
サポートされていません#
- 任意の形式の UDP (プロキシが構成されている場合、QUIC はすべてのブラウザで TCP にフォールバックします)。
- IPv6 ターゲット: 出口は IPv4 です。
- プロキシ ポート自体への TLS (
https://として プロキシ スキーム）。ゲートウェイへのホップは単純です。参照してください エンドポイント. - FTP、ポート 25 の SMTP、およびプロキシが接続を開く必要があるプロトコル。