SaaS セキュリティ

Netskope導入後にアプリケーションが動かない？トラブルシューティング

投稿日 2025.12.16
Netskope よくあるお問い合わせ

こんにちは〜！セキュリティチームの佐藤です。

Netskopeに関するお問い合わせに関して、

「Netskopeを有効にすると、特定のクラウドサービスにログインできない！」
「昨日まで使えていたSaaSが突然エラーで開けなくなった！」

といった認証周りのトラブルを本当によくご相談いただきます。

なのでこのブログは、過去にブログでご紹介した手順をより詳細により分かりやすくお届けします。

過去記事：Netskopeを利用するとクラウドサービスの認証がうまくいかない場合のトラブルシュート

急いで除外に関する手順を知りたい方はStep 4をご覧ください。

注意事項

本ブログの内容は、 2025年12月16日時点の情報に基づいております。クラウドサービスの仕様変更などにより、記載内容が将来的に変更となる可能性がございます。最新の情報となるよう努めてまいりますが、あらかじめご了承ください。

トラブルシューティングの全体像（フロー）

【Step 1】事象の切り分け
【Step 2】ログの取得
【Step 3】原因（FQDN）の特定
【Step 4】原因（FQDN）に対する例外設定の適用

このような流れで対応していきます。

事象が発生する要因について

Netskopeは通信内容を可視化・制御するために暗号化されたHTTPS通信は復号化し、その後にNetskopeが発行する独自の証明書を用いて通信が再暗号化されます。

この復号化と再暗号化の処理がクラウドサービスによっては正常に動作しない事象を引き起こす場合があります。

また、そもそもNetskopeのデータセンターを経由すること自体が原因で正常に動作しない場合があります。

（注記：クラウドサービスの仕様や設定により、詳細な状況や対応策は異なります。）

なお、「Netskopeを経由することで、動作に支障が出る」とNetskope社で確認されている特定のクラウドサービスについては、初期導入時から規定（デフォルト）で通信の例外設定（Exception）が適用されています。

また、Netskopeがインライン（CASB または Web 用）で展開されている場合に、一部のCLIツールが動作しない事象は、Netskopeコミュニティサイトにて既知の事象として記載されています。

If Netskope is deployed inline (for CASB or Web), some CLI tools will not work because they use certificate bundles distributed with those tools (i.e. Python distribution, for example), and they do not access system certificate store where Netskope client installs Netskope root CA. The guidance below will allow you to enable those tools to seamlessly work with Netskope SSL interception.

https://community.netskope.com/next-gen-swg-2/configuring-cli-based-tools-and-development-frameworks-to-work-with-netskope-ssl-interception-7015

これらのCLI ツールがNetskope署名証明書を信頼するには、Netskope証明機関（CA）を信頼するように設定する必要があります。
具体的な設定手順は、Netskopeコミュニティサイトにて詳細に解説されています。ぜひご活用くださいね。

トラブルシューティング手順

事象の切り分けについて事象が発生したユーザー側で行う作業、Netskope運用担当者側で行う作業をまとめました。

事象の報告（何時何分に起きたか、どんなエラー画面が出たのか）などを情報共有
事象の切り分け
Netskope clientログの取得
設定完了後の動作確認

ユーザー側からの担当者への情報共有をいただく際には、「繋がらなくなった」という報告だけではなく「その事象は何時何分に起きたか」や、エラーが出た場合は画面のスクリーンショットを取得してもらい、視覚的にどんなエラー画面が出たのかを把握することで、その後の対応がスムーズになりますよ！

【Step 1】事象の切り分け

Netskope オン/オフ確認

そもそも発生した事象がNetskopeで起こったものか、それともアプリケーション側で起こっているのかを確認するために、Netskopeをオフにした状態で発生するかを確認します。

Netskopeのアイコンをクリックして「Disable All Client Services」を選択すると無効にできます。

なお、有効にする場合は同じように「Enable All Client Services」を選択すると有効にできます。

オフにした状態でも発生してしまう場合は、アプリケーション側で事象が発生している可能性が高いためアプリケーション側の設定などを確認ください。 Netskopeがオンになっている状態でのみ事象が発生する場合にはNetskopeで後続の手順に沿って対応することで解消することが期待されます。

ただし企業によってはNetskopeを端末側ではオフにできないように設定している場合があります。
その場合は管理コンソール上からオフにしましょう。
Settings > Security Cloud Platform > Devices より対象のデバイスをDisableにできます。

管理コンソール上からNetskopeをDisable（無効）にした場合、端末側でEnable（有効化）することはできません。必ず管理コンソール上からEnableに設定する必要があります。

端末のIPv6設定を無効化する

