会社のプロキシサーバーが「あるTwitterクライアント」に悲鳴を上げた話

こんにちは。今回は、今から10年以上前の2012年に、会社のオフィスネットワークで実際に起きた「とあるITインシデント（？）」について振り返ってみたいと思います。

当時、社内SEやネットワーク管理者、あるいはオフィスでこっそり情報収集のためにTwitter（現X）を開いていた人なら、「あぁ、そんなこともあったな……」と頭を抱えたくなるような、牧歌的でありながらも厄介だったトラブルのお話です。

2012年7月のある日、プロキシサーバーの通信ログを確認しました。すると、特定のIPアドレスから、異様な頻度で同一のファイルへアクセスが集中しているのを発見したのです。

ターゲットになっていたのは、社内ネットワークの自動プロキシ設定ファイルである proxy.pac（または wpad.dat） でした。

通常、proxy.pac はブラウザの起動時や、新しいドメインへの接続時に数回読み込まれる程度の軽いファイルです。しかしログを見ると、「数十秒〜数分おきに、特定のアカウントからひたすら proxy.pac を読み込み続けている」という、まるでDoS攻撃かのような異常な挙動を示していました。

原因を紐解いていくと、当時の「企業ネットワークの仕様」と「Twitterアプリの設計」、そして「時代背景」が最悪の形で噛み合ってしまった結果でした。

当時の人気国産Twitterクライアント（Tweenなど）の多くは、Windows（Internet Explorer）のネットワークコンポーネントである「WinINet」を利用して通信を行っていました。
この仕様のアプリは、インターネットにデータを送信する際、OSの「インターネットオプション」にあるプロキシ設定をそのまま参照します。会社が「自動構成スクリプト（PACURL）を使用する」にしていると、アプリは毎回律儀にそのURLへお伺いを立てに行く仕様になっていたのです。

2012年当時は、今のようにタイムラインが自動でヌルヌル流れるリアルタイム更新（UserStream）が、まだ一般に完全普及しきっていない過渡期でした。
アプリは「1分おき」「2分おき」に最新のツイートを自動でサーバーに見に行く（ポーリングする）必要がありました。さらに、当時は「1時間に150回まで」という厳しいTwitterのAPI制限があったため、ユーザーは制限ギリギリの頻度で更新設定を攻めていたのです。

さらにこの2012年7月〜8月頃というのは、Twitterの歴史において大きな転換点でした。Twitter公式が「API 1.1」への移行を発表し、サードパーティ製アプリへの締め付け（10万人ユーザー制限など）を開始した時期です。

開発者の方々もAPIの仕様変更への対応で手一杯であり、企業内の特殊なプロキシ環境で発生する「PACファイルの過剰読み込み」といった細かい挙動のバグ修正まで手が回りにくい、そんな混沌としたタイミングでもありました。

この「プロキシ連打事件」を解決するために、当時現場では以下のような泥臭い対策が行われていました。

今ではTwitterの公式Web版や公式アプリが主流になり、プロキシの自動設定もOSレベルで高度にキャッシュされるようになったため、こうした「アプリがPACファイルを連打して社内サーバーを重くする」というトラブルはほとんど見かけなくなりました。

2012年、会社のデスクで「なんかTwitterクライアントのカクつきが酷いな…」と悩んでいたあなた。それはあなたのPCのスペック不足ではなく、会社のプロキシサーバーとアプリが裏で必死に『proxy.pac』を奪い合っていたせいだったのかもしれません。

当時のインターネットの、少し不器用で、でもクライアントアプリの選択肢が豊富で楽しかった時代を思い出させる、懐かしいトラブルのお話でした。