HTTP・SOCKS・透過プロキシ・UDPのソースを表示

SOCKS・透過プロキシ・UDP&#45;over&#45;TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

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

<span id="大規模多機能系"></span>
== 大規模・多機能系 ==

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

==== gost ====

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

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

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

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

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

==== go&#45;proxy ====

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

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

<span id="gfw回避"></span>
== GFW回避 ==

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

==== shadowsocks ====

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

VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

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

<span id="hysteria"></span>
==== Hysteria ====

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

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

<span id="sni-proxy"></span>
== SNI Proxy ==

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]

<span id="dlundquistsniproxy"></span>
==== 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ほど。ライブラリ用途がメインか。

<span id="ameshkovsniproxy"></span>
==== ameshkov/sniproxy ====

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

<span id="puxxustcsniproxy"></span>
==== puxxustc/sniproxy ====

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

<span id="socksプロキシサーバー"></span>
== SOCKSプロキシサーバー ==

<span id="dante"></span>
==== Dante ====

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

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

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

<span id="openssh"></span>
==== OpenSSH ====

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

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

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

==== socks&#45;with&#45;udp&#45;over&#45;ssh ====

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

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

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

==== 3proxy ====

[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]

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

==== fast&#45;socks5 ====

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

<span id="txthinkingsocks5"></span>
==== txthinking/socks5 ====

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

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

クライアントもある。

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

<span id="armongo&#45;socks5"></span>
==== armon/go&#45;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]）。

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

<span id="things&#45;gogo&#45;socks5"></span>
==== things&#45;go/go&#45;socks5 ====

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

armon/go&#45;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を追加した

<span id="haxiisocks5"></span>
==== haxii/socks5 ====

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

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

<span id="wzshimingsocks5"></span>
==== 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]）が結局使用されず。

<span id="haochen233socks5"></span>
==== 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]

<span id="透過socksプロキシクライアント"></span>
== 透過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）が必要。

==== redsocks ====

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

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

<span id="proxifyre"></span>
==== ProxiFyre ====

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

==== hev&#45;socks5&#45;tproxy ====

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

<span id="proxifier"></span>
==== Proxifier ====

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

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

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

<span id="linuxld_preload"></span>
=== Linux（LD_PRELOAD） ===

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

==== socksify ====

後述の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&#61;192.168.1.1&#58;1080 socksify curl http&#58;//ipv4.icanhazip.com</code> とかでもよい。

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

<span id="proxychains&#45;ngproxychains"></span>
==== proxychains&#45;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]）。

<span id="torsockstsocks"></span>
==== torsocks(tsocks) ====

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

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

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

<span id="windowsdll-hijacking"></span>
=== Windows（DLL Hijacking） ===

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

==== discord&#45;drover ====

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

==== discord&#45;voice&#45;proxy ====

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

<span id="httpプロキシ"></span>
== HTTPプロキシ ==

Squid, Privoxyなどが有名。

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

<span id="socks関連の話題"></span>
== SOCKS関連の話題 ==

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

基本的に現在主流のブラウザ（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&#58;//gitlab.torproject.org/tpo/applications/mullvad&#45;browser/&#45;/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https&#58;//bugzilla.mozilla.org/show_bug.cgi?id&#61;1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https&#58;//bugzilla.mozilla.org/show_bug.cgi?id&#61;1882071]
** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https&#58;//bugzilla.mozilla.org/show_bug.cgi?id&#61;1947229]

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

<span id="udp-associateリクエストのdstaddrとdstport"></span>
==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

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

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

この部分に誤って<strong>クライアント側が通信したい宛先ポート</strong>を入れるよう実装していた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&#45;go/go&#45;socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。

<span id="vpntun"></span>
== VPN(tun) ==

<span id="tun2proxy-1"></span>
==== tun2proxy ====

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

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

==== hev&#45;socks5&#45;tunnel ====

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

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

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

==== socks&#45;to&#45;http&#45;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プロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）

<span id="udpwireguard関連"></span>
== UDP・Wireguard関連 ==

<span id="udpでサーバークライアントにデータ送信"></span>
==== UDPでサーバー→クライアントにデータ送信 ====

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

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

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https&#58;//superuser.com/questions/1737943/how&#45;to&#45;create&#45;a&#45;reverse&#45;udp&#45;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><p>自分でカスタマイズしてCone NATを加えたthings&#45;go/go&#45;socks5を使えば（<code>go.mod</code>で<code>replace github.com/things&#45;go/go&#45;socks5 &#61;&gt; ../../go&#45;socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。</p>
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>

<span id="wireguard通信の確立&#58;-各パターンでのやり方"></span>
=== Wireguard通信の確立&#58; 各パターンでのやり方 ===

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

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

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

普通にWireguardを使う

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

<strong>forward</strong>

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

<strong>reverse</strong>

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

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

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

↑さっきと逆

<strong>forward</strong>

wgslirpyを使うか、Hysteriaを使うか

<strong>reverse</strong>

udp&#45;reverse&#45;tunnelで頑張ったうえで普通にWireguardとWireproxy

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

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

<strong>forward</strong>

Hysteriaでいけそう。

<strong>reverse</strong>

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