Torを正常に設定しました透明プロキシiptablesを使用してください（つまり、出てくるすべてのトラフィックは、アプリケーションが知らない間にTorを介して送信されます）。そうしながら、私は奇妙な問題と同様に、奇妙な修正（解決方法？）を見つけました。
私のルールは次のとおりです。カスタムチェーンやその他のルールはなく、すべてのポリシーが許可されます。
-t nat -A OUTPUT -o lo -j RETURN
-t nat -A OUTPUT -p tcp -m owner --uid-owner tor -j RETURN
-t nat -A OUTPUT -p tcp --syn -j REDIRECT --to-ports 54
-t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 55
-A INPUT -j ACCEPT
-A OUTPUT -o lo -j ACCEPT # Rule A
-A OUTPUT -d 127.0.0.1 -j ACCEPT # Rule B
-A OUTPUT -p tcp -m owner --uid-owner tor -j ACCEPT
-A OUTPUT -j REJECT # Rule C
言い換えれば：
- localhost から入ってくるすべてのトラフィックは変更されません。
- Torによって生成されたすべてのトラフィックは影響を受けません。
- 発信するすべてのTCP接続は、Tor（透明プロキシポート54）を介して送信されます。
- 発信するすべてのDNSクエリは、Tor（ポート55のDNS）によって解決されます。
- 漏れを防ぐために、他のすべての出発トラフィックはレンガで頭の上にぶつかり、溝に投げられました。
（この設定にはLAN接続に応答しないなど、いくつかの問題がありますが、これは現在の問題とは関係ありません。）
ルールBが存在しない場合、すべての発信接続はルールCによって直ちに拒否されます。拒否の種類（たとえば--reject-with icmp-proto-unreachable）を変更すると、他のエラーが発生するため、ルールCによって拒否されることがわかります。ルールBのないエラーメッセージの例：
# With Rule C --reject-with icmp-port-unreachable, the default:
$ curl 213.155.151.153 # (google.com; DNS also doesn't work)
curl: (7) Failed connect to 213.155.151.153:80; Connection refused
# With Rule C --reject-with icmp-proto-unreachable:
$ curl 213.155.151.153
curl: (7) Failed connect to 213.155.151.153:80; Protocol not available
ルールBを使用すると、接続は正常に機能します。
iptablesの私の理解によると、発信TCP接続が確立されると、OUTPUTチェーンの3番目のルールはパケットの宛先をnat127.0.0.1:54に書き換えます。その後、パケットはOUTPUTチェーンにfilter入ります。しなければならない発信インターフェイスがループバック インターフェイスなので、ルール A と一致します。しかしそれはいいえルールAが一致し、ルールB（一致）が存在しない場合、パケットは路地に引き込まれ、ルールCによって奪われます。
ルールAとルールBが同じではないのはなぜですか？この場合、ループバックインターフェイスのマッチングとループバックアドレスのマッチングはどう違いますか？