認証プロキシ環境でVSCodeとAcrobat Reader DCの通信先を調べた話
認証プロキシが必須の環境だと、アプリごとに通信許可を通す必要があり、地味に面倒です。
特に
- VSCode
- Acrobat Reader DC
あたりは裏でいろいろ通信しているため、「どこに接続しているのか分からない問題」にぶつかります。
そこで、実際に通信先を調べてみました。
調べ方（ESETを使う）
変なツールを入れたくなかったので、既存のセキュリティソフトの機能を活用。
今回は ESET を使いました。
手順
- ESETを開く
- 左メニュー「ツール」
- 「その他ツール」
- 「ネットワーク接続」を開く
ここで、現在の通信一覧が確認できます。
- VSCode →
Code.exe - Acrobat →
AcroRd32.exe
それぞれを展開すると、接続先が見えます。
VSCodeの通信先
Visual Studio Code の通信先はこんな感じでした。
前回
- 13.107.6.175:443（visualstudio.com）
- 104.42.78.153:443（*.azurewebsites.net）
今回
- 117.18.232.200:443
- 104.42.78.153:443
- 13.107.6.175:443
- 23.101.203.117:443
- 192.229.232.200:443
気づき
- Microsoft系（Azure / Visual Studio関連）は安定して登場
- ただしIPは変わる
- CDNっぽい接続も混ざっている
👉 IP固定で許可するのはほぼ無理
Acrobat Reader DCの通信先
Adobe Acrobat Reader DC の通信先はこちら。
前回
- 104.79.33.4:443（*.adobe.com）
- Akamai CDN（deploy.static.akamaitechnologies.com）
今回
- a96-16-200-223.deploy.static.akamaitechnologies.com:443
- 104.78.187.10:80
- 54.236.178.223:443
- 52.86.255.153:443
- 104.79.33.4:443
- a96-16-200-5.deploy.static.akamaitechnologies.com:443
気づき
- Adobe本体 + CDN（Akamai）がメイン
- AWSっぽいIPも混ざる
- HTTP(80)通信も一部あり
「謎の接続先」の正体
一見すると「怪しい通信」に見えますが、整理するとこうです👇
正体パターン
- CDN（Akamaiなど）
- クラウド（Azure / AWS）
- アップデート配信サーバー
- テレメトリ（利用状況送信）
つまり、
👉 ほぼ全部「正常な通信」
ハマりポイントと対策
❌ よくある失敗
- IP単位でプロキシ許可
- 一度通ったIPだけ登録
→ 数日後に通信できなくなる
✅ 現実的な対策
1. ドメインベースで許可
*.visualstudio.com*.azurewebsites.net*.adobe.com*.akamai*
2. 認証プロキシ対応設定を入れる
VSCodeは設定可能
3. 例外ルールは「ざっくり」
細かく絞りすぎると運用が破綻する
まとめ
- VSCodeとAcrobatは裏でかなり通信している
- 接続先はクラウド + CDNで動的に変わる
- IP固定は非現実的
- ドメイン単位で許可が正解
余談（個人的な感想）
調べてみると、「怪しい通信」ではなく
👉 現代のアプリはクラウド前提で動いている
という当たり前の事実を実感しました。
昔みたいに「このサーバーだけ通信」ではなく、
CDNや分散環境に乗っているので、ネットワーク制御側の考え方もアップデートが必要ですね。
The following two tabs change content below.
フリーダム
金融系システムエンジニアが、業務効率化や日常の工夫を発信しています。
日々の作業を少しラクにするアイデアやツールを記録しています。
忙しい中でも役立つヒントになればうれしいです。
最新記事 by フリーダム (全て見る)
- Android個人開発、最後の壁は「テスター12人」だった話 - 2026-04-04
- 【保存版】テニススクールで学んだことまとめ｜3年間の気づきと上達のコツ - 2026-03-29
- OpenAIのAPIキーを使って利用する方法 - 2025-08-20
