piu lentoの日々

以前書いた、インターネットの謎やGoogleの迷惑(謎のドメイン "cache.google.com", すっっっごく迷惑な tunnel.googlezip.net!!!)のシリーズ。

ブログシステム移行や その後の経過観察をして居ると、いろいろな謎が見付かり、原因を調べると迷惑なことがあるし、原因不明で本当に謎のこともある。

※3つに分けた最後の稿。

1. インターネットの謎・迷惑 再び: Cloudflareの怪しいUA "bushbaby"
2. インターネットの謎・迷惑 再び(2): またもやGoogle、今度はgoogle-proxy。。。

faviconが連続アクセスされる謎

大きな問題では ないものの、なんか気持ち悪い。が、原因※が分からず対処出来て居ない。

※何となく、僕の小細工(後述の簡易アクセス記録)が悪い気がして居る。

現象

• favicon(/favicon.ico)にクエリ文字列でパスを付けて簡易アクセス記録※するようにしたところ、同じページへのアクセスの記録が連続することがある。
  • ※参照: [次期ブログサーバ] 新しいサーバ構成(CF Pages+R2 + Isso)で行こう。 (「アクセスログが見られない。 → 簡易アクセスログの仕組みを作った。」)
  • 簡易アクセス記録でのパスとクエリ文字列の例: /favicon.ico?__bt-log-acc__-/posts/50009/50009864/
• 連続する場合のアクセス回数は数十から数百回。
  • 回数は多いが、アクセス間隔は短くない(例: 約5回/秒)。 → レート制限に掛からない。
• 頻繁には起こらない(多くて数回/日)。
• 特定のプロバイダ(KDDI)からのアクセスで起こることが多いが、別のプロバイダ(例: J:COM)でも起こる。
  • そもそもKDDIからのアクセスが多いためか。

最初は攻撃かと思ってブロックしようと思ったが、見て居たら、(日本)各地から・複数のプロバイダからのアクセスで起こるし※、faviconだけアクセスしても余り効果的でないから違うと確信し、勇み足を せずに済んだ。

※DDoS攻撃なら あり得るが、上に書いたようにアクセス間隔が短くないので、それもない。

原因の推測と検討・試行結果

• ×? モバイルの移動などによるNWの切断などによる再取得?
  • 他のページ・ファイルでは連続アクセスは起こらないし(推測)、明らかに固定回線からと思われるアクセスでも起こったので、違うのではないか。
    • ただ、今は ほとんど どこでも固定とモバイルをサービスして居るので、実際にはモバイルなのかも知れない。
• × ブラウザのバグ
  • 今まで見た限りではChromeだけで起こって居る。
    • UAでは細かい版が分からないが、古い版では なさそう。
    • モバイル(Android)のChromeだけだった気がするが、確証はない。
  • 他のページ・ファイルでは起こらないし、そういう問題のニュースを見たことがないので違うのでは?
• ×? ブラウザの先読みによるもの。
  • 先読みするページごとにfaviconを読むが、クエリ文字列は全部同じになった?
  • ブラウザのアドオンの可能性もあり。
  • ただ、数百ページも先読みするとは考えにくい。
  • この場合は対処不可。
• ? faviconでアクセス記録しようとしたためのブラウザの誤動作
  • favicon.icoにクエリ文字列を付けるのが良くない?
    • ただ、ほとんどの場合には起こらないのが謎。
  • 試行: faviconでのアクセス記録を基本的に止めた。 → アクセス記録は連続しなくなったが、faviconの連続アクセスは起こる。
    • 試行概要
      • 基本的に、アクセス記録をJSで実行するようにした。
        • faviconと同様の処理をJSのfetchで行う。
          • faviconと区別出来るように、アクセスするファイル名を別にした。
          • 例: /bla?__bt-log-acc__-/posts/50009/50009864/
      • ただし、JS不可の環境では、以前と同様にfavicon.icoにクエリ文字列を付けてアクセス記録するようにした。
      • その関係で、JSの環境ではfaviconをJSで設定するようにし、JSでない環境では<noscript>に入れるようにした。
    • 依然として現象は起こるものの、随分減った気がする。
      • Cloudflare(以下、CF)のアクセスログを見るタイミングで起こって居ないだけかも知れない。
      • JSでのアクセス記録は連続しない。
• × faviconがページ本体と別ホスト(遅延が大きい)にあるため?
  • 上の試行と一緒に、faviconをページ本体と同じホストにした。 → 効果なし。 → 無関係

原因の推測2: faviconの設定の仕方が悪い。

上述のように、JSでない環境でfaviconを<noscript>に入れてクエリ文字列を付ける(全く普通でない)のが良くないのか、JSでfaviconを設定するのが良くないのか。

ただ、ほとんど起こらないので、faviconの設定の仕方は問題ないと考えるほうが妥当。

現状

faviconをページ本体と同じホスト(Cloudflare Pages)にした関係で完全なアクセスログが見られない※ため、問題が起こって居るかが分からず、試行錯誤出来ず、有効な対処を考えられず。

※制限付き(直近の約100アクセス)でCFのアクセスログが見られるので、そこに入って居れば(タイミングが合えば)分かる。

更に試すとすれば・・・

faviconを普通でない方法で設定するのが悪そうなので、以下にするのが良さそうだ。

• JS不可の環境でのアクセス記録を諦め、faviconの設定を全く普通にする(<noscript>に入れず、クエリ文字列を付けない)。
  • 現状ではfaviconでのアクセス記録は ほとんどないので、問題ない。
• 効果の確認のため、faviconをCF Pagesでないホスト(完全なアクセス記録が取れる)に置く。

※もし これでも現象が起こるなら、こちらには問題がなく、問題はアクセスする側(プロバイダやブラウザなど)にあることが確認出来る(ので、元のやり方に戻すことも出来る)。

書いて居て これが良さそうな気がして来たので、(やる気が出たら)試したい。

↓

(8/11 17:01) 実装した。faviconはコメントサーバ(coma.piulento.net)から取得するようにした。

作業中に気付いたのは、faviconにクエリ文字列を付けてアクセス記録する場合はブラウザでキャッシュされないため、特に連続アクセスが起こりやすいことである。ただ、JSでfaviconを指定した場合(クエリ文字列なし)にも連続アクセスが起こりやすいかは未確認である。

なお、JSでアクセス記録する場合は、ブラウザのキャッシュとサーバの状態をチェックするため(fetchのオプションは"no-cache")、繰り返しアクセスされた場合にはHTTP 304となる。

その後 (8/23 7:11)

上の作業後に問題は起こって居らず、効果があったようで、結局 僕がfaviconを「おかしな設定」(クエリ文字列を付けたり、<noscript>に入れたり)にしたのが悪かったようだ。

関係あるかどうかは不明だが、一度(数日に渡って)、Googlebotがレート制限に掛かったことがあった。ログではアクセス頻度は問題ない(通常どおり)ので原因不明だったが、CF側の問題なのかと思ってレート制限の設定をし直した(記述は異なるが、動作は同じ)ら起こらなくなった。全くの謎である。

多くの場合に問題ないのが腑に落ちないが、普通でないことをすると、数多くのクライアント(ブラウザ)・環境の どれかで駄目になることがあるというのは良くある話だ。

(2025/11/1 13:59 アクセスが多目なので、期限で非公開にならないようにした。; 2025/12/31 14:59 ブログシステムの移転でなく、新しい(現行の)システムに関することなので、カテゴリ「ブログシステム2025」を追加した。)