WordPress や Web サーバー（Nginx / Apache）のアクセス解析や 404 エラーログを見ていると、以下のような見慣れないリクエストが数百件単位で記録されていることがあります。
- リクエストパス:
/safeview-redirect/tc_frame.html - ステータス:
404 Not Found
「海外からの脆弱性スキャン攻撃か？」「改ざんコードが埋め込まれたのか？」と不安になりがちですが、実害のないアクセスです。
正体と原因の調べ方、そして Web サーバー側でログを一切汚さずにスマートに受け流す（204 No Content）設定を解説します。
犯人の正体：ウイルスバスター等のセキュリティ拡張機能
このリクエストの正体は、トレンドマイクロ社（ウイルスバスターなど）の Web脅威対策（Trend Micro Toolbar / Safe View） が内部的に使用する制御用フレーム（HTML）です。
閲覧者のブラウザに入っている拡張機能が、ページ内のリンクや接続先の安全性を裏でチェックする際、ローカルで処理されるべきパスがサーバーへの相対パスとして誤認され、Web サーバー宛てにリクエストが飛んでしまうことがあります。
- サーバーへの攻撃？: いいえ。単なる閲覧者側セキュリティソフトの空振りアクセスです。
- 放置するとどうなる？: 実害はありませんが、存在しないファイルを要求され続けるため 404 エラーログが大量に膨れ上がり、本当のエラーの発見を妨げる 要因になります。
事前確認：記事本文にゴミコードが残っていないか？
まれに、過去に記事を作成・編集した際、ブラウザの拡張機能が挿入した一時的な HTML（<iframe> 等）を誤ってコピー＆ペーストして記事内に保存してしまっているケースがあります。
念のため、サーバーのファイル内にこの文字列が存在しないか確認しておきます。
# WordPress ルートディレクトリ内で検索
sudo grep -rn "safeview-redirect" /var/www/何も出力されなければ、テーマやプラグインのファイル自体は正常です。
Nginx での対策：404 を出さずに「204 No Content」で無視する
404 エラーを返すと、WordPress が重い 404 テンプレートをレンダリングして負荷がかかり、ログも埋まってしまいます。
Web サーバー（Nginx）のレイヤーで直接捕捉し、「中身なしの成功（204 No Content）」を返しつつアクセスログ記録をオフ にするのが最もスマートな解決策です。
1. Nginx 設定ファイルの編集
サイトの設定ファイル（/etc/nginx/sites-available/...）を開き、server { ... } ブロック内に以下を追記します。
# safeview-redirect の空振りアクセスを無音で受け流す
location = /safeview-redirect/tc_frame.html {
access_log off;
log_not_found off;
return 204;
}2. 設定のテストと反映
sudo nginx -t
sudo systemctl reload nginx動作確認
ターミナルから curl でリクエストを送り、ステータスコードを検証します。
curl -I https://example.com/safeview-redirect/tc_frame.htmlレスポンスの 1 行目が以下のように返ってくれば完了です。
HTTP/2 204
server: nginx
...- 404 エラーがゼロになる
- アクセスログやエラーログに記録されない
- レスポンスボディを返さないためサーバー負荷や帯域消費もゼロ
まとめ
/safeview-redirect/tc_frame.htmlは Trend Micro 製品の機能による空振りアクセス（攻撃ではない）- WordPress 側で 404 を処理させず、Nginx 側で
return 204;とaccess_log off;を設定して遮断するのがベストプラクティス
コメント