トラブルシューティング
このページはPRX-WAFの実行中に発生する最も一般的な問題とその原因および解決策を説明します。
データベース接続の失敗
症状： PRX-WAFが「connection refused」または「authentication failed」エラーで起動に失敗する。
解決策：
- PostgreSQLが実行中であることを確認：
# Docker
docker compose ps postgres
# systemd
sudo systemctl status postgresql- 接続をテスト：
psql "postgresql://prx_waf:[email protected]:5432/prx_waf"- TOMLコンフィグの接続文字列を確認：
[storage]
database_url = "postgresql://prx_waf:[email protected]:5432/prx_waf"- データベースが存在するがテーブルがない場合はマイグレーションを実行：
prx-waf -c configs/default.toml migrateルールが読み込まれない
症状： PRX-WAFは起動するがルールがアクティブでない。攻撃が検出されていない。
解決策：
- ルール統計を確認：
prx-waf rules stats出力が0ルールを示す場合、ルールディレクトリが空または誤設定されている可能性があります。
- 設定内のルールディレクトリパスを確認：
[rules]
dir = "rules/"- ルールファイルを検証：
python rules/tools/validate.py rules/- YAMLシンタックスエラーを確認 -- 1つの不正なファイルがすべてのルールの読み込みを妨げる可能性があります：
# Validate one file at a time to find the problem
python rules/tools/validate.py rules/owasp-crs/sqli.yaml- 内蔵ルールが有効であることを確認：
[rules]
enable_builtin_owasp = true
enable_builtin_bot = true
enable_builtin_scanner = trueホットリロードが機能しない
症状： ルールファイルが変更されたが変更が反映されない。
解決策：
- ホットリロードが有効であることを確認：
[rules]
hot_reload = true
reload_debounce_ms = 500- 手動でリロードをトリガー：
prx-waf rules reload- SIGHUPを送信：
kill -HUP $(pgrep prx-waf)- ファイルシステム監視の制限を確認（Linux）：
cat /proc/sys/fs/inotify/max_user_watches
# If too low, increase:
echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p誤検知
症状： 正当なリクエストがブロックされている（403 Forbidden）。
解決策：
- セキュリティイベントからブロッキングルールを特定：
curl -H "Authorization: Bearer $TOKEN" http://localhost:9527/api/security-eventsイベントのrule_idフィールドを確認。
- 特定のルールを無効化：
prx-waf rules disable CRS-942100- パラノイアレベルを下げる。 パラノイア2以上で実行している場合、1に削減を試みます：
# In your rules config, only load paranoia level 1 rules- 監視のためにルールをログモードに切り替え：
ルールファイルを編集してaction: "block"をaction: "log"に変更し、リロード：
prx-waf rules reload- 信頼されたソースのIPアローリストを追加：
curl -X POST http://localhost:9527/api/rules/ip \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"ip": "10.0.0.0/8", "action": "allow"}'TIP
新しいルールをデプロイする際は、action: blockに切り替える前に誤検知を監視するためにaction: logで始めてください。
SSL証明書の問題
症状： HTTPS接続の失敗、証明書エラー、またはLet's Encrypt更新の失敗。
解決策：
管理UIのSSL証明書セクションで証明書ステータスを確認。
ACME HTTP-01チャレンジのためにポート80がインターネットからアクセス可能であることを確認。
手動証明書を使用している場合は証明書パスを確認：
[http3]
cert_pem = "/etc/prx-waf/tls/cert.pem"
key_pem = "/etc/prx-waf/tls/key.pem"- 証明書がドメインと一致することを確認：
openssl x509 -in /etc/prx-waf/tls/cert.pem -text -noout | grep -A1 "Subject Alternative Name"クラスターノードが接続できない
症状： ワーカーノードがクラスターに参加できない。ステータスに「disconnected」ピアが表示される。
解決策：
- クラスターポート（デフォルト：UDP 16851）でネットワーク接続を確認：
# From worker to main
nc -zuv node-a 16851- ファイアウォールルールを確認 -- クラスター通信はUDPを使用：
sudo ufw allow 16851/udp- 証明書を確認 -- すべてのノードは同じCAで署名された証明書を使用する必要があります：
openssl verify -CAfile cluster-ca.pem node-b.pem- ワーカーノードのシード設定を確認：
[cluster]
seeds = ["node-a:16851"] # Must resolve to the main node- デバッグログでログを確認：
prx-waf -c config.toml run 2>&1 | grep -i "cluster\|quic\|peer"メモリ使用量が多い
症状： PRX-WAFプロセスが予想以上のメモリを消費する。
解決策：
- レスポンスキャッシュサイズを削減：
[cache]
max_size_mb = 128 # Reduce from default 256- データベース接続プールを削減：
[storage]
max_connections = 10 # Reduce from default 20- ワーカースレッドを削減：
[proxy]
worker_threads = 2 # Reduce from CPU count- メモリ使用量を監視：
ps aux | grep prx-wafCrowdSec接続の問題
症状： CrowdSec統合が「disconnected」を示すか、決定が読み込まれない。
解決策：
- LAPI接続をテスト：
prx-waf crowdsec test- APIキーを確認：
# On the CrowdSec machine
cscli bouncers list- LAPI URLを確認：
[crowdsec]
lapi_url = "http://127.0.0.1:8080"
api_key = "your-bouncer-key"- LAPIが到達不能の場合のための安全なフォールバックアクションを設定：
[crowdsec]
fallback_action = "log" # Don't block when LAPI is downパフォーマンスチューニング
レスポンスが遅い
- レスポンスキャッシングを有効化：
[cache]
enabled = true
max_size_mb = 512- ワーカースレッドを増加：
[proxy]
worker_threads = 8- データベース接続を増加：
[storage]
max_connections = 50CPU使用率が高い
アクティブなルール数を削減する。 不要な場合はパラノイアレベル3〜4のルールを無効化する。
未使用の検出フェーズを無効化する。 例えば、CrowdSecを使用しない場合：
[crowdsec]
enabled = falseヘルプの取得
上記の解決策で問題が解決しない場合：
- 既存のissueを確認： github.com/openprx/prx-waf/issues
- 以下を含む新しいissueを提出：
- PRX-WAFバージョン
- オペレーティングシステムとカーネルバージョン
- 設定ファイル（パスワードを伏せた状態）
- 関連するログ出力
- 再現手順