ネットワークのすべてのトラフィックをプロキシを介して通過させたい場合 — 各ノートパソコン、スマートフォン、サーバーで手動設定を行うことなく — OpenWrtルーターでTPROXYを使用した透過プロキシが必要です。このガイドでは、必要なパッケージのインストールからiptablesのルール、動作確認までの完全な構成を説明します。
TPROXYとは何か、なぜ必要か
TPROXY（Transparent Proxy）は、Linuxカーネルのメカニズムで、パケットの宛先IPアドレスを変更することなくTCPおよびUDPトラフィックをキャプチャすることを可能にします。従来のNATリダイレクト（REDIRECT）とは異なり、TPROXYは受信者の元のアドレスを保持するため、プロキシクライアントがネットワーク内のデバイスが接続しようとしている場所を「見る」ことができるため、正確な動作が重要です。
実際にこれはなぜ必要なのでしょうか？オフィスや家庭のラボに数十台のデバイス（コンピュータ、スマートフォン、IoTデバイス、テスト用仮想マシン）があると想像してみてください。それぞれに手動でプロキシを設定するのは、何時間もかかり、プロキシサーバーを変更するたびに頭痛の種になります。ルーター上の透過プロキシは、ネットワーク全体のトラフィックを自動的にプロキシを通過させ、デバイスはそれに気づくことすらありません。
OpenWrtにおけるTPROXYの典型的な使用シナリオは次のとおりです：
- ジオブロックを回避するために、常駐またはモバイルプロキシを介してすべてのトラフィックをルーティングする
- 企業ネットワーク内のトラフィックを集中監視およびフィルタリングする
- クライアントマシンの設定を変更することなく、異なる地域からプロキシを介してアプリケーションをテストする
- ルーターに接続されたすべてのデバイスのIPを自動的に置き換える
- 単一のゲートウェイを介してアンチデテクトブラウザ（Dolphin Anty、AdsPower、GoLogin）を使用する
TPROXYの最大の利点は、通常のREDIRECTに対するUDPのサポートです。これは、REDIRECTが正しく処理できない現代のプロトコル（QUIC、DNS over UDP、ゲームトラフィック）にとって重要です。
OpenWrtにおける透過プロキシの動作
OpenWrtにおけるTPROXYの動作の仕組みは次のようになります：
- ネットワーク内のデバイスが外部IPアドレス（例：
93.184.216.34:443）にパケットを送信します。 - ルーターは、ルーティングの決定を行う前にPREROUTINGチェーンで
iptables TPROXYルールでパケットをキャプチャします。 - パケットには特別なfwmarkが付けられ、プロキシクライアントのローカルソケット（例：ポート7893）にリダイレクトされます。
- プロキシクライアント（redsocks、Xray、sing-box）は、
IP_TRANSPARENTメカニズムを介して元の宛先アドレスを「見る」ことができ、リモートプロキシサーバーを介して接続を確立します。 - 応答がデバイスに戻ります — 透明に、クライアント側での変更はありません。
💡 重要なポイント
TPROXYは、PREROUTINGチェーンのmangleテーブルでのみ動作します。これは、ネットワークデバイスからのトランジットトラフィックのみがキャプチャされ、ルーター自体のトラフィックはキャプチャされないことを意味します。ルーターのトラフィックをキャプチャするには、OUTPUTを介して追加の設定が必要です。
要件: ルーター、ファームウェア、パッケージ
設定を開始する前に、構成が最小要件を満たしていることを確認してください。
ルーターの要件
| パラメータ | 最小 | 推奨 |
|---|---|---|
| RAM | 64 MB | 256 MB以上 |
| フラッシュ / ストレージ | 16 MB | 128 MB以上 |
| CPUアーキテクチャ | MIPS、ARM | ARM Cortex-A7/A53以上 |
| OpenWrtのバージョン | 21.02 | 23.05またはスナップショット |
| Linuxカーネル | 5.4 TPROXY付き | 5.15 / 6.1 |
このタスクに適した実績のあるモデル：GL.iNet GL-MT6000 (Flint 2)、Xiaomi AX3000T、Banana Pi BPi-R3、Raspberry Pi 4（OpenWrt搭載）、および十分なRAMを持つ任意のx86ルーター。
TPROXYのカーネルサポートの確認
SSHでルーターに接続し、次のコマンドを実行します：
zcat /proc/config.gz | grep TPROXY
CONFIG_NETFILTER_XT_TARGET_TPROXY=yまたは=mという行が表示されるはずです。出力が空であれば、カーネルはTPROXYをサポートしておらず、再コンパイルまたはファームウェアの変更が必要です。
必要なパッケージのインストール
OpenWrtでTPROXYを動作させるには、いくつかのパッケージが必要です。SSHで接続し、パッケージリストを更新します：
opkg update必要なコンポーネントをインストールします：
# TPROXY用のカーネルモジュール
opkg install kmod-nft-tproxy
# iptablesを使用している場合（古いスタック）
opkg install iptables-mod-tproxy
# ip rule / ip routeユーティリティ
opkg install ip-full
# fwmarkを使用するための追加
opkg install kmod-ipt-tproxy選択したプロキシクライアントに応じて、次のパッケージのいずれかをインストールします：
| プロキシクライアント | OpenWrtパッケージ | TPROXYサポート |
|---|---|---|
| redsocks | redsocks |
TCP（UDPはredsocks2経由） |
| Xray-core | xray-core |
TCP + UDP（ネイティブ） |
| sing-box | sing-box |
TCP + UDP（ネイティブ） |
| mihomo（Clash Meta） | mihomo |
TCP + UDP（ネイティブ） |
大多数のタスクにはsing-boxまたはmihomoをお勧めします — これらはTPROXYをネイティブでサポートし、UDPを含む便利な構成形式を持っています。
iptablesおよびipルールの設定
これは重要なステップです。必要なことは3つあります：必要なパケットにfwmarkを付け、特別なルーティングテーブルを設定し、iptablesにTPROXYルールを追加します。
ステップ 1: ルーティングテーブルの作成
# 特別なルートを追加：マークされたパケットはループバックに行く
ip rule add fwmark 1 table 100
ip route add local default dev lo table 100これはカーネルに「fwmark=1のすべてのパケットをローカルと見なし、ループバックに配信する」と指示します。これにより、プロキシクライアントはソケットを介して受け取ることができます。
ステップ 2: iptablesルール（mangle/PREROUTING）
# TPROXY用のチェーンを作成
iptables -t mangle -N TPROXY_RULES
# ローカルアドレスを除外する（プロキシしない）
iptables -t mangle -A TPROXY_RULES -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 240.0.0.0/4 -j RETURN
# TCPをプロキシクライアントのポート（7893）にリダイレクト
iptables -t mangle -A TPROXY_RULES -p tcp \
-j TPROXY --on-port 7893 --on-ip 127.0.0.1 --tproxy-mark 1
# UDPをプロキシクライアントのポート（7893）にリダイレクト
iptables -t mangle -A TPROXY_RULES -p udp \
-j TPROXY --on-port 7893 --on-ip 127.0.0.1 --tproxy-mark 1
# トランジットトラフィックにチェーンを適用
iptables -t mangle -A PREROUTING -j TPROXY_RULES📌 ポート7893
ポート7893は、プロキシクライアント（sing-box、mihomo、Xray）がtproxyモードでリッスンしているポートです。クライアントの設定と一致していることを確認してください。
ステップ 3: 再起動時のルールの保存
/etc/init.d/tproxyに自動起動スクリプトを作成するか、/etc/rc.localにコマンドを追加します。OpenWrt 23.05でiptablesの代わりにnftablesを使用する場合は、nftの構文で同様のルールを使用します：
nft add table ip tproxy_table
nft add chain ip tproxy_table prerouting \
'{ type filter hook prerouting priority mangle; policy accept; }'
nft add rule ip tproxy_table prerouting \
ip daddr { 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } return
nft add rule ip tproxy_table prerouting \
tcp tproxy to 127.0.0.1:7893 meta mark set 1
nft add rule ip tproxy_table prerouting \
udp tproxy to 127.0.0.1:7893 meta mark set 1プロキシクライアントの構成: redsocks、Xray、sing-box
ルーター上のプロキシクライアントは、キャプチャされたトラフィックを受け取り、リモートプロキシサーバーを介して送信するプログラムです。最も人気のあるオプションの構成を見てみましょう。
オプション 1: redsocks（シンプル、TCPのみ）
SOCKS5プロキシを使用した基本的なタスクに適しています。構成ファイル/etc/redsocks.conf：
base {
log_debug = off;
log_info = on;
log = "file:/var/log/redsocks.log";
daemon = on;
redirector = tproxy;
}
redsocks {
local_ip = 127.0.0.1;
local_port = 7893;
// あなたのSOCKS5プロキシのアドレス
ip = 185.220.101.50;
port = 1080;
type = socks5;
// プロキシが認証を必要とする場合：
login = "your_login";
password = "your_password";
}オプション 2: sing-box（推奨 — TCP + UDP）
sing-boxはTPROXYをネイティブでサポートし、SOCKS5、HTTP、Shadowsocks、VLESS、Trojanなどのほとんどのプロキシタイプで動作します。構成の例/etc/sing-box/config.json：
{
"inbounds": [
{
"type": "tproxy",
"listen": "127.0.0.1",
"listen_port": 7893,
"tcp_fast_open": false,
"udp_fragment": true,
"sniff": true
}
],
"outbounds": [
{
"type": "socks",
"tag": "proxy-out",
"server": "185.220.101.50",
"server_port": 1080,
"version": "5",
"username": "your_login",
"password": "your_password"
},
{
"type": "direct",
"tag": "direct"
}
],
"route": {
"rules": [
{
"geoip": ["private"],
"outbound": "direct"
}
],
"final": "proxy-out"
}
}sing-boxを起動し、自動起動に追加します：
/etc/init.d/sing-box enable
/etc/init.d/sing-box startオプション 3: mihomo / Clash Meta
mihomoはClashのフォークで、拡張機能があります。tproxy-portセクションでキャプチャ用のポートを指定します：
mixed-port: 7890
tproxy-port: 7893
allow-lan: false
mode: rule
log-level: info
proxies:
- name: "my-socks5"
type: socks5
server: 185.220.101.50
port: 1080
username: your_login
password: your_password
udp: true
proxy-groups:
- name: "PROXY"
type: select
proxies:
- my-socks5
rules:
- IP-CIDR,192.168.0.0/16,DIRECT
- IP-CIDR,10.0.0.0/8,DIRECT
- MATCH,PROXYDNSリークの防止
正しいDNS設定なしでの透過プロキシは重大な脆弱性です。DNSクエリがプロキシを介さずにプロバイダーを通過する場合、IPアドレスを置き換えても実際の位置が明らかになります。これは、匿名性や地理的な置き換えが重要なタスクにとって致命的です。
方法 1: TPROXYを介したDNSのキャプチャ
UDPトラフィックをポート53でキャプチャするためのルールを追加します：
# ネットワークデバイスからのDNSクエリをキャプチャ
iptables -t mangle -A TPROXY_RULES -p udp --dport 53 \
-j TPROXY --on-port 7893 --on-ip 127.0.0.1 --tproxy-mark 1方法 2: sing-box / mihomoを介したDNS
sing-boxとmihomoは、DNSクエリを自動的に処理し、プロキシを介して送信することができます。sing-boxの設定にDNSセクションを追加します：
"dns": {
"servers": [
{
"tag": "remote",
"address": "8.8.8.8",
"detour": "proxy-out"
},
{
"tag": "local",
"address": "192.168.1.1",
"detour": "direct"
}
],
"rules": [
{
"geoip": ["private"],
"server": "local"
}
],
"final": "remote",
"independent_cache": true
}方法 3: dnsmasqをプロキシ経由で上流に設定
sing-box/mihomoを使用していない場合は、dnsmasq（OpenWrtの標準DNSサーバー）を設定して、リクエストを暗号化されたDNSサーバーに転送します。/etc/dnsmasq.confファイルに次のように記述します：
# プロバイダーからのDNS使用を無効にする
no-resolv
# ローカルリゾルバーを介してDoH/DoTを使用
server=127.0.0.1#5335
# デバイスが外部DNSを直接使用することを禁止する
# （直接DNSリクエストをブロックするためのiptablesルール）
# iptables -t nat -A PREROUTING -p udp --dport 53 ! -d 192.168.1.1 -j DNAT --to 192.168.1.1確認とデバッグ
設定後は、透過プロキシが正しく動作しているか必ず確認してください。以下はステップバイステップのチェックリストです。
ステップ 1: iptablesルールの確認
# TPROXY_RULESチェーンを表示
iptables -t mangle -L TPROXY_RULES -v -n
# ルーティングテーブル100を確認
ip rule show
ip route show table 100ステップ 2: プロキシクライアントがポートをリッスンしているか確認
ss -tlnp | grep 7893
# または
netstat -tlnp | grep 7893
127.0.0.1:7893でリッスンしているsing-box、mihomo、またはredsocksプロセスが表示されるはずです。
ステップ 3: クライアントデバイスからのIP確認
ネットワーク内の任意のデバイスからルーターに接続し、ブラウザでifconfig.meまたは2ip.ruを開きます。表示されるIPは、プロキシサーバーのIPと一致し、プロバイダーの実際のIPとは異なるはずです。
ステップ 4: DNSリークの確認
dnsleaktest.comにアクセスし、拡張テストを実行します。結果に表示されるDNSサーバーは、プロキシプロバイダーまたは選択したDoHサーバーに属し、インターネットプロバイダーに属してはいけません。
一般的な問題とその解決策
| 症状 | 原因 | 解決策 |
|---|---|---|
| インターネットが全く機能しない | プロキシクライアントが起動していない | サービスのステータスとクライアントのログを確認してください |
| IPが変更されない | iptablesルールが適用されていない | 確認してくださいiptables -t mangle -L -v |
| UDPが機能しない | redsocksはUDPをサポートしていない | sing-boxまたはmihomoに切り替えてください |
| ルーティングループ | プロキシクライアントのトラフィックもキャプチャされる | プロキシクライアントのUIDまたはcgroupをルールから除外してください |
| TPROXYターゲットエラー | カーネルモジュールがロードされていない | modprobe xt_TPROXY |
TPROXYに適したプロキシの種類
プロキシの種類の選択は結果に重大な影響を与えます。ルーター上の透過プロキシにはすべてのオプションが適しているわけではなく、プロトコル、接続の安定性、タスクを考慮することが重要です。
SOCKS5プロキシ
TPROXYに最も汎用的なオプションです。TCPおよびUDPをサポートしています（sing-box/mihomoを使用する場合）。ジオブロックの回避、ネットワーク全体のIPの置き換え、マーケットプレイスとの連携など、ほとんどのタスクに適しています。データセンターのプロキシはSOCKS5形式で高い速度と安定性を提供し、速度が優先される場合の最適な選択です。
レジデンシャルプロキシ
レジデンシャルプロキシは、実際の家庭ユーザーのIPアドレスを使用します。ルーター上でTPROXYを介してルーティングする場合、ネットワークのすべてのトラフィックは、必要な国の通常の家庭用インターネットユーザーのトラフィックとして見えます。次の目的に最適です：
- 海外マーケットプレイス（Amazon、eBay、Zalando）の価格監視
- 異なる地域からの広告のテスト
- データセンターのIPを積極的にブロックするプラットフォームとの連携
- 実際のユーザーとしての最大限のマスキングが必要なタスク
モバイルプロキシ
モバイルプロキシは、モバイル通信事業者（4G/5G）のIPを介して動作します。プラットフォームからの信頼度が最も高く、Facebook、Instagram、TikTokはモバイルIPをブロックすることはほとんどありません。なぜなら、1つのアドレスの背後には数千の実際のユーザーがいる可能性があるからです。TPROXYを介して使用することで、ネットワークのすべてのトラフィックがモバイルIPを取得し、次の目的にとって重要です：
- Facebook AdsやTikTok Adsを介したトラフィックの仲介
- ソーシャルメディアアカウントのファーミング
- 単一のゲートウェイを介してアンチデテクトブラウザ（Dolphin Anty、AdsPower、GoLogin）を使用する
| プロキシの種類 | 速度 | プラットフォームの信頼 | 最適なシナリオ |
|---|---|---|---|
| データセンター | ⚡ 高速 | ★★☆☆☆ | パース、価格監視 |
| レジデンシャル | ⚡⚡ 中速 | ★★★★☆ | ジオテスト、eコマース |
| モバイル | ⚡ 中速 | ★★★★★ | ソーシャルメディア、トラフィック仲介 |
結論
OpenWrtでのTPROXYを介した透過プロキシは、ネットワーク全体のトラフィックを集中管理するための強力なツールです。このアプローチの主な利点は、各デバイスにプロキシを個別に設定する必要がなく、TCPおよびUDPトラフィックの両方をサポートし、家庭用から企業インフラストラクチャまであらゆるタスクに柔軟にスケールできる構成です。
我々が説明した主要なステップは、OpenWrtのカーネルでのTPROXYのサポートの確認、必要なパッケージのインストール、正しいfwmarkを持つiptables/nftablesルールの設定、プロキシクライアント（redsocks、sing-box、またはmihomo）の構成、DNSリークの防止です。これらの各ステップは重要であり、いずれかを省略すると不正確な動作や実際のIPのリークが発生します。
あなたのタスクが、最大限のプラットフォームの信頼を得ながらネットワーク全体のトラフィックをプロキシを介してルーティングすることであれば、レジデンシャルプロキシを使用することをお勧めします — これは必要な国からの実際の家庭用IPを提供し、透過プロキシを介して作業する際のブロックのリスクを最小限に抑えます。
```