Netskope Private Access (NPA) は現状、IPv6トラフィックをサポートしておりません。この制限により、事象が発生するケースが確認されています。

Netskope Private Access doesn’t support IPv6 traffic. For IPv6 DNS queries over TCP, if the hostname in the DNS query is a Private App, the Netskope Client will block the DNS request.
https://docs.netskope.com/en/ipv6-traffic-steering

他にも、NetskopeとIPv6環境の組み合わせにおいて一部のサイトに接続できない、またはサイトの一部が正しく表示されない場合があるため、端末のIPv6設定をオフにした状態で事象が改善されるかをご確認ください。

無効化の方法は、お使いの端末やOSのバージョンによって手順が異なります。あらかじめご了承ください。

IPv6の無効化手順（Windows11）

コントロールパネル > ネットワークと共有センターを開きます。
アダプターの設定の変更またはネットワーク接続の管理に進みます。
設定を変更したいネットワーク接続デバイスを右クリックし、プロパティを選択します。
一覧にあるインターネットプロトコルバージョン 6 (TCP/IPv6)のチェックボックスをオフにします。

IPv6の無効化手順（Mac）

Macでは、ターミナル（CLI）からネットワーク設定コマンドを用いて無効化を行います。

ターミナルを開きます。
networksetup -setv6off Wi-FiでEnterを押すとOFFにできます。

実行後、無効化完了などのメッセージは表示されませんので、状態を確認する際は、networksetup -getinfo Wi-Fiを使用します。
出力結果のIPv6の部分がOffになっていれば、設定は完了です。

再度有効に戻す際は、networksetup -setv6Automatic Wi-Fiを入力し、Enterキーを押します。

下の画像は、IPv6を一度オフにして再度オンにした時のそれぞれの状態を確認したものです。

参考： Appleサポート公式情報（https://support.apple.com/ja-jp/guide/remote-desktop/apdd0c5a2d5/mac）

IPv6の停止手順（iOS）

注意事項

iOSの「設定」で直接IPv6を無効化する公式な機能や手順は提供されていません。この方法はIPv6の利用を停止させるための間接的な手段であり、OSレベルでの無効化（OFF）ではありませんのでご了承ください。

この設定は、接続先のWi-Fiネットワークごとに個別に行う必要があります。

手順:

設定アプリを開く
Wi-Fiを選択
現在接続中のWi-Fiの横にある情報ボタン（iマーク）をタップ
DNSを構成を選択
設定を手動に変更
リストからIPv6 DNSのエントリを削除します。

【Step 2】ログの取得方法

ログの取得にはデバイス側での取得と管理コンソール上での取得があります。管理コンソール上での取得の場合は、ログの取得完了後にTenant Admin宛にメール通知が行われる関係上、Tenant Admin権限を持った方での操作を推奨します。

参考：https://docs.netskope.com/en/devices#collect-logs

ログ取得時の3つの鉄則

鉄則1：事象が発生した当日中または再現日の当日に取得する
ログは原則として事象発生当日または再現させた日の当日中に取得してください。時間が経過すると対象のログが上書きされて確認ができなくなるためです。
鉄則2：「Info」モードで取得する
「Debug」モードはログが膨大かつFQDNの特定に不要な情報を含みすぎるため、対象のFQDNが探しにくくなります。「Info」モードで必要な情報を取得しましょう。
- Security Cloud Platform > Client Configuration > 対象のClient Configurationの右にある３点マークをクリックしEditをクリック。Install & Troubleshootタブの下にあるLog Levelで変更できます。
鉄則3：再現時は必要のないタブを閉じる
ログには関係ない通信も大量に含まれます。可能な限り、他のアプリケーションやブラウザのタブを閉じてから事象を再現させ、事象に関係のないログを発生させないようにしましょう。

端末でのログ取得方法

Netskopeクライアントのアイコンを押し「Save logs」を押すと保存先が出てきます。保存先を指定してsaveを押すとログの取得ができます。

Log bundle created！の表示が出れば取得完了です。

iOS端末でのログの取得方法

Netskopeのアプリを開く > 右上の歯車アイコンを選択 >「Share Log」を選択
メールなどでログを他デバイスに送信することで取得が可能です。

管理コンソールでのログ取得方法

Settings > Security Cloud Platform > Devices より対象のデバイスを選択します。

「Collect Log」ボタンを一度クリックすると、ログの収集処理が開始されます。この処理が始まると、ボタンがグレーアウトの状態になります。

ログの収集処理が完了すると、Netskopeのテナント管理者宛にメールで通知が届く仕組みとなっております。「Download Log」 を押して取得しましょう。

なお、完了の通知が届く前に「Download Log」を押した場合には、「Log has not been collected」（ログが収集されていません）というエラーメッセージが表示されます。

