どのポートを監視できますか？

1から65535までのすべてのTCPポートに対応しています。よくあるケース例：SMTP（25/587/465）、POP3（110/995）、IMAP（143/993）、データベースリスナー（PostgreSQL 5432、MySQL 3306、Redis 6379、MongoDB 27017）、SSH（22）、FTP（21）、カスタムアプリケーションポートなど。

モニターはサービスの正常性をチェックしますか？それとも接続可否だけですか？

接続可否のみです。モニターはTCP接続を開き、デーモンが受信するか確認します。プロトコルレベルのハンドシェイクは行いません。プロトコルを考慮したチェック（例：SMTPバナー検証、データベースクエリ応答）の場合、HTTPチェック（HTTPサービス用）やself-hostedハートビートエージェントをご利用ください。

ポートチェックのタイムアウトは？

デフォルトは10秒です。各モニターごとに設定可能です。もしTCP接続がタイムアウト時間内に確立しない場合、「connection timeout」で失敗扱いとなります。遠距離接続（例：欧州からアジアのサーバー監視）ではより長いタイムアウトが必要な場合があります。

UDPポートの監視は可能ですか？

現時点ではできません。UDPはコネクションレスなので、「接続受理」の概念がありません。UDPベースのサービスは通常、プロトコル固有のprobe（例：53番ポートならDNS問い合わせ、161番ならSNMP get）が必要です。その場合はハートビート監視などをご活用ください。

ポート監視でTLS/SSLの警告も検出できますか？

いいえ—ポートチェックは純粋なTCP到達性のみです。対象ポートでTLS証明書の検証もしたい場合は、URLにポート番号を含めたHTTPSチェック（例：https://api.example.com:8443/）をご利用ください。こちらでは到達性と証明書チェック両方を行います。

TCPポート監視 — データベース、メール、サービス

重要なサービスが待ち受けているか確認しましょう—ウェブサーバーだけではありません。あらゆるホストの任意のTCPポートを監視します。

HTTP以外：スタック全体の監視

ビジネスを支えるほとんどのサービスはWebサーバーではありません。データベースは5432（Postgres）、3306（MySQL）、27017（MongoDB）、6379（Redis）のようなポートで待ち受けています。メールは25、465、587、993、995を使います。SSHは22。ゲームサーバーは発行元が選んだポート。ファイアウォールの裏にある内部マイクロサービスは、プラットフォームチームが設定した何らかのポート。どれもHTTPで通信しません。どれもウェブサイトのアップタイムツールでは見えません。そして、どれかがリスニングを停止すると、目に見える何かが失われます。

ポート監視はこのギャップを埋めます。監視対象のホストとポートを指定すると、各チェック時にTCP接続を開き、サービスがリッスンしているかどうかを検証します。もし接続できなければ—デーモンが落ちた、ファイアウォールのルールが変わった、ホストがダウンした、ネットワークが障害を起こした—アラートが届きます。

監視できるサービス例

データベース：5432（Postgres）、3306（MySQL/MariaDB）、1433（SQL Server）、27017（MongoDB）、6379（Redis）、9042（Cassandra）、11211（Memcached）。
メールサーバー：25（SMTP）、465（SMTPS）、587（submission）、110（POP3）、143（IMAP）、993（IMAPS）、995（POP3S）。
リモートアクセス：22（SSH）、3389（RDP）、5900（VNC）。
ファイル転送：21（FTP）、990（FTPS）、445（SMB）、2049（NFS）。
カスタムや内部サービス：GraphQLゲートウェイ、gRPC、キュー（RabbitMQ 5672、Kafka 9092）、検索（Elasticsearch 9200、Solr 8983）、ゲームサーバー、IoTデバイスなど。

チェックの仕組み

モニターは、ホストとポートへ5秒タイムアウト付きの生TCP接続を張ります。SYN/ACKが返れば、ポートは到達可能でサービスがリッスン中、チェックは正常です。もし"connection refused"、タイムアウト、no routeなら、チェックは失敗し、カーネルエラー（「connection refused」「operation timed out」「no route to host」など）が記録されます—トリアージがしやすくなります。

モニターはアプリケーションレベルのプロトコル会話は行いません—SQLクエリやSMTP HELOを送りません。これによりチェックが高速かつ副作用なしで行え、1分ごとに100サービスを監視するときに重宝します。アプリケーションレベルの検証が必要なら、ポート監視をハートビートや独自のAPIモニターと組み合わせてください。

HTTPやPingとの組み合わせ

各パブリックサービスに3つのモニターを設けると明快な診断階層ができます。Pingはホストのネットワーク生存確認。ポート監視でサービスのリッスン状態。HTTP / API監視は正しい応答を確認。何かが落ちた場合、どの層で問題が起きているかわかります。HTTPだけ落ちていればアプリケーションのクラッシュ。ポートも落ちていればデーモンの問題。Pingも落ちていればハードやネットワークの消失です。

設定方法

ツールを開き、「モニター追加」をクリックし、「TCPポート」タイプを選び、ホスト名（プロトコルなし）を入力、ポート番号（1-65535）を記入し、インターバルを設定します。保存すれば、次のサイクルから1分ごとにTCP接続を張り、ラウンドトリップを記録し、ポートが閉じた瞬間にアラートします—Email、Telegram、Slack、Discord、SMSで、同じ確認閾値とナイトモードのルールです。

よくある質問

どのポートを監視できますか？
1から65535までのすべてのTCPポートに対応しています。よくあるケース例：SMTP（25/587/465）、POP3（110/995）、IMAP（143/993）、データベースリスナー（PostgreSQL 5432、MySQL 3306、Redis 6379、MongoDB 27017）、SSH（22）、FTP（21）、カスタムアプリケーションポートなど。
モニターはサービスの正常性をチェックしますか？それとも接続可否だけですか？
接続可否のみです。モニターはTCP接続を開き、デーモンが受信するか確認します。プロトコルレベルのハンドシェイクは行いません。プロトコルを考慮したチェック（例：SMTPバナー検証、データベースクエリ応答）の場合、HTTPチェック（HTTPサービス用）やself-hostedハートビートエージェントをご利用ください。
ポートチェックのタイムアウトは？
デフォルトは10秒です。各モニターごとに設定可能です。もしTCP接続がタイムアウト時間内に確立しない場合、「connection timeout」で失敗扱いとなります。遠距離接続（例：欧州からアジアのサーバー監視）ではより長いタイムアウトが必要な場合があります。
UDPポートの監視は可能ですか？
現時点ではできません。UDPはコネクションレスなので、「接続受理」の概念がありません。UDPベースのサービスは通常、プロトコル固有のprobe（例：53番ポートならDNS問い合わせ、161番ならSNMP get）が必要です。その場合はハートビート監視などをご活用ください。
ポート監視でTLS/SSLの警告も検出できますか？
いいえ—ポートチェックは純粋なTCP到達性のみです。対象ポートでTLS証明書の検証もしたい場合は、URLにポート番号を含めたHTTPSチェック（例：https://api.example.com:8443/）をご利用ください。こちらでは到達性と証明書チェック両方を行います。

ポート監視