@@ 10行目: / 10行目: @@
 ==== 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推しに見える。
+GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost <span>https://github.com/ginuerzh/gost</span>], [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ほど。
@@ 22行目: / 22行目: @@
 <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>
+<p>[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 <span>https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17</span>]</p></li></ul>
 ==== go&#45;proxy ====
-[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]
+[https://github.com/snail007/goproxy <span>https://github.com/snail007/goproxy</span>]
 これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。
@@ 37行目: / 37行目: @@
 ==== shadowsocks ====
-SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。
+SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust <span>https://github.com/shadowsocks/shadowsocks-rust</span>]などが主流とみられる。
 VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。
@@ 53行目: / 53行目: @@
 == 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>
 ==== dlundquist/sniproxy ====
-[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。
+[https://github.com/dlundquist/sniproxy <span>https://github.com/dlundquist/sniproxy</span>]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。
 ==== tcpproxy ====
-[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。
+[https://github.com/inetaf/tcpproxy <span>https://github.com/inetaf/tcpproxy</span>]　starは1.3kほど。ライブラリ用途がメインか。
 <span id="ameshkovsniproxy"></span>
 ==== ameshkov/sniproxy ====
-[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。
+[https://github.com/ameshkov/sniproxy <span>https://github.com/ameshkov/sniproxy</span>]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。
 <span id="puxxustcsniproxy"></span>
 ==== puxxustc/sniproxy ====
-[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。
+[https://github.com/puxxustc/sniproxy <span>https://github.com/puxxustc/sniproxy</span>]　starもほぼなく更新も9年前。
 <span id="socksプロキシサーバー"></span>
 == SOCKSプロキシサーバー ==
+ここにあげたものは特に注記がなければUDP（ただし筆者が念頭に置いているのはAssociateのみで、Bindに関してはほぼ調べていない）に対応している。
 <span id="dante"></span>
@@ 85行目: / 87行目: @@
 企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。
+Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。
 Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。
@@ 99行目: / 103行目: @@
 ==== 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]
+[https://github.com/ge9/socks-with-udp-over-ssh <span>https://github.com/ge9/socks-with-udp-over-ssh</span>]
-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]に書いてある。
+* このツールでは、DNSリクエストを解釈してサーバー側（サーバー側から見えている外部のDNSを指定してもよい）で解決を行う機能も実装してある。この機能は”fake dns”と名付けているが、shadowsocks&#45;rustのfake dnsやtun2proxyのvirtual dnsはこれとは異なる機能のようである。
 ==== 3proxy ====
@@ 109行目: / 115行目: @@
 [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]
+[https://github.com/3proxy/3proxy <span>https://github.com/3proxy/3proxy</span>]
-ロシア系。エラーメッセージなどがかなり不親切だが、ちゃんと動くソフト。
+ロシア系。SOCKS・HTTP・POP3・SMTPなどいくつかのプロキシを含む。エラーメッセージなどがかなり不親切だが、結構多機能で、ちゃんと動くソフト。<code>3proxy</code>というメインの実行ファイルとあわせて、各プロキシに対応した<code>socks</code>や<code>proxy</code>といった検索性の低い名前の実行ファイルがいくつか含まれているちょっと謎の構成。
 ==== fast&#45;socks5 ====
-[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし
+[https://github.com/dizda/fast-socks5 <span>https://github.com/dizda/fast-socks5</span>] Rust製では最も有名か。starは500ほど。使ったことなし
 <span id="txthinkingsocks5"></span>
 ==== txthinking/socks5 ====
-[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]
+[https://github.com/txthinking/socks5 <span>https://github.com/txthinking/socks5</span>]
-starは700前後。hysteriaやtrojan&#45;goなどいくつかの大きなプロジェクトで使われており、go製のSOCKS5関連ライブラリでは一番メジャーか。
+starは700前後。hysteriaやtrojan&#45;goなどいくつかの大きなプロジェクトで使われており、現在もメンテされているgo製のSOCKS5関連ライブラリでは一番メジャーか。
 クライアントもある。
-自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した
+自分のfork（[https://github.com/ge9/socks5 <span>https://github.com/ge9/socks5</span>]）では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]
+[https://github.com/armon/go-socks5 <span>https://github.com/armon/go-socks5</span>]
-starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。
+starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 <span>https://github.com/whyvl/wireproxy/issues/15</span>]）。
 ここからフォークされたものが複数ある。
@@ 140行目: / 146行目: @@
 ==== things&#45;go/go&#45;socks5 ====
-[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]
+[https://github.com/things-go/go-socks5 <span>https://github.com/things-go/go-socks5</span>]
-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]）。
+armon/go&#45;socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 <span>https://github.com/things-go/go-socks5/pull/63</span>]）。
 Wireproxyで使われている。
-自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した
+自分のフォーク [https://github.com/ge9/go-socks5 <span>https://github.com/ge9/go-socks5</span>] ではFull Cone NATを追加した
 <span id="haxiisocks5"></span>
 ==== haxii/socks5 ====
-[https://github.com/haxii/socks5 https://github.com/haxii/socks5]
+[https://github.com/haxii/socks5 <span>https://github.com/haxii/socks5</span>]
 armon/go&#45;socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。
@@ 158行目: / 164行目: @@
 ==== wzshiming/socks5 ====
-[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]
+[https://github.com/wzshiming/socks5 <span>https://github.com/wzshiming/socks5</span>]
 クライアントもある。
@@ 166行目: / 172行目: @@
 とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。
-Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。
+Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 <span>https://github.com/whyvl/wireproxy/issues/15</span>]）が結局使用されず。
 <span id="haochen233socks5"></span>
 ==== haochen233/socks5 ====
-[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]
+[https://github.com/haochen233/socks5 <span>https://github.com/haochen233/socks5</span>]
 クライアントもある。
@@ 177行目: / 183行目: @@
 UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。
-同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。
+同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 <span>https://github.com/whyvl/wireproxy/issues/15</span>]）が結局使用されず。
-=== tun系 ===
-==== tun2proxy ====
-[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]
 <span id="透過socksプロキシクライアント"></span>
@@ 190行目: / 190行目: @@
 [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のレイヤで透過プロキシを行うもの。VPNと同等の動作で、基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。
+以下のいずれも、ドメイン解決にはプロキシが適用されない（Linux向けの2つはできなくはないかもしれないが、しづらい）ことに注意。
 ==== redsocks ====
@@ 197行目: / 199行目: @@
 &#42;nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。
+==== hev&#45;socks5&#45;tproxy ====
+[https://github.com/heiher/hev-socks5-tproxy <span>https://github.com/heiher/hev-socks5-tproxy</span>] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。
 <span id="proxifyre"></span>
 ==== ProxiFyre ====
-[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。
+[https://github.com/wiresock/proxifyre <span>https://github.com/wiresock/proxifyre</span>] 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>
@@ 211行目: / 213行目: @@
 [https://www.proxifier.com/ https&#58;//www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。
+<span id="vpntun"></span>
+== VPN(tun) ==
+上記と似ているが、VPNとして動作するもの。プロセスが特定しづらい場合・特定のIPアドレス範囲だけで十分な場合などに効果を発揮する。
+以下は特筆しない限りUDP Associateに対応。もちろん、pingなどは通らない。
+==== tun2proxy ====
+[https://github.com/tun2proxy/tun2proxy <span>https://github.com/tun2proxy/tun2proxy</span>]
+Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。
+==== hev&#45;socks5&#45;tunnel ====
+[https://github.com/heiher/hev-socks5-tunnel <span>https://github.com/heiher/hev-socks5-tunnel</span>]
+hev&#45;socks5&#45;tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun <span>https://github.com/heiher/sockstun</span>]もここから。
 == ライブラリ関数ハック系 ==
@@ 239行目: / 260行目: @@
 多段プロキシを構成するためのソフトウェア。
-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]）。
+UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 <span>https://github.com/rofl0r/proxychains-ng/issues/336</span>]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 <span>https://github.com/rofl0r/proxychains-ng/issues/103</span>]）。
 <span id="torsockstsocks"></span>
@@ 257行目: / 278行目: @@
 ==== discord&#45;drover ====
-[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]
+[https://github.com/hdrover/discord-drover <span>https://github.com/hdrover/discord-drover</span>]
 ==== discord&#45;voice&#45;proxy ====
-[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]
+[https://github.com/runetfreedom/discord-voice-proxy <span>https://github.com/runetfreedom/discord-voice-proxy</span>]
 <span id="httpプロキシ"></span>
@@ 270行目: / 291行目: @@
 Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。
+<span id="localhostlanなどへのアクセス制限"></span>
+== localhost・LANなどへのアクセス制限 ==
+典型的な設定例として、localhostやプライベートIPへのアクセスを制限する設定をSquid・Dante・3proxyそれぞれに関して紹介しておく。
+プロキシ側で設定せず、cgroupなどを使ってファイアウォール側で制御する方法もある。
+==== squid ====
+<code>to_localhost</code>はbuilt&#45;inとして定義されていて、<code>localnet</code>（&#61;srcがlocalnet）についてもUbuntuパッケージで提供されるsquid.confには入っているのだが、localnetがdstであるものとなるとACLが定義されていない。
+<code>deny to_localhost</code>と<code>deny to_linklocal</code>は定義済みという前提で、以下のように書くとよい。
+<syntaxhighlight lang="go">acl to_localnet dst 0.0.0.1-0.255.255.255
+acl to_localnet dst 10.0.0.0/8
+acl to_localnet dst 100.64.0.0/10
+acl to_localnet dst 172.16.0.0/12
+acl to_localnet dst 192.168.0.0/16
+acl to_localnet dst fc00::/7
+http_access deny to_localnet</syntaxhighlight>
+<span id="3proxy-1"></span>
+==== 3proxy ====
+IPv4のみ対応。
+<syntaxhighlight lang="go">deny * * 127.0.0.0/8,0.0.0.1-0.255.255.255,10.0.0.0/8,100.64.0.0/10,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16 * * * *
+allow *</syntaxhighlight>
+<span id="dante-1"></span>
+==== dante ====
+IPv4のみ対応。squid・3proxyの場合と違って0.0.0.0もblockしてしまっているが、そもそも使わないので問題ないはず。
+<syntaxhighlight lang="go">client pass {
+  from: 0/0  to: 0/0
+}
+socks block {
+    from: 0/0 to: 127.0.0.0/8 # localhost
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 0.0.0.0/8 # RFC 1122 "this" network (LAN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 10.0.0.0/8        # RFC 1918 local private network (LAN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 100.64.0.0/10     # RFC 6598 shared address space (CGN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 169.254.0.0/16    # RFC 3927 link-local (directly plugged) machines
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 172.16.0.0/12     # RFC 1918 local private network (LAN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 192.168.0.0/16        # RFC 1918 local private network (LAN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks pass {
+    from: 0/0 to: 0.0.0.0/0
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}</syntaxhighlight>
 <span id="socks関連の話題"></span>
 == SOCKS関連の話題 ==
+<span id="natが介在する場合などのudp-associateの動作"></span>
+==== NATが介在する場合などのUDP Associateの動作 ====
+OpenSSHの項目でも関連することを述べたが、UDP&#45;over&#45;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&#45;socks5&#45;tproxyなどは中継ポート通知のIP部分を無視するため、ポート番号が変わらないNATであれば問題なく動作する（redsocksはダメ）。
 <span id="socks5によるドメイン解決"></span>
@@ 278行目: / 384行目: @@
 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ブラウザなどでは、この機能が使われる場合がある（参照&#58; [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?]）。
+透過SOCKSプロキシの場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]）（さらに、繰り返しになるが付け加えておくと、普通にセットアップした場合はDNSにプロキシは使われない）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 <span>https://github.com/FelisCatus/SwitchyOmega/issues/1379</span>]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる（これは[https://github.com/FelisCatus/SwitchyOmega/wiki/FAQ FAQ]にも書いてある）一方、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 <span>https://github.com/FelisCatus/SwitchyOmega/issues/2304</span>]
 <span id="ブラウザのsocks5プロキシのwebrtc対応"></span>
@@ 291行目: / 401行目: @@
 ** 新しめの包括的なバグレポート [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が無くても可能。
+従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことが多くなるだろう。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。
 <span id="udp-associateリクエストのdstaddrとdstport"></span>
@@ 302行目: / 412行目: @@
 この部分に誤って<strong>クライアント側が通信したい宛先ポート</strong>を入れるよう実装していたSOCKS5クライアントがいくつかある。
-* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
+* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 <span>https://github.com/semigodking/redsocks/issues/210</span>]で修正済み。
-* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
+* gost…[https://github.com/ginuerzh/gost/issues/96 <span>https://github.com/ginuerzh/gost/issues/96</span>]で修正済み。
-* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
+* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 <span>https://github.com/txthinking/socks5/issues/15</span>]で修正済み。
-* things&#45;go/go&#45;socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。
+* things&#45;go/go&#45;socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 <span>https://github.com/things-go/go-socks5/issues/29</span>]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。
-<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]もここから。
 == プロキシプロトコル間の変換 ==
@@ 327行目: / 421行目: @@
 ==== socks&#45;to&#45;http&#45;proxy ====
-[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]
+[https://github.com/KaranGauswami/socks-to-http-proxy <span>https://github.com/KaranGauswami/socks-to-http-proxy</span>]
 名前の通り、socksをhttpにしてくれる。starは250ほど。
@@ 341行目: / 435行目: @@
 ==== UDPでサーバー→クライアントにデータ送信 ====
-[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]
+[https://github.com/prof7bit/udp-reverse-tunnel <span>https://github.com/prof7bit/udp-reverse-tunnel</span>]
 これを使うと、<strong>サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等</strong>になるのでreverseをするのが楽になる
@@ 350行目: / 444行目: @@
 ==== wgslirpy ====
-[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]
+[https://github.com/vi/wgslirpy <span>https://github.com/vi/wgslirpy</span>]
 Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。
@@ 356行目: / 450行目: @@
 ==== wireproxy ====
-[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]
+[https://github.com/whyvl/wireproxy <span>https://github.com/whyvl/wireproxy</span>]
 wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。
-依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。
+依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 <span>https://github.com/whyvl/wireproxy/issues/30</span>]）。
 <ul>
@@ 412行目: / 506行目: @@
 udp&#45;reverse&#45;tunnelしてHysteria？かな
+== その他の話題 ==
+==== ドメインごとにプロキシを変更できるブラウザ拡張のiframeにおける動作 ====
+FoxyProxyやSwitchyOmega(ZeroOmega)など、ドメインごとに自動でプロキシを切り替えてくれるブラウザ拡張はChromium系にもFirefoxにもいくつかあるが、これらはあくまでコンテンツのオリジンを元にプロキシを適用しており、ブラウザのタブを見ているわけではない。つまり、foo.comのページを開いていて、そこにbar.comのコンテンツがiframeで埋め込まれている場合、iframeの内部は、bar.comに対して使用するものと指定されたプロキシを使用して処理される。
+一応、[https://superuser.com/questions/250172/disable-enable-the-proxy-on-a-tab-by-tab-basis-in-firefox Disable/enable the proxy on a tab by tab basis in Firefox]によると、Firefoxのcontainer&#45;proxyというのがこれに近い機能を実質的に実現してくれるらしい。
 [[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

「HTTP・SOCKS・透過プロキシ・UDP」の版間の差分