【Step 3】原因（FQDN）の特定 (ログの分析)

取得したlogの中にあるnsdebuglog を開きます。場合によってはnsdebuglog1 やold.nsdebuglog という表記でログが複数分かれている場合もあります。

再現した時刻のログを見てどのFQDNが原因かを特定します。

Netskopeを経由している通信：調査対象

Action: Tunnel またはtunnel

Netskopeを経由している場合はtunnelと表示されます。疑わしいFQDNを特定するにはこのログの host: の次にある値を確認します。

2025/11/06 15:34:38.421958 stAgentNE p877 t15683 info ExceptionMgr.cpp:1316 ExceptiontMgr 298: Host: blog.cloudnative.fqdn.sample.co.jp, CatId: 547, Action: Tunnel
2025/11/05 12:40:29.981215 stAgentNE p2469 t24651 info tunnel.cpp:1148 nsTunnel TLS [sessId 502] Tunneling flow from addr: x.x.x.x:xxxxx, process: google chrome helper to host: blog.cloudnative.fqdn.sample.co.jp, addr: x.x.x.x:443 to nsProxy

Netskopeを経由していない除外された通信：調査対象外

Action: Bypass またはbypassAppMgr

Netskopeを経由していない場合はBypass と表示されます。このFQDNはすでに対処されているので新しく調査対象から外します。

2025/11/06 12:40:33.216841 stAgentNE p877 t15683 info ExceptionMgr.cpp:1316 ExceptiontMgr 298: Host: blog.cloudnative.fqdn.sample.co.jp, CatId: 547, Action: Bypass
2025/11/05 12:40:56.253920 stAgentNE p2469 t30255 info bypassAppMgr.cpp:1622 BypassAppMgr bypassing flow to exception host: blog.cloudnative.fqdn.sample.co.jp, process: wdavdaemon_enterprise, Dest IP: x.x.x.x, Dest Port: 443, Src IP: x.x.x.x, Src Port: x

FQDNを特定するときにこのドメインが関係あるかな？と目星をつけるのが難しい方はApp Catalogにあるアプリのドメイン欄からヒントを探すといいでしょう。

アプリケーション名でログ内を検索してみるのもいいかと思います。サービスによっては推奨のFQDN除外のリストをサービス元のヘルプページなどで公開している場合があります。そのFQDNのドメインの後方部分のみを抽出して探す方法もあります。

また、特定のURLが開かない場合については「https://」の後のドメインでログ内を検索するといいでしょう。
例： https://blog.cloudnative.fqdn.sample.co.jp であれば blog.cloudnative.fqdn.sample.co.jp の部分をログで検索してみるなど。

【Step 4】FQDNの除外設定の適用

はじめに注意

以下の設定を適用するとNetskopeの機能を使ったクラウドサービスの監視・制御が一部できなくなります。
「事象解消に本当に必要なFQDN」だけを特定し、除外設定することをお勧めします。

除外設定には以下の３パターンの方法で除外が可能です。

SSL Decryption Policy の設定

SSL Decryption Policy を使用すると、設定されたFQDNはNetskopeのデータセンターを経由するもののHTTPS通信は復号化されずに暗号化したまま通信させることができます。そのため、Exceptionでの除外よりはNetskopeで経由する分取得できる情報は多いため、まずこのポリシー設定で事象が解消するかをお試しいただくことをお勧めします。

CERTIFICATE PINNED APPSを使った例外設定

アプリケーションを証明書固定アプリケーションの例外として追加することで、そのアプリケーションからの通信をNetskopeで経由せず除外されます。Netskopeが定義済みの証明書固定のアプリケーションの他にカスタムのアプリを作成して、特定のアプリケーションで特定のドメインを使用するプロセスのみを除外することが可能です。

該当FQDNの例外設定

該当のドメインをNetskopeで通信を経由しないように設定できます。この設定を行ったFQDNはNetskopeを経由しないということになりますので、最小限の範囲かつ最小限のFQDNを設定することをお勧めします。

この３つの除外設定方法について記載していきます。

なお、SSL Decryption Policyの説明の中にも記載しておりますが、１つ目の手段であるSSL Decryption Policyを設定することで事象が解消するものに対して２や３の手段のExceptionでの除外を行うことは推奨しません。

SSL Decryption Policy の設定

Policies > SSL Decryption よりポリシーを作成します。

SSL Decryption Policyでは証明書名（CN）やサブジェクト代替名（SAN）での除外はできません。また、ドメイン一致基準としてワイルドカードドメイン（例：*.example.com）を用いた設定は可能ですが、その他の正規表現文字はサポートしていません。

Netskope supports domain names based on server name indication (SNI) and not certificate name (CN) or subject alternative name (SAN). Netskope supports using wildcard domains (e.g., *.example.com) for the Domains match criteria, but no other regex characters are supported.

