公開日: 2024年5月8日
社内サーバーにつながらないときの切り分け方：1台だけか、全員かを先に確認する
「サーバーにつながらない」という連絡だけでは、サーバーの故障なのか、端末やネットワーク、認証の問題なのかはまだ分かりません。インターネットを使えていても、社内の共有フォルダーや業務システムへ正常に接続できるとは限りません。
まず、同じことができる端末と、できない端末を比べます。この記事では、企業の担当者が影響範囲を整理し、管理者が次の調査先を決めるための確認方法を説明します。
対象は社内LANや組織のVPNから利用するファイルサーバー、社内Webシステムなどです。Windowsのコマンド例を載せますが、個別製品の復旧や設定変更を一律に案内する記事ではありません。
1. 最初に残すのは、エラーと影響範囲
画面のエラー全文、発生時刻、接続先の名前・URL・共有パスを記録します。画面を閉じたり再起動したりする前に残すと、調査担当者へ同じ情報を渡せます。
1台だけか、複数台か
- 1台だけ：その端末のLAN／Wi-Fi／VPN、接続先の指定、利用アカウント、直前の変更を先に確認する。
- 同じ部署や拠点だけ：共通のネットワーク経路や設定を確認する。
- 複数の部署・拠点：共通のサーバー、認証基盤、サービス側の状態も確認する。
この分類は調査範囲を絞る目安であり、原因の確定ではありません。複数端末に同じ更新が配布された場合など、端末側の要因が広い範囲に及ぶことも考えられます。
すべてのサービスか、一部だけか
「共有フォルダーは使えないが社内Webは開く」「ログオンはできるが特定アプリだけ失敗する」のように、できることも残します。利用できるサービスがあるなら、その通信まで止める操作を避ける判断にも使えます。
ずっと使えないのか、時々切れるのか
一時的な障害では、確認時には正常に見えることがあります。発生した時刻、続いた時間、直前の操作を記録してください。業務を止めるような負荷をかけて、無理に再現させる必要はありません。
2. 利用者が設定を変えずに確認できること
普段利用するネットワークに接続しているか、必要なVPNが接続済みかを見ます。来客用Wi-Fiなど、社内サーバーへの接続を許可していないネットワークに入っていないかも確認します。
接続先は、社内で案内された正しいURLや共有パスと照合してください。古いショートカットやお気に入りだけで確認しないことも大切です。
Webシステムの場合、別の対応ブラウザーやプライベートウィンドウとの比較が、端末内の状態を調べる手掛かりになる場合があります。ただし、プライベートウィンドウではログイン状態が引き継がれないことがあります。そこで開けないことだけで、サーバー障害とは判断しません。
証明書や安全性の警告が表示された場合は、警告を無視して進まず、時刻と画面を管理者に伝えます。パスワードを何度も試したり、ネットワーク設定を自己判断で変更したりしないでください。
3. 管理担当者向け：確認する層を分ける
管理者は、端末の接続設定、名前解決、対象サービスへの通信、認証・アプリケーションの順に、何が確認できたかを整理します。以下は設定を書き換えない確認例です。ただし名前照会や接続試験の通信は発生するので、組織の運用ルールに従い、管理対象の接続先だけを調べます。
端末のネットワーク設定を見る
ipconfig /all利用中のアダプター、IPアドレス、既定のゲートウェイ、DNSの参照先などを確認します。正常端末と比較するときは、同じ拠点・接続方法かも揃えて考えます。VPNや複数アダプターがある場合は、先頭の設定だけで判断しないでください。
DNSを外部の公開DNSへ変更したり、IPアドレスを適当に固定したりせず、設計された値と違いがあるかを確かめます。Microsoft：ipconfig
接続先の名前が、意図したアドレスに解決されるか
Resolve-DnsName -Name server.example.internal -DnsOnlyserver.example.internal は説明用です。管理者が確認した実際の接続先名へ置き換えます。
失敗した場合は、名前の誤り、DNS参照先、VPNを含む経路などを確認します。成功しても、そのアドレスのサービスが動作しているとは分かりません。返されたアドレスが正しいか、構成情報と照合します。Microsoft：Resolve-DnsName
対象のTCPポートに接続できるか
次はHTTPSをTCP 443で提供していると確認できたシステムの例です。
Test-NetConnection -ComputerName server.example.internal -Port 443 -InformationLevel Detailedポート番号は対象サービスの設計に合わせます。分からないまま広い範囲のポートを調べたり、機器の許可設定を変更したりしないでください。
TcpTestSucceeded : True：表示された接続先へのTCP接続は成立しています。Webの画面表示、ログイン、データ処理までは保証しません。TcpTestSucceeded : False：その端末からの接続が成立していません。接続先の稼働・待受状態、経路、VPN、ファイアウォールなどが確認対象です。
接続先アドレスと使用したインターフェースも残します。「想定した経路で試験したか」を担当者が確認できます。Microsoft：Test-NetConnection
Pingだけで正常・異常を決めない
Pingが確認するのはICMPによる応答です。業務アプリケーションやファイル共有への接続確認とは別なので、応答があっても業務が使えるとは限りません。応答を許可していない環境では、返答がなくても対象サービスへ接続できることがあります。Microsoft：pingの仕様
4. ここまでの結果を、次の担当者へつなぐ
確認の目的は、無理に一人で原因を確定することではありません。どの段階まで確認できたかを共有すると、調査の重複を減らせます。
- 名前解決に問題がある：端末とDNS・ネットワークの担当者へ、照会した名前と結果を渡す。
- TCP接続が成立しない：サーバーとネットワークの担当者へ、接続元・接続先・ポート・時刻を渡す。
- TCP接続は成立するが利用できない：サービスの担当者へ、画面のエラー、対象ユーザー、時刻を渡し、認証やアプリケーションのログと照合する。
- 電源や起動自体に問題がある：サーバーが起動しないときの確認へ進む。
Windowsの共有フォルダーならファイルサーバー編、ドメインのログオンや認証ならActive Directory編で確認項目を分けています。
5. 再起動や設定変更の前に確認すること
再起動が必要な場面はあります。ただし、対象機器に依存する業務、取得しておくログ、判断する担当者を整理してから行います。
変更は一度に複数の設定を変えず、変更前の値、実施時刻、結果、戻す方法を残します。ファイアウォールの全面停止や権限の一括緩和は、通常の切り分け手順にしません。
復旧後は管理画面へ入れることだけでなく、影響を受けた利用者が必要な業務操作を行えるかを確認します。一時的な回避策で戻した場合は、未解決の課題も記録してください。
そのまま使える状況共有メモ
- 発生時刻・継続時間：
- できない業務・できる業務：
- 影響する端末・利用者・拠点：
- 接続元のLAN／Wi-Fi／VPN：
- 接続先の名前・サービス：
- エラー全文・コード：
- 直前の変更：
- 名前解決・TCP接続の結果：
- 実施済みの操作と結果：
- 次に確認する担当者・項目：
分からない欄は不明のままで構いません。構成やログを外部へ渡すときは共有先と方法を確認し、パスワードや機密データを不用意に添付しないでください。
ソルブネオへ相談する際も、症状と確認済みの情報を整理することで、原因を特定できていない段階から状況を共有できます。相談する