> ## Documentation Index
> Fetch the complete documentation index at: https://docs.streamnative.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Test Connectivity to StreamNative Cloud

Brokers hosted on StreamNative Cloud do not respond to `ping` requests. Instead, you can use the methods presented in this guide to test the connectivity to your StreamNative Cloud cluster and its endpoints before whitelisting them.

Run through the following steps to validate StreamNative Cloud connectivity is working as expected.

## Test connectivity to StreamNative Cloud

You can test connectivity to any StreamNative Cloud cluster using `openssl`, `Netcat`, or `Telnet`.

For clusters with public endpoints, you can run connectivity tests from any computer with internet access.

For clusters in private network environments (such as PrivateLink, Private Service Connect, VPC peering, VNet peering, and AWS Transit Gateway), run tests from within your VPC or VNet that is connected to the StreamNative Cloud cluster.

* For PrivateLink, ensure enabling Private DNS name when setting up the Private Endpoint in your VPC. See [Inbound PrivateLink for BYOC Clusters](id:inbound-private-link-for-byoc-clusters) for more details.

All the services of a StreamNative Cloud cluster share the same DNS name, but use different ports:

* Use port `443` to test the connection to the Pulsar HTTP service, Websocket service, REST messaging service, and the Kafka schema registry service.
* Use port `6651` to test the connection to the Pulsar Broker service.
* Use port `9093` to test the connection to the Kafka Broker service.
* Use port `8883` to test the connection to the MQTT service.

To test the connection to the Kafka Broker and MQTT service, ensure that both Kafka and MQTT protocols are enabled on your cluster. These protocols are enabled by default on new clusters. However, for older clusters, you may need to enable them manually.

To only test TCP connectivity, use `Telnet` or `Netcat`:

* **Netcat**

  ```bash theme={null}
  nc -zv <cluster-endpoint> 443
  nc -zv <cluster-endpoint> 6651
  nc -zv <cluster-endpoint> 9093
  nc -zv <cluster-endpoint> 8883
  ```

* **Telnet**

  ```bash theme={null}
  telnet <cluster-endpoint> 443
  telnet <cluster-endpoint> 6651
  telnet <cluster-endpoint> 9093
  telnet <cluster-endpoint> 8883
  ```

In addition to TCP connectivity, to also test the TLS handshake and the certificate, use `openssl`. With `openssl`, you can an SNI header:

* **OpenSSL**

  ```bash theme={null}
  openssl s_client -servername <cluster-endpoint> -connect <cluster-endpoint>:443
  openssl s_client -servername <cluster-endpoint> -connect <cluster-endpoint>:6651
  openssl s_client -servername <cluster-endpoint> -connect <cluster-endpoint>:9093
  openssl s_client -servername <cluster-endpoint> -connect <cluster-endpoint>:8883
  ```

  For more details, see the [OpenSSL documentation](https://www.openssl.org/docs/man3.0/man1/openssl-s_client.html) for the `-connect` option.

It is recommended that you use `openssl` to test TCP and TLS because with the TCP testing only, it is difficult to make the distinction among the various cases when a connection fails, such as:

* Timeout because of routing problems.
* Established connection, but you as the client not initiating the TLS handshake.
* Envoy disconnecting your connection because you do not send the SNI header.

  For Kafka clients, see the [TLS SNI extension requirements](/cloud/build/kafka-clients/compatibility/kafka-compatibility#tls-sni-extension-requirements) for more details.

## Test connectivity using Pulsar or Kafka tools

After connectivity is successfully established, you can use the Pulsar or Kafka clients and/or tools to test producing/consuming messages. Examples are `pulsar-client`, `kcat`, `kafkacat`, `kafka-console-consumer`, `kafka-console-producer`, native command line tools, or Java and other clients. The following are a few of the test workflows you can use as references:

* For using the Pulsar clients to produce and consume messages, see [Pulsar Client Guides](/clients/pulsar-clients/pulsar-clients-overview)
* For using the Kafka clients to produce and consume messages, see [Kafka Client Guides](/clients/kafka-clients/kafka-clients-overview)
* For using the Pulsar CLI tools to produce and consume messages, see [Use Pulsar Tools with StreamNative Cloud](/tools/cli/other-tools/use-pulsar-tools-with-streamnative-cloud)
* For using the Kafka CLI tools to produce and consume messages, see [Use Kafka Tools with StreamNative Cloud](/tools/cli/other-tools/use-kafka-tools-with-streamnative-cloud)

## Troubleshoot connectivity issues

If connectivity to the cluster endpoint cannot be established, first check your firewall and other security configurations and restrictions that could prevent the connection to the StreamNative Cloud cluster endpoint.

Here are some common issues and their troubleshooting steps:

### Failed connection to brokers in private link cluster

**Issue**: You got an error message similar to the following from a Kafka client over a private link, such as produce or consume messages:

```
SSL handshake failed: Disconnected: connecting to a PLAINTEXT broker listener? (after 0ms in state SSL_HANDSHAKE)
```

**Possible causes**:

* The private endpoint in use does not correspond to the correct availability zone.
* Zone affinity between your application VPC and StreamNative managed VPC is not respected. See [Inbound PrivateLink for BYOC Clusters](/cloud/networking/networking-on-aws/aws-privatelink/aws-inbound-privatelink-byoc) for more details.
* The private DNS name is not enabled when setting up the private endpoint in your VPC.