HTTP・SOCKS・透過プロキシ・UDP - 版の履歴

Turgenev: Notion-MW

2025-10-02T06:08:55Z

Notion-MW

Turgenev: Notion-MW

2025-09-01T01:31:47Z

Notion-MW

← 古い版		2025年9月1日 (月) 10:31時点における版
53行目:		53行目:
	== SNI Proxy ==		== SNI Proxy ==

	HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI ~~Proxyと呼ぶことがあるらしい。~~<strong>Nginx</strong>や<strong>HAProxy</strong>~~のような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。~~		HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。ドメイン→IPを決め打ちする場合は多くのソフトウェアでできそうだが、任意ドメインに対してDNSで解決しつつ振り分けるのは対応していない場合もある。gostはこれにも対応している。<strong>Nginx</strong>は対応しているが、ngx_stream_ssl_preread_moduleとかが必要なので、環境によっては動かしづらいかもしれない。<strong>HAProxy</strong>は自分が試した限りでは動かせなかった。これらの汎用のプロキシサーバーの他に、これを専門とするソフトウェアもある。

	* ~~こんな使い方もある（自分の記事）→~~ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]		* Nginxでの使用例（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]とか[https://turgenev.hatenablog.com/entry/2025/04/27/215220 【広告ブロックDNS】特定ドメインへのTCP接続を途中で切断してAd-Shield対策 - turgenev’s blog]

	<span id="dlundquistsniproxy"></span>		<span id="dlundquistsniproxy"></span>
87行目:		87行目:

	企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。		企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

			Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。

	Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。		Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。
106行目:		108行目:

	経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。		経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

			* このツールでは、DNSリクエストを解釈してサーバー側（サーバー側から見えている外部のDNSを指定してもよい）で解決を行う機能も実装してある。この機能は”fake dns”と名付けているが、shadowsocks-rustのfake dnsやtun2proxyのvirtual dnsはこれとは異なる機能のようである。

	==== 3proxy ====		==== 3proxy ====
291行目:		295行目:

	典型的な設定例として、localhostやプライベートIPへのアクセスを制限する設定をSquid・Dante・3proxyそれぞれに関して紹介しておく。		典型的な設定例として、localhostやプライベートIPへのアクセスを制限する設定をSquid・Dante・3proxyそれぞれに関して紹介しておく。

			プロキシ側で設定せず、cgroupなどを使ってファイアウォール側で制御する方法もある。

	==== squid ====		==== squid ====

Turgenev: Notion-MW

2025-06-03T13:39:53Z

Notion-MW

@@ 180行目: / 180行目: @@
 同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。
 <span id="透過socksプロキシクライアント"></span>
@@ 192行目: / 186行目: @@
 [https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。
-バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。
+バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。VPNと同等の動作で、基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。
 以下のいずれも、ドメイン解決にはプロキシが適用されない（Linux向けの2つはできなくはないかもしれないが、しづらい）ことに注意。
@@ 215行目: / 209行目: @@
 [https://www.proxifier.com/ https&#58;//www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。
 == ライブラリ関数ハック系 ==
@@ 397行目: / 410行目: @@
 * txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
 * things&#45;go/go&#45;socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。
 == プロキシプロトコル間の変換 ==

Turgenev: Notion-MW

2025-05-05T01:30:21Z

Notion-MW

差分を表示

Turgenev: Notion-MW

2025-04-02T15:42:26Z

Notion-MW

← 古い版		2025年4月3日 (木) 00:42時点における版
79行目:		79行目:
	== SOCKSプロキシサーバー ==		== SOCKSプロキシサーバー ==

	~~ここにあげたものは特に注記がなければUDPに対応している。~~		ここにあげたものは特に注記がなければUDP（ただし筆者が念頭に置いているのはAssociateのみで、Bindに関してはほぼ調べていない）に対応している。

	<span id="dante"></span>		<span id="dante"></span>
274行目:		274行目:
	<span id="socks関連の話題"></span>		<span id="socks関連の話題"></span>
	== SOCKS関連の話題 ==		== SOCKS関連の話題 ==

			<span id="natが介在する場合などのudp-associateの動作"></span>
			==== NATが介在する場合などのUDP Associateの動作 ====

			OpenSSHの項目でも関連することを述べたが、UDP-over-TCPの性能劣化を避けるため、UDP Associateは「サーバー側がクライアント側に対してUDP通信で使うための中継ポートを通知する」という動作を伴う。この際、ネットワーク上でクライアント側からサーバーが直接見えていればよいが、NATを介している場合、クライアントから見たときのサーバーのIPとサーバー自身から見たときのサーバーのIP（中継ポート通知に含まれるのはこれ）が異なることがあり、通信が成立しなくなってしまう（SSHのポート転送を普通に使うだけではUDP Associateが使えないのも直接にはこれが原因）。

			ただし、[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]にも書いた通り、Proxifyreやhev-socks5-tproxyなどは中継ポート通知のIP部分を無視するため、ポート番号が変わらないNATであれば問題なく動作する（redsocksはダメ）。

	<span id="socks5によるドメイン解決"></span>		<span id="socks5によるドメイン解決"></span>
280行目:		287行目:
	SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。		SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

	Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/~~2025~~/03/25/~~171736 squidで透過プロキシ（intercept, tproxy）を動かす~~ - turgenev’s blog]）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。		Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。

	なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。		なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。

Turgenev: Notion-MW

2025-04-02T15:29:11Z

Notion-MW

← 古い版		2025年4月3日 (木) 00:29時点における版
78行目:		78行目:
	<span id="socksプロキシサーバー"></span>		<span id="socksプロキシサーバー"></span>
	== SOCKSプロキシサーバー ==		== SOCKSプロキシサーバー ==

			ここにあげたものは特に注記がなければUDPに対応している。

	<span id="dante"></span>		<span id="dante"></span>
101行目:		103行目:
	[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]		[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

	TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。		これ自体はSOCKS5サーバーではなく、TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

	経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。		経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。
111行目:		113行目:
	[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]		[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

	~~ロシア系。エラーメッセージなどがかなり不親切だが、ちゃんと動くソフト。~~		ロシア系。SOCKS・HTTP・POP3・SMTPなどいくつかのプロキシを含む。エラーメッセージなどがかなり不親切だが、結構多機能で、ちゃんと動くソフト。<code>3proxy</code>というメインの実行ファイルとあわせて、各プロキシに対応した<code>socks</code>や<code>proxy</code>といった検索性の低い名前の実行ファイルがいくつか含まれているちょっと謎の構成。

	==== fast-socks5 ====		==== fast-socks5 ====
272行目:		274行目:
	<span id="socks関連の話題"></span>		<span id="socks関連の話題"></span>
	== SOCKS関連の話題 ==		== SOCKS関連の話題 ==

			<span id="socks5によるドメイン解決"></span>
			==== SOCKS5によるドメイン解決 ====

			SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

			Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。

			なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。

			* 拡張機能などではうまく動作しない場合がある模様。 [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]

	<span id="ブラウザのsocks5プロキシのwebrtc対応"></span>		<span id="ブラウザのsocks5プロキシのwebrtc対応"></span>

Turgenev: Notion-MW

2025-04-02T08:28:25Z

Notion-MW

← 古い版		2025年4月2日 (水) 17:28時点における版
272行目:		272行目:
	<span id="socks関連の話題"></span>		<span id="socks関連の話題"></span>
	== SOCKS関連の話題 ==		== SOCKS関連の話題 ==

	~~<span id="socks5によるドメイン解決"></span>~~
	~~==== SOCKS5によるドメイン解決 ====~~

	SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

	Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]）。一方、Webブラウザなどでは、この機能が使われる場合がある（参照: [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]、[https://stackoverflow.com/questions/33099569/how-does-sock-5-proxy-ing-of-dns-work-in-browsers How does SOCK 5 proxy-ing of DNS work in browsers?]）。

	<span id="ブラウザのsocks5プロキシのwebrtc対応"></span>		<span id="ブラウザのsocks5プロキシのwebrtc対応"></span>

Turgenev: Notion-MW

2025-04-02T08:04:44Z

Notion-MW

← 古い版		2025年4月2日 (水) 17:04時点における版
272行目:		272行目:
	<span id="socks関連の話題"></span>		<span id="socks関連の話題"></span>
	== SOCKS関連の話題 ==		== SOCKS関連の話題 ==

			<span id="socks5によるドメイン解決"></span>
			==== SOCKS5によるドメイン解決 ====

			SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

			Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]）。一方、Webブラウザなどでは、この機能が使われる場合がある（参照: [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]、[https://stackoverflow.com/questions/33099569/how-does-sock-5-proxy-ing-of-dns-work-in-browsers How does SOCK 5 proxy-ing of DNS work in browsers?]）。

	<span id="ブラウザのsocks5プロキシのwebrtc対応"></span>		<span id="ブラウザのsocks5プロキシのwebrtc対応"></span>

Turgenev: Notion-MW

2025-04-02T07:02:55Z

Notion-MW

← 古い版		2025年4月2日 (水) 16:02時点における版
1行目:		1行目:
			SOCKS・透過プロキシ・UDP-over-TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

	近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。		近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。

35行目:		37行目:
	==== shadowsocks ====		==== shadowsocks ====

	~~shadowsocksはSOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。~~[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。		SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

	~~VPN以外だとこれが現在主流と思われる。~~		VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

	サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。		サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。
53行目:		55行目:
	HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。<strong>Nginx</strong>や<strong>HAProxy</strong>のような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。		HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。<strong>Nginx</strong>や<strong>HAProxy</strong>のような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。

	* ~~こんな使い方もある→~~ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 ~~-~~ turgenev’s blog]		* こんな使い方もある（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]

	<span id="dlundquistsniproxy"></span>		<span id="dlundquistsniproxy"></span>
80行目:		82行目:
	==== Dante ====		==== Dante ====

	[https://www.inet.no/dante/index.html ~~https://www.inet.no/dante/index.html~~]		[https://www.inet.no/dante/index.html Dante - A free SOCKS server]

	企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。		企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。
100行目:		102行目:

	TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。		TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

			経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

	==== 3proxy ====		==== 3proxy ====

	[https://~~github~~.~~com/3proxy~~/3proxy https://github.com/3proxy/3proxy~~] [~~https://~~3proxy~~.~~ru/ https:~~//3proxy~~.ru/~~]		[https://3proxy.ru/ 3proxy tiny free proxy server for Windows, Linux, Unix: SOCKS, HTTP, FTP proxy]

			[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

	ロシア系。エラーメッセージなどがかなり不親切だが、ちゃんと動くソフト。		ロシア系。エラーメッセージなどがかなり不親切だが、ちゃんと動くソフト。
181行目:		187行目:
	<span id="透過socksプロキシクライアント"></span>		<span id="透過socksプロキシクライアント"></span>
	== 透過SOCKSプロキシクライアント ==		== 透過SOCKSプロキシクライアント ==

			[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。

	バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（最低でもCAP_NET_ADMIN）が必要。		バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（最低でもCAP_NET_ADMIN）が必要。
188行目:		196行目:
	[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）		[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

	*~~nix対応~~		*nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。

	<span id="proxifyre"></span>		<span id="proxifyre"></span>
216行目:		224行目:

	後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。		後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。

			<syntaxhighlight lang="go">route {
			from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.1 port = 1080
			}</syntaxhighlight>
			こんな感じの<code>/etc/socks.conf</code>を作るか、<code>SOCKS5_SERVER=192.168.1.1:1080 socksify curl http://ipv4.icanhazip.com</code> とかでもよい。

			Macでも動くはずだが、筆者が唯一試したMac環境ではcurlに対してさえうまく動作しなかった（socksifyを使わないのと全く同様に動作するだけだった）（<code>DYLD_FORCE_FLAT_NAMESPACE=1</code>は指定している）。

	<span id="proxychains-ngproxychains"></span>		<span id="proxychains-ngproxychains"></span>
251行目:		266行目:
	== HTTPプロキシ ==		== HTTPプロキシ ==

	Squid, ~~Privoxyなどが有名~~		Squid, Privoxyなどが有名。

			Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。

	<span id="socks関連の話題"></span>		<span id="socks関連の話題"></span>
259行目:		276行目:
	==== ブラウザのSOCKS5プロキシのWebRTC対応 ====		==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

	基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。		基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。これは原理的に実装が不可能なわけではなく、単に需要が少ないから実装されていないだけである。

			* Chromeではどれが最新か不明（最近の物は少ない）。このへんとか？[https://issues.chromium.org/issues/41180783 Chromium]
	* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]		* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]
	* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]		* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]
	** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]		** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]
	** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]		** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]

			従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことになる。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。

	<span id="udp-associateリクエストのdstaddrとdstport"></span>		<span id="udp-associateリクエストのdstaddrとdstport"></span>

Turgenev: Notion-MW

2025-03-28T12:59:00Z

Notion-MW

新規ページ

近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。


== 大規模・多機能系 ==

以下のものは機能が多くて分類できないのでソフトウェアごとに紹介する。

==== gost ====

GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost https://github.com/ginuerzh/gost], [https://v2.gost.run/ https://v2.gost.run/]）と開発中のv3系（[https://github.com/go-gost https://github.com/go-gost], [https://gost.run/ https://gost.run/]）で大きく仕様が異なる。v3は開発中と言いつつv2系のページを見るとかなりv3推しに見える。

starはバージョン2が16k、バージョン3が5kほど。

イメージとしては、TCPによるシンプルなトンネルプロトコル（これがgost）（暗号化無し）と他の大量のプロトコルの間の相互変換を実装しているような感じと思われる。

非常に多機能で、このページで紹介している多くソフトウェアの基本機能をカバーしていると言ってもいいくらい。UDP-over-TCP系は基本これ1つで十分。機能の豊富さに比して明らかにドキュメントが不足しており、エラーメッセージも親切ではない（起動時ではなく実際にパケットが来てからエラーが出るような感じ）。

<ul>
<li>connectorとしてはsocks5も用意されているが、相手がgostでない限りUDP Associateは動かない模様。具体的には
<syntaxhighlight lang="javascript">gost -L "auto://:8480?udp=true&relay=udp" -F socks5://192.168.1.13:3129</syntaxhighlight>
などとしても、 05f3 0001 0000 0000 0000みたいなよくわからんリクエストが送られてしまう。このf3のところは下記の独自拡張っぽい。
[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17]</li></ul>

==== go-proxy ====

[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]

これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。


== GFW回避 ==

中国政府の検閲システムであるグレート・ファイアウォール（GFW）に対抗することを主な目的とするもの。

==== shadowsocks ====

shadowsocksはSOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

VPN以外だとこれが現在主流と思われる。

サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。


==== Hysteria ====

通信路がHTTP/3に偽装した形で暗号化される。shadowsocksの次世代に位置付けられるソフトウェアのように見える。

SOCKS5サーバー部分にはtxthinking/socks5を使っている。


== SNI Proxy ==

HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。NginxやHAProxyのような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。

* こんな使い方もある→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]


==== dlundquist/sniproxy ====

[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。

==== tcpproxy ====

[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。


==== ameshkov/sniproxy ====

[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。


==== puxxustc/sniproxy ====

[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。


== SOCKSプロキシサーバー ==


==== Dante ====

[https://www.inet.no/dante/index.html https://www.inet.no/dante/index.html]

企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。


==== OpenSSH ====

現実的に最もよく使われているSOCKSサーバーは間違いなくOpenSSHだろう。しかし、UDP-over-TCPの問題があるため、UDPはサポートされていない。

ssh -Dでforward方向のプロキシを建てるのが有名だが、OpenSSH 7.6からは-Rでreverse方向にも建てられるようになった。クライアント側が7.6以上であればよい。

* 参考: [https://www.openssh.com/txt/release-7.6 OpenSSH 7.6] （<code>ssh(1): add support for reverse dynamic forwarding</code>）

==== socks-with-udp-over-ssh ====

[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

==== 3proxy ====

[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy] [https://3proxy.ru/ https://3proxy.ru/]

ロシア系。エラーメッセージなどがかなり不親切だが、ちゃんと動くソフト。

==== fast-socks5 ====

[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし


==== txthinking/socks5 ====

[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]

starは700前後。hysteriaやtrojan-goなどいくつかの大きなプロジェクトで使われており、go製のSOCKS5関連ライブラリでは一番メジャーか。

クライアントもある。

自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した


==== armon/go-socks5 ====

[https://github.com/armon/go-socks5 https://github.com/armon/go-socks5]

starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。

ここからフォークされたものが複数ある。


==== things-go/go-socks5 ====

[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]

armon/go-socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 https://github.com/things-go/go-socks5/pull/63]）。

Wireproxyで使われている。

自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した


==== haxii/socks5 ====

[https://github.com/haxii/socks5 https://github.com/haxii/socks5]

armon/go-socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。


==== wzshiming/socks5 ====

[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]

クライアントもある。

starは90個ほど。最終更新2024年。

とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。

Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


==== haochen233/socks5 ====

[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]

クライアントもある。

UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。

同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。

=== tun系 ===

==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]


== 透過SOCKSプロキシクライアント ==

バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（最低でもCAP_NET_ADMIN）が必要。

==== redsocks ====

[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

*nix対応


==== ProxiFyre ====

[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。

==== hev-socks5-tproxy ====

[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。


==== Proxifier ====

[https://www.proxifier.com/ https://www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。

== ライブラリ関数ハック系 ==

ライブラリ関数レベルでの置き換えになるため厳密性・安定性に欠ける（異常終了する場合もある）ものの、root権限がない場合に有効な手法。


=== Linux（LD_PRELOAD） ===

libc依存でないプログラム（Go製のものなど）には効かない。

==== socksify ====

後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。


==== proxychains-ng(proxychains) ====

ngはnew generationの略で、proxychainsの後継である。ただしコマンド名はproxychains4である。

多段プロキシを構成するためのソフトウェア。

UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 https://github.com/rofl0r/proxychains-ng/issues/336]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 https://github.com/rofl0r/proxychains-ng/issues/103]）。


==== torsocks(tsocks) ====

多分、メンテされていないtsocksがTorに取り込まれてtorsocksになったような感じ。tsocksは非常に古く、多分2010年以降には更新されていないが、知名度は高く、今でも多分そこそこ使われてそう。

torsocksはアクティブなはず。ただし、Torでない普通のSOCKS5を指定しても動かないようである（やり方が悪いかも）。

tsocksはUDPには対応していない。torsocksもそうだが、まずそもそもTor自体がUDPに対応していない。


=== Windows（DLL Hijacking） ===

どのDLLを置き換えたらいいか自明ではなさそうなので、LD_PRELOADと違って対象とするソフトウェアごとに実装が必要そう。そもそも不可能なソフトウェアもLD_PRELOADの場合より多そう。よく見かけるのはDiscordを対象にしたもので、ロシア系のものが多い。筆者は使ったことがない。

==== discord-drover ====

[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]

==== discord-voice-proxy ====

[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]


== HTTPプロキシ ==

Squid, Privoxyなどが有名


== SOCKS関連の話題 ==


==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。

* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]
** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]


==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

クライアントがサーバー側にUDP Associateリクエストをするとき、この2フィールドには通信したい宛先ではなく（←というかそもそもそれが複数ある場合もある）、クライアント側がUDP Associateに使用する予定のポートを入れる。指定しない場合（例えばNATがある場合、これを予測するのは難しくなる）は、全ビットを0に設定する必要がある。

これによってサーバー側は、UDPパケットが送られてきたタイミングでそれが事前に通知されたものと一致するかどうか確認できるというわけである。

この部分に誤ってクライアント側が通信したい宛先ポートを入れるよう実装していたSOCKS5クライアントがいくつかある。

* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
* things-go/go-socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。


== VPN(tun) ==


==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]

Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。

==== hev-socks5-tunnel ====

[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]

hev-socks5-tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。

== プロキシプロトコル間の変換 ==

==== socks-to-http-proxy ====

[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]

名前の通り、socksをhttpにしてくれる。starは250ほど。

==== privoxy ====

基本的にはHTTPプロキシソフトウェア。socksプロキシをhttpプロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）


== UDP・Wireguard関連 ==


==== UDPでサーバー→クライアントにデータ送信 ====

[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]

これを使うと、サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等になるのでreverseをするのが楽になる

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel]
* どっちも開放できない場合、UDPホールパンチングで何とかするしかない

==== wgslirpy ====

[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]

Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。

==== wireproxy ====

[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]

wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。

依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。

<ul>
<li>自分でカスタマイズしてCone NATを加えたthings-go/go-socks5を使えば（<code>go.mod</code>で<code>replace github.com/things-go/go-socks5 => ../../go-socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>


=== Wireguard通信の確立: 各パターンでのやり方 ===

各状況に応じて、2端末間でUDPの暗号化された通信路を確立するための方法を書いた。

* forwardは「クライアント→サーバー」、reverseは「サーバー→クライアント」という意味。「サーバー」は、「ポートが開放できる方」という意味合い。

==== どっちもrootあり ====

普通にWireguardを使う

==== サーバーのみrootあり ====

forward

サーバーはWireguard、クライアントは普通にWireproxyでいける

reverse

udp-reverse-tunnelで頑張って逆にする（あるいはホールパンチング）。

その上で、wgslirpyを使うか、Hysteriaを使うか

==== クライアントのみrootあり ====

↑さっきと逆

forward

wgslirpyを使うか、Hysteriaを使うか

reverse

udp-reverse-tunnelで頑張ったうえで普通にWireguardとWireproxy

==== どっちもrootなし ====

この場合そもそもWireguardを使うメリットはあまりないかも。というのとrootがないならポート開放も無理そう

forward

Hysteriaでいけそう。

reverse

udp-reverse-tunnelしてHysteria？かな
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}