# 使用に関するよくある質問

## ライセンスが期限切れになるとどうなりますか？

EMQX Enterpriseユーザーの場合、ライセンスの有効期限が切れると、ノード起動時に期限切れを通知する警告が表示されます。ライセンスタイプによっては、追加の制限が適用されることがあります。

- **「小規模」顧客向けまたはトライアルライセンスの場合：** ライセンスで指定された接続数の上限に達していなくても、新規のMQTT接続は許可されません。既存の接続は切断されませんが、切断された場合は再接続できません。
- **「小規模」顧客向けやトライアル以外のライセンスの場合：** 合計接続数が最大上限を超えない限り、新規のMQTT接続は許可されます。

ご自身のライセンスタイプが不明な場合は、担当のアカウントマネージャーにご確認ください。

## ライセンスはどのように更新しますか？

以下のコマンドでEMQX Enterpriseのライセンスを更新できます。

```bash
./bin/emqx ctl 

    license info             # ライセンス情報を表示 
    license update <License> # 文字列として与えられたライセンスを更新
```

また、ダッシュボードからもライセンスを更新可能です。ライセンスの申請方法やダッシュボードを使った更新方法については、[EMQX Enterpriseライセンスの利用](../deploy/license.md)をご参照ください。

## 共有サブスクリプションを使うと保持メッセージが受信できないのはなぜですか？

MQTTプロトコルの仕様により、クライアントが共有サブスクリプションを使用している場合、サーバーはそのクライアントに保持メッセージを送信できません。

## 共有サブスクリプションを使うとメッセージが時々失われるのはなぜですか？

共有サブスクライバーの接続が切断されてもセッションがアクティブな場合、サーバーはメッセージの配信を続け、そのメッセージはセッション内に一時的に保存されます。そのため、他のアクティブな共有サブスクライバーはすべてのメッセージを消費していないように見えることがあります。また、共有サブスクライバーが再接続時に新しいセッションを作成すると、古いセッションにキャッシュされたメッセージは永久に失われます。

上記の状況がないにもかかわらずメッセージの損失が続く場合は、[ログトレース](../observability/tracer.md)を使ってさらに調査してください。

## SSL/TLS接続失敗の原因をどのように調査しますか？

通常、SSL/TLS接続のハンドシェイクに失敗すると、EMQXは[ログ](../observability/log.md)に失敗理由を出力します。以下はログに現れる一般的なキーワードとその意味です。

- certificate_expired

   ログに`certificate_expired`が表示された場合、証明書の有効期限が切れているため、速やかに更新してください。

- no_suitable_cipher

   ログに`no_suitable_cipher`が表示された場合、ハンドシェイク時に適切な暗号スイートが見つからなかったことを示します。証明書の種類が暗号スイートと合わない、サーバーとクライアントの両方でサポートされる暗号スイートが存在しないなどが考えられます。

- handshake_failure

   ログに`handshake_failure`が表示された場合、原因は多岐にわたります。クライアントのエラー報告と合わせて分析してください。例えば、クライアントが接続先サーバーのアドレスとサーバー証明書のドメイン名が一致しないことを検出する場合があります。

- unknown_ca

   ログに`unknown_ca`が表示された場合、証明書の検証に失敗しています。中間CA証明書の省略、ルートCA証明書の未指定、誤ったルートCA証明書の指定が一般的な原因です。双方向認証の場合、ログの他の情報からサーバーまたはクライアントの証明書設定の誤りを判断できます。

   サーバー証明書に問題がある場合、エラーログは通常以下のようになります。

   ```
   {ssl_error,{tls_alert,{unknown_ca,"TLS server: In state certify received CLIENT ALERT: Fatal - Unknown CA\n"}}}
   ```

   `CLIENT ALERT`はクライアントからの警告メッセージであり、サーバー証明書がクライアントの検証に失敗したことを示します。

   クライアント証明書に問題がある場合、エラーログは通常以下のようになります。

   ```
   {ssl_error,{tls_alert,{unknown_ca,"TLS server: In state certify at ssl_handshake.erl:1887 generated SERVER ALERT: Fatal - Unknown CA\n"}}}
   ```

   `SERVER ALERT`はサーバーがクライアント証明書の認証に失敗し、クライアントに警告メッセージを送信したことを示します。

- protocol_version

   ログに`protocol_version`が表示された場合、クライアントとサーバー間でTLSプロトコルのバージョンが一致していません。

## MQTTクライアントの異常切断の原因をどのように調査しますか？

Shellで`emqx ctl listeners`を実行すると、各リスナーの切断統計情報が返されます。切断理由や切断回数が含まれます。例：

