Slack の通信はなぜ slack.com と CDN に分散しやすいか
Slack の Web クライアント・デスクトップ（Electron）・モバイルは、画面上は単一アプリに見えますが、裏ではワークスペースのメタデータとメッセージ API用の slack.com 系と、絵文字・画像・ファイルのサムネイルなど静的・準静的コンテンツに割り当てられた slack-edge.com などのホスト、場合によっては音声・画面共有や認証周りの別名へ短時間に分散します。ここが異なるストラテジ・異なる地域ノードに割れると、UI の一部だけが TLS タイムアウトや低速に見え、表向きは「ずっと読み込み」のスピナーになります。モデル倉庫と CDN 分流 で書いたとおり、CDN という語だけではホスト集合は一致しません。Slack 専用に SLACK_COLLAB のようなストラテジを一つ決め、MATCH より手前に明示ルールを置くのが再現性を上げる近道です。
ノードの地理的出口も絡みます。メッセージ用とファイル用が別リージョンに乗ると、一覧は速いが開いたスレッドだけ遅い、といった部分的成功に見えます。まずは同一ストラテジに束ね、それでも通話だけ不安定なときは UDP／TUN の境界を TUN 記事 と併せて切り分けます。
典型症状：ワークスペースは開くが添付や通話だけ不安定
目立ちやすい例は次の通りです。(1) ログインやワークスペース一覧は通るが、チャンネルを開いた瞬間の履歴取得だけが終わらない。(2) メッセージは見えるが、画像・PDF・動画のインライン表示だけが灰色のまま。(3) ハドルやビデオ通話だけが切断・再接続を繰り返す。(4) ブラウザでは問題なくデスクトップだけおかしい——というときは OS のプロキシ経路と Electron の実流量のズレを疑います。失敗直前のログから SNI（接続先ホスト名）を抜き、(a) slack.com 名義、(b) slack-edge／ファイル配信、(c) 音声・RTC 系、(d) 社内 SSO／IdP に大まかに分類すると、ルール追記の優先度が付けやすいです。
slack.com／アプリ・API・リアルタイム層
出発点として DOMAIN-SUFFIX,slack.com を SLACK_COLLAB 向けポリシーに載せます。ワークスペース URL は *.slack.com、API／イベント／リアルタイム接続は時期と機能でサブドメインが増えるため、公開リスト一発より自分の組織で実際に出た FQDN をルールへ追記する運用が安全です。Enterprise Grid ではワークスペースごとに名前空間が増えることがあり、固定サンプルだけでは漏れやすい点には注意してください。Microsoft 365 と併用する職場では、Teams と Slack のドメイン束を取り違えないよう、ストラテジ名を分けておくと運用が楽です。
slack-edge・ファイル・静的アセットの束ね方
アイコン・絵文字・一部プレビューで一般的なのが slack-edge.com などエッジ／CDN 側のホストです。本体 API は速いがエッジだけ別出口に落ちると、チャット本文は出ているのに見た目だけ欠ける状態に見えます。ファイル共有やアップロード先が files.slack.com 系や一時 URL に分かれる場合も、同じ SLACK_COLLAB にログで確認した範囲で足していくのが無難です。amazonaws.com や cloudfront.net を丸ごと同一ポリシーにすると他サービスまで寄るため、Notion／AWS 束と同様、実際に Slack 操作中にだけ増える FQDNを優先してください。
エンプラ：SSO と Splunk 等の連携ホスト
エンタープライズでは SAML／OIDC の IdP、監査ログのエクスポート、あるいは Splunk など SIEM とのコネクタが API 経由で追加ホストを叩くことがあります。ここがメインの slack.com 束から漏れると、「アプリは動くが監査連携だけ失敗」など周辺機能だけが不安定に見えます。連携用ドメインはプロダクト改版で変わりやすいので、ドキュメントより失敗ログの SNIを信頼し、必要なら別ストラテジに切り出してください。
ブラウザとデスクトップ（Electron）で経路が変わるとき
ブラウザ版は OS のシステムプロキシ設定を読みやすい一方、デスクトップアプリは TUN でしか拾えないパスがあることがあります。クライアント選定 と TUN の深掘り を参照し、ブラウザのみ／TUN 有りで A/B してください。音声・画面共有は UDP が絡むため、一般的な HTTP プロキシだけでは取りこぼすケースがあります。macOS では他 VPN やシステム拡張との競合もあり得るため、必要なら macOS TUN 記事も併読ください。
ルール例：SLACK_COLLAB 用ストラテジへ集約する
狭い DOMAIN や Slack 向け rule-providers を、巨大 GEOIP／ストリーミング／一般 AI 向け MATCH より手前へ。グループ名 SLACK_COLLAB_STABLE には、レイテンシと契約上許される地域に合うノード（企業方針での DIRECT を含む）を割り当てます。以下は概念例です。本番前に必ず接続ログで照合し、自組織の IdP 名や音声ホストを足してください。
rules.yaml（例：概念のみ／本番は検証のうえ調整）
# Slack workspace + edge CDN bundle; place BEFORE broad MATCH / GEOSITE lists
rules:
- DOMAIN-SUFFIX,slack.com,SLACK_COLLAB_STABLE
- DOMAIN-SUFFIX,slack-edge.com,SLACK_COLLAB_STABLE
- MATCH,PROXY_OR_DEFAULT
files.slack.com などは slack.com サフィックスで拾える一方、実ログに別トップレベルドメインが出た場合のみ個別の DOMAIN-SUFFIX を足してください。slack-edge.com を広く取ると意図しないホストまで同一ストラテジに乗ることがあるため、必要ならログで狭めるか process-name（Windows 等）と併用して衝突を減らしてください。
Notion／Discord／M365 束との棲み分け
Notion や Discord 向けに整えたルール集合を、Slack 用にそのまま貼り替えないでください。協業ツール同士でもホスト名は別物です。体感としては「本体と CDN の二段がズレる」ところは似ていますが、ドメイン表はコピー不可です。
システムプロキシ・TUN と取りこぼし
ブラウザとデスクトップで症状が分かれるときは、システムプロキシと TUN のどちらが実流量を握っているかを先に揃えます。SwitchyOmega など拡張で直 PROXY を指定していると二重中継になりやすく、Slack のような多接続アプリでは一部分だけタイムアウトに見えることがあります。
DNS、fake-ip、証明書エラーに見えるズレ
fake-ip とブラウザ DoH が二重だと、ルールが想定する名前解決と実 TLS の SNI が食い違い、証明書エラーや無限リロードに見えることがあります。Clash Meta の DNS 設定を一か所の前提に揃え、Slack 関連ホストを fake-ip-filter に追加するかどうかは、手元のクライアントと照合してください。IPv6 のみ直進する場合は IPv6 二重スタックの整理も有用です。
許可された利用の前提で押さえるチェック
- このネットワークで Slack を Clash 経由で利用することが方針上許可されているか確認する。
- 失敗行の FQDN を列挙し、slack.com 本体／slack-edge・ファイル／RTC／IdP の層に分ける。
SLACK_COLLAB束がMATCHより前にあり、広告ブロッカー等の REJECT と衝突していないか確認する。- ブラウザのみ・TUN 有り・デスクトップのみで A/B し、取りこぼしを切り分ける。
- Clash DNS／fake-ip とブラウザ DoH の二重構成を解消する。
- ルールと購読の更新取得が、不安定なチェーンに乗っていないか確認する。
操作ごとの短いログ断片を残すと、設定全体の入れ替えより早く、どの層の出口が揃っていないかに辿り着けます。
まとめ
Slack の「ワークスペースやファイルがずっと読み込み」は、単一ノードの遅延だけには還元できないことが多く、slack.com 周辺と slack-edge など CDN 側の出口ずれとして説明しやすいです。Clash で SLACK_COLLAB 向けストラテジに束ね、TUN と DNS を揃えれば、多くのケースは経路の部分ずれとして切り分けられます。他 SaaS 向けルールセットと混同しないことが長期運用の鍵です。
→ 方針が固まったら、Clash を無料ダウンロードし、Slack 用の小さなサブプロファイルで試し、ライブ接続に出た FQDN を都度足していくのが近道です。止まっていたスピナーを、本来のコミュニケーションに戻せます。