引用元：https://docs.netskope.com/en/add-a-policy-for-ssl-decryption-2

CERTIFICATE PINNED APPSを使った例外設定（Exception）

Settings > Security Cloud Platform > App DefinitionよりCertificate Pinned Appsのタブより例外設定を行うアプリを定義していきます。

New Certificate Pinned Applicationよりプラットフォーム（WindowsやMacなど）を指定し、特定のアプリケーションプロセス(例：test.blog.cloudnative.fqdn.exe ）を除外します。

なお、プラットフォームが複数ある場合は＋ADD PLATFORMより追加できます。

これで特定のアプリケーションプロセスの定義ができました。

続いて、除外設定を行います。

Settings > Security Cloud Platform > Steering Configurationより除外設定を行うConfigurationを選択しExceptionsタブを開きます。

除外するドメインを記載し、設定しましょう。

Tips

CERTIFICATE PINNED APPSを使った例外設定ではワイルドカード表記での除外設定はできません
参考：https://docs.netskope.com/en/adding-exceptions#certificate-pinned-applications

ドメインの除外は、親ドメイン（例：cloudnative.fqdn.sample.co.jp ）を指定することで、そのサブドメイン（例：a.blog.cloudnative.fqdn.sample.co.jp ,blog1.cloudnative.fqdn.sample.co.jp）も包括的に除外することが可能です。

記載例

a.blog.cloudnative.fqdn.sample.co.jp やblog1.cloudnative.fqdn.sample.co.jp をまとめて除外したい場合
◯　cloudnative.fqdn.sample.co.jp
✖️　*.cloudnative.fqdn.sample.co.jp

なお、その下のACTIONSにあるAdvanced Optionsを有効にすると、Windowsは設定したFQDNをNetskopeでは経由させないが、Macでは経由させるといったカスタム設定が可能です。

iOS 端末に対する Certificate Pinned Apps を使った「プロセス対象のアプリ除外」は、Netskopeの仕様上サポートされていません。
iOS 端末は個別のアプリ(Netskope Unified app)から他のアプリケーションのプロセスの取得ができません。iOS端末を対象にCertificate Pinned Appsでの設定を行った場合はiOS端末に対してのみにdomain exceptionする挙動になります。

該当FQDNの例外設定（Exception）

Settings > Security Cloud Platform > Steering Configurationより除外設定を行うConfigurationを選択しExceptionsより設定します。

New ExceptionよりDomainを選択します。

なお、こちらの設定では「*」のワイルドカード表記が可能です。

設定を行った上で、事象が再現するかをご確認ください。再現してしまった場合は事象が再現した時間を記録した上で再度ログを取得し、他にないか探して試行します。

補足：範囲の広いFQDNの除外を推奨しないのはなぜ？

トラブル発生時、つい「当てはまりうるFQDNを全部除外しよう」と安易な対応を取りがちです。しかし、そのアプローチは推奨しません。

そもそもNetskopeを導入する目的や経緯は何でしたか。

会社としての運用方針や規定に従って『様々なアプリやサービスを適切に制御し、可視化する』ためなどではないでしょうか。

必要以上に広範な除外設定を行えば、確かに目の前の認証エラーはすぐに解消されるかもしれません。しかしその分Netskopeの可視化・制御できる範囲が大きく減るのも事実です。

手間がかかってもログを分析し、「本当に必要なFQDN」だけを特定することが不可欠だと思っています。

まとめ

Netskope導入後によくあるお問い合わせの一つである「Netskopeを経由するとうまく動かない！」に対するトラブルシュート手順をご紹介いたしました。

この記事でご紹介した通り、トラブルシューティングは少し手間がかかりますが、「事象を解消するために必要なFQDNだけを見つけ出す」ことは重要なプロセスです。

「広範囲でドメインを除外しちゃえ！」と手を抜きたくなる気持ちもわかりますが、それではNetskopeを導入した意味がなくなっちゃいます。

手間を惜しまずログを確認し、必要最小限の除外設定に留めることで、Netskopeの持っている可視化・制御のパフォーマンスを下げすぎることなく活用できます。

このトラブルシューティングブログが、Netskope運用のお役に立てれば嬉しいです。

困ったことがあったら、いつでもこの手順を思い出してくださいね！

参考資料

Hitomi Sato

セキュリティチームの佐藤です！名古屋市在住。20年以上大阪で過ごすも大阪弁＆関西弁を全くマスターできずイントネーションだけ関西弁です。好きなアニメは名探偵コナン、好きなゲームはFGO。一児の母。

記事一覧

Netskope導入後にアプリケーションが動かない？トラブルシューティング