```
$ . /bin/emqx ctl listeners
tcp:default
  listen_on : 0.0.0.0:1883
  acceptors : 16
  proxy_protocol : false
  running : true
  current_conn : 9
  max_conns : infinity
  shutdown_count : [{keepalive_timeout,1},{idle_timeout,2}]
```

よくある切断理由は以下の通りです。

- `keepalive_timeout`: クライアントのハートビートがタイムアウトし、EMQXが接続を切断。
- `tcp_closed`: クライアントがDISCONNECTパケットを送信せずにTCP接続を直接閉じた。
- `frame_too_large`: クライアントが送信したパケットサイズが最大制限を超え、EMQXが接続を切断。
- `protocol_error`: クライアントの非準拠動作によりEMQXが接続を切断。例として同一接続内で複数のCONNECTパケット送信など。
- `idle_timeout`: TCP接続確立後15秒以内にクライアントからCONNECTパケットを受信できず、EMQXが接続を切断。

また、[ログトレース](../observability/tracer.md)を使い、指定したクライアントID、IP、トピックに関連するすべてのログを追跡し、切断原因を分析できます。

## ストレステスト時に接続数やスループットが期待より低かった場合、システムを最大限活用するためにはどう調整すればよいですか？

ストレステストを実施する際は、必要なハードウェアリソースの確保に加え、OSやErlang VMのチューニングが必要です。主なチューニング項目は、ファイルハンドルのグローバル制限およびユーザー制限、TCPのバックログやバッファ、Erlang VMのプロセス数制限などです。また、クライアント側のマシンも、すべてのサブスクライブおよびパブリッシュを処理できる能力とリソースを持つよう調整してください。

ユースケースによって最適なチューニングは異なります。一般的なチューニング方法については、[パフォーマンスチューニング](../performance/tune.md)をご参照ください。

## クライアント接続、パブリッシュ、サブスクライブに関する問題（接続失敗、異常切断など）が発生した場合、どのようにトラブルシュートすればよいですか？

EMQXのデバッグログにはすべての動作や現象が記録されています。デバッグログを確認することで、クライアントがいつ接続を開始したか、接続時に指定したパラメータ、接続の成功・拒否の有無やその理由などを把握できます。ただし、デバッグモードでは大量の情報が記録されるため、個別のクライアントやトピックの解析が困難になることがあります。

これに対処するため、EMQXは[ログトレース](../observability/tracer.md)機能を提供しています。トレース対象のクライアントやトピックを指定すると、それらに関連するすべてのデバッグログを指定のログファイルに出力します。これにより自己解析やコミュニティへの相談が容易になります。

なお、クライアントがネットワーク障害によりEMQXと接続できない場合、EMQXはメッセージを受信しないためログトレースは役に立ちません。このような場合は、ファイアウォールやセキュリティグループなどのネットワーク設定によりサーバーポートが閉じられていることが多く、特にクラウド環境でのEMQXデプロイ時に発生しやすいです。したがって、ログトレースに加え、ポートの占有状況やリスニング状態、ネットワーク設定の確認も重要です。

## 「CENSYS」などの見慣れないクライアントIDが接続しているのはなぜですか？

CENSYSはインターネットのスキャンおよび偵察ツールで、IPv4アドレス空間を定期的にスキャンし、HTTP、SSH、MQTTなどの各種プロトコルのデフォルトポートを調査します。したがって、MQTTブローカーに「CENSYS」などのクライアントIDを持つ不明なクライアントがアクセスしている場合、セキュリティ保護レベルが比較的低いことを示しています。この問題に対処するため、以下の対策を検討してください。

1. EMQXのHTTP APIアクセス権限を検証するAppIDやAppSecretなど、デフォルト設定を使用しない。
2. パスワード認証やJWT認証などの認証機構を有効にし、IPアドレスだけでログインできないようにする。
3. TLS相互認証を有効にし、有効な証明書を持つクライアントのみアクセスを許可する。
4. 適切な認可機構を有効にし、認可されていないデバイスによる機密データへのアクセスを制限する。
5. ファイアウォールで不要なポートを可能な限り閉じる。

## ダッシュボードのログインパスワードを忘れた場合、どのようにリセットしますか？

ダッシュボードの初期ユーザー名とパスワードはそれぞれ`admin`と`public`です。セキュリティ上の理由から、初回ログイン時にパスワード変更が強制されます。以前設定したパスワードを忘れた場合は、以下のコマンドで旧パスワードを入力せずに新しいパスワードを設定できます。

```bash
./bin/emqx ctl admins passwd <Username> <Password>
```