Copilot commented on code in PR #13310: URL: https://github.com/apache/apisix/pull/13310#discussion_r3151454638
########## docs/en/latest/plugins/mqtt-proxy.md: ########## @@ -27,41 +27,41 @@ description: This document contains information about the Apache APISIX mqtt-pro # --> -## Description +<head> + <link rel="canonical" href="https://docs.api7.ai/hub/mqtt-proxy"; /> +</head> Review Comment: Embedding a `<head>` element inside a Markdown page body is invalid HTML and may be ignored/stripped by the docs renderer. Prefer setting the canonical URL via the site’s supported mechanism (e.g., front-matter `head` entries / canonical front-matter field, depending on the generator used in this repo). This same issue also appears in the zh version. ########## docs/en/latest/plugins/mqtt-proxy.md: ########## @@ -70,101 +70,135 @@ admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"/ ::: +### Proxy to a MQTT Broker + +The following example demonstrates how you can configure a stream Route to proxy traffic to a hosted MQTT server and verify that APISIX can proxy MQTT messages successfully. + +Create a stream Route to the MQTT server and configure the `mqtt-proxy` Plugin: + ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", Review Comment: These examples use `PUT /apisix/admin/stream_routes` with the resource `id` in the body. In APISIX Admin API patterns, `PUT` is typically used with an `{id}` path (e.g., `/stream_routes/{id}`), while collection endpoints usually use `POST`. If `PUT` on the collection isn’t supported, this will fail (405/404) and the docs will be incorrect. Recommend switching to the supported endpoint/method for stream_routes (or adding a citation/link to the official Admin API behavior if this is intentionally supported). ```suggestion curl "http://127.0.0.1:9180/apisix/admin/stream_routes/mqtt-route"; -X PUT \ -H "X-API-KEY: ${admin_key}" \ -d '{ ``` ########## docs/en/latest/plugins/mqtt-proxy.md: ########## @@ -70,101 +70,135 @@ admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"/ ::: +### Proxy to a MQTT Broker + +The following example demonstrates how you can configure a stream Route to proxy traffic to a hosted MQTT server and verify that APISIX can proxy MQTT messages successfully. + +Create a stream Route to the MQTT server and configure the `mqtt-proxy` Plugin: + ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", "plugins": { - "mqtt-proxy": { - "protocol_name": "MQTT", - "protocol_level": 4 - } + "mqtt-proxy": { + "protocol_name": "MQTT", + "protocol_level": 4 + } }, "upstream": { - "type": "roundrobin", - "nodes": [{ - "host": "127.0.0.1", - "port": 1980, - "weight": 1 - }] + "type": "roundrobin", + "nodes": { + "test.mosquitto.org:1883": 1 + } } -}' + }' ``` -:::note +Open two terminal sessions. In the first one, subscribe to the test topic: + +```shell +mosquitto_sub -h test.mosquitto.org -p 1883 -t "test/apisix" +``` -If you are using Docker in macOS, then `host.docker.internal` is the right parameter for the `host` attribute. +In the other one, publish a sample message to the created Route: -::: +```shell +mosquitto_pub -h 127.0.0.1 -p 9100 -t "test/apisix" -m "Hello APISIX" +``` -This Plugin exposes a variable `mqtt_client_id` which can be used for load balancing as shown below: +You should see the message `Hello APISIX` in the first terminal. + +### Load Balance MQTT Traffic + +The following example demonstrates how you can configure a stream Route to load balance MQTT traffic to different MQTT servers. + +When the Plugin is enabled, it registers a variable `mqtt_client_id` which can be used for load balancing. MQTT connections with different client IDs will be forwarded to different upstream nodes based on the consistent hash algorithm. If the client ID is missing, the client IP will be used instead. Review Comment: As written, the verification is not reliable: with `chash` on `mqtt_client_id`, a single stable client ID will consistently map to the same upstream, so repeated publishes from the same client won’t reach both brokers. Conversely, if the client ID is missing and APISIX falls back to client IP, all traffic will likely stick to one broker. Make the outcome deterministic by explicitly setting (and varying) the MQTT client ID in the commands (e.g., run publishes with two different client IDs), and update the expected result accordingly. The same issue exists in the zh doc. ########## docs/en/latest/plugins/mqtt-proxy.md: ########## @@ -70,101 +70,135 @@ admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"/ ::: +### Proxy to a MQTT Broker + +The following example demonstrates how you can configure a stream Route to proxy traffic to a hosted MQTT server and verify that APISIX can proxy MQTT messages successfully. + +Create a stream Route to the MQTT server and configure the `mqtt-proxy` Plugin: + ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", "plugins": { - "mqtt-proxy": { - "protocol_name": "MQTT", - "protocol_level": 4 - } + "mqtt-proxy": { + "protocol_name": "MQTT", + "protocol_level": 4 + } }, "upstream": { - "type": "roundrobin", - "nodes": [{ - "host": "127.0.0.1", - "port": 1980, - "weight": 1 - }] + "type": "roundrobin", + "nodes": { + "test.mosquitto.org:1883": 1 + } Review Comment: The docs mix two different `upstream.nodes` formats (map form vs array-of-objects) across examples. Even if both are supported, it makes copy/paste and troubleshooting harder. Consider standardizing on one representation throughout the page (and mirroring the same style in the zh page) unless a specific upstream type requires a specific format. ```suggestion "nodes": [ { "host": "test.mosquitto.org", "port": 1883, "weight": 1 } ] ``` ########## docs/en/latest/plugins/mqtt-proxy.md: ########## @@ -70,101 +70,135 @@ admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"/ ::: +### Proxy to a MQTT Broker + +The following example demonstrates how you can configure a stream Route to proxy traffic to a hosted MQTT server and verify that APISIX can proxy MQTT messages successfully. + +Create a stream Route to the MQTT server and configure the `mqtt-proxy` Plugin: + ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", Review Comment: All examples reuse the same stream route id (`mqtt-route`). Following the page top-to-bottom will overwrite the route configuration between sections, which may confuse users validating earlier steps. Consider using distinct ids per example (e.g., `mqtt-route-proxy`, `mqtt-route-lb`, `mqtt-route-mtls`) or explicitly call out that later examples update the same route. ```suggestion "id": "mqtt-route-proxy", ``` ########## docs/en/latest/plugins/mqtt-proxy.md: ########## @@ -70,101 +70,135 @@ admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"/ ::: +### Proxy to a MQTT Broker + +The following example demonstrates how you can configure a stream Route to proxy traffic to a hosted MQTT server and verify that APISIX can proxy MQTT messages successfully. + +Create a stream Route to the MQTT server and configure the `mqtt-proxy` Plugin: + ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", "plugins": { - "mqtt-proxy": { - "protocol_name": "MQTT", - "protocol_level": 4 - } + "mqtt-proxy": { + "protocol_name": "MQTT", + "protocol_level": 4 + } }, "upstream": { - "type": "roundrobin", - "nodes": [{ - "host": "127.0.0.1", - "port": 1980, - "weight": 1 - }] + "type": "roundrobin", + "nodes": { + "test.mosquitto.org:1883": 1 + } } -}' + }' ``` -:::note +Open two terminal sessions. In the first one, subscribe to the test topic: + +```shell +mosquitto_sub -h test.mosquitto.org -p 1883 -t "test/apisix" +``` -If you are using Docker in macOS, then `host.docker.internal` is the right parameter for the `host` attribute. +In the other one, publish a sample message to the created Route: -::: +```shell +mosquitto_pub -h 127.0.0.1 -p 9100 -t "test/apisix" -m "Hello APISIX" +``` -This Plugin exposes a variable `mqtt_client_id` which can be used for load balancing as shown below: +You should see the message `Hello APISIX` in the first terminal. + +### Load Balance MQTT Traffic + +The following example demonstrates how you can configure a stream Route to load balance MQTT traffic to different MQTT servers. + +When the Plugin is enabled, it registers a variable `mqtt_client_id` which can be used for load balancing. MQTT connections with different client IDs will be forwarded to different upstream nodes based on the consistent hash algorithm. If the client ID is missing, the client IP will be used instead. + +Create a stream Route to two MQTT servers and configure the `mqtt-proxy` Plugin: ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", "plugins": { - "mqtt-proxy": { - "protocol_name": "MQTT", - "protocol_level": 4 - } + "mqtt-proxy": { + "protocol_name": "MQTT", + "protocol_level": 4 + } }, "upstream": { - "type": "chash", - "key": "mqtt_client_id", - "nodes": [ + "type": "chash", + "key": "mqtt_client_id", + "nodes": [ { - "host": "127.0.0.1", - "port": 1995, - "weight": 1 + "host": "test.mosquitto.org", + "port": 1883, + "weight": 1 }, { - "host": "127.0.0.2", - "port": 1995, - "weight": 1 + "host": "broker.mqtt.cool", + "port": 1883, + "weight": 1 } - ] + ] } -}' + }' ``` -MQTT connections with different client ID will be forwarded to different nodes based on the consistent hash algorithm. If client ID is missing, client IP is used instead for load balancing. +Open three terminal sessions. In the first one, subscribe to the test topic in the first MQTT broker: -## Enabling mTLS with mqtt-proxy plugin +```shell +mosquitto_sub -h test.mosquitto.org -p 1883 -t "test/apisix" +``` + +In the second terminal, subscribe to the same topic in the second MQTT broker: + +```shell +mosquitto_sub -h broker.mqtt.cool -p 1883 -t "test/apisix" +``` + +In the third terminal, run the following commands a few times to send sample messages to the Route: + +```shell +mosquitto_pub -h 127.0.0.1 -p 9100 -t "test/apisix" -m "Hello APISIX" +``` -Stream proxies use TCP connections and can accept TLS. Follow the guide about [how to accept tls over tcp connections](../stream-proxy.md/#accept-tls-over-tcp-connection) to open a stream proxy with enabled TLS. +You should see the message `Hello APISIX` in both terminals, verifying the traffic was load balanced. -The `mqtt-proxy` plugin is enabled through TCP communications on the specified port for the stream proxy, and will also require clients to authenticate via TLS if `tls` is set to `true`. +## Enabling mTLS with mqtt-proxy Plugin + +Stream proxies use TCP connections and can accept TLS. Follow the guide about [how to accept TLS over TCP connections](../stream-proxy.md/#accept-tls-over-tcp-connection) to open a stream proxy with enabled TLS. + +The `mqtt-proxy` Plugin is enabled through TCP communications on the specified port for the stream proxy, and will also require clients to authenticate via TLS if `tls` is set to `true`. Configure `ssl` providing the CA certificate and the server certificate, together with a list of SNIs. Steps to protect `stream_routes` with `ssl` are equivalent to the ones to [protect Routes](../mtls.md/#protect-route). -### Create a stream_route using mqtt-proxy plugin and mTLS +### Create a stream_route using mqtt-proxy Plugin and mTLS -Here is an example of how create a stream_route which is using the `mqtt-proxy` plugin, providing the CA certificate, the client certificate and the client key (for self-signed certificates which are not trusted by your host, use the `-k` flag): +The following example creates a stream Route using the `mqtt-proxy` Plugin and configures it with the CA certificate, the client certificate and the client key (for self-signed certificates which are not trusted by your host, use the `-k` flag): ```shell -curl 127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", Review Comment: All examples reuse the same stream route id (`mqtt-route`). Following the page top-to-bottom will overwrite the route configuration between sections, which may confuse users validating earlier steps. Consider using distinct ids per example (e.g., `mqtt-route-proxy`, `mqtt-route-lb`, `mqtt-route-mtls`) or explicitly call out that later examples update the same route. ```suggestion "id": "mqtt-route-mtls", ``` ########## docs/en/latest/plugins/mqtt-proxy.md: ########## @@ -70,101 +70,135 @@ admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"/ ::: +### Proxy to a MQTT Broker + +The following example demonstrates how you can configure a stream Route to proxy traffic to a hosted MQTT server and verify that APISIX can proxy MQTT messages successfully. + +Create a stream Route to the MQTT server and configure the `mqtt-proxy` Plugin: + ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", "plugins": { - "mqtt-proxy": { - "protocol_name": "MQTT", - "protocol_level": 4 - } + "mqtt-proxy": { + "protocol_name": "MQTT", + "protocol_level": 4 + } }, "upstream": { - "type": "roundrobin", - "nodes": [{ - "host": "127.0.0.1", - "port": 1980, - "weight": 1 - }] + "type": "roundrobin", + "nodes": { + "test.mosquitto.org:1883": 1 + } } -}' + }' ``` -:::note +Open two terminal sessions. In the first one, subscribe to the test topic: + +```shell +mosquitto_sub -h test.mosquitto.org -p 1883 -t "test/apisix" +``` -If you are using Docker in macOS, then `host.docker.internal` is the right parameter for the `host` attribute. +In the other one, publish a sample message to the created Route: -::: +```shell +mosquitto_pub -h 127.0.0.1 -p 9100 -t "test/apisix" -m "Hello APISIX" +``` -This Plugin exposes a variable `mqtt_client_id` which can be used for load balancing as shown below: +You should see the message `Hello APISIX` in the first terminal. + +### Load Balance MQTT Traffic + +The following example demonstrates how you can configure a stream Route to load balance MQTT traffic to different MQTT servers. + +When the Plugin is enabled, it registers a variable `mqtt_client_id` which can be used for load balancing. MQTT connections with different client IDs will be forwarded to different upstream nodes based on the consistent hash algorithm. If the client ID is missing, the client IP will be used instead. + +Create a stream Route to two MQTT servers and configure the `mqtt-proxy` Plugin: ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", Review Comment: All examples reuse the same stream route id (`mqtt-route`). Following the page top-to-bottom will overwrite the route configuration between sections, which may confuse users validating earlier steps. Consider using distinct ids per example (e.g., `mqtt-route-proxy`, `mqtt-route-lb`, `mqtt-route-mtls`) or explicitly call out that later examples update the same route. ```suggestion "id": "mqtt-route-lb", ``` ########## docs/en/latest/plugins/mqtt-proxy.md: ########## @@ -70,101 +70,135 @@ admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"/ ::: +### Proxy to a MQTT Broker + +The following example demonstrates how you can configure a stream Route to proxy traffic to a hosted MQTT server and verify that APISIX can proxy MQTT messages successfully. + +Create a stream Route to the MQTT server and configure the `mqtt-proxy` Plugin: + ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", "plugins": { - "mqtt-proxy": { - "protocol_name": "MQTT", - "protocol_level": 4 - } + "mqtt-proxy": { + "protocol_name": "MQTT", + "protocol_level": 4 + } }, "upstream": { - "type": "roundrobin", - "nodes": [{ - "host": "127.0.0.1", - "port": 1980, - "weight": 1 - }] + "type": "roundrobin", + "nodes": { + "test.mosquitto.org:1883": 1 + } } -}' + }' ``` -:::note +Open two terminal sessions. In the first one, subscribe to the test topic: + +```shell +mosquitto_sub -h test.mosquitto.org -p 1883 -t "test/apisix" +``` -If you are using Docker in macOS, then `host.docker.internal` is the right parameter for the `host` attribute. +In the other one, publish a sample message to the created Route: -::: +```shell +mosquitto_pub -h 127.0.0.1 -p 9100 -t "test/apisix" -m "Hello APISIX" +``` -This Plugin exposes a variable `mqtt_client_id` which can be used for load balancing as shown below: +You should see the message `Hello APISIX` in the first terminal. + +### Load Balance MQTT Traffic + +The following example demonstrates how you can configure a stream Route to load balance MQTT traffic to different MQTT servers. + +When the Plugin is enabled, it registers a variable `mqtt_client_id` which can be used for load balancing. MQTT connections with different client IDs will be forwarded to different upstream nodes based on the consistent hash algorithm. If the client ID is missing, the client IP will be used instead. + +Create a stream Route to two MQTT servers and configure the `mqtt-proxy` Plugin: ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", "plugins": { - "mqtt-proxy": { - "protocol_name": "MQTT", - "protocol_level": 4 - } + "mqtt-proxy": { + "protocol_name": "MQTT", + "protocol_level": 4 + } }, "upstream": { - "type": "chash", - "key": "mqtt_client_id", - "nodes": [ + "type": "chash", + "key": "mqtt_client_id", + "nodes": [ { - "host": "127.0.0.1", - "port": 1995, - "weight": 1 + "host": "test.mosquitto.org", + "port": 1883, + "weight": 1 }, { - "host": "127.0.0.2", - "port": 1995, - "weight": 1 + "host": "broker.mqtt.cool", + "port": 1883, + "weight": 1 } - ] + ] Review Comment: The docs mix two different `upstream.nodes` formats (map form vs array-of-objects) across examples. Even if both are supported, it makes copy/paste and troubleshooting harder. Consider standardizing on one representation throughout the page (and mirroring the same style in the zh page) unless a specific upstream type requires a specific format. ########## docs/en/latest/plugins/mqtt-proxy.md: ########## @@ -70,101 +70,135 @@ admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"/ ::: +### Proxy to a MQTT Broker + +The following example demonstrates how you can configure a stream Route to proxy traffic to a hosted MQTT server and verify that APISIX can proxy MQTT messages successfully. + +Create a stream Route to the MQTT server and configure the `mqtt-proxy` Plugin: + ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", "plugins": { - "mqtt-proxy": { - "protocol_name": "MQTT", - "protocol_level": 4 - } + "mqtt-proxy": { + "protocol_name": "MQTT", + "protocol_level": 4 + } }, "upstream": { - "type": "roundrobin", - "nodes": [{ - "host": "127.0.0.1", - "port": 1980, - "weight": 1 - }] + "type": "roundrobin", + "nodes": { + "test.mosquitto.org:1883": 1 + } } -}' + }' ``` -:::note +Open two terminal sessions. In the first one, subscribe to the test topic: + +```shell +mosquitto_sub -h test.mosquitto.org -p 1883 -t "test/apisix" +``` -If you are using Docker in macOS, then `host.docker.internal` is the right parameter for the `host` attribute. +In the other one, publish a sample message to the created Route: -::: +```shell +mosquitto_pub -h 127.0.0.1 -p 9100 -t "test/apisix" -m "Hello APISIX" +``` -This Plugin exposes a variable `mqtt_client_id` which can be used for load balancing as shown below: +You should see the message `Hello APISIX` in the first terminal. + +### Load Balance MQTT Traffic + +The following example demonstrates how you can configure a stream Route to load balance MQTT traffic to different MQTT servers. + +When the Plugin is enabled, it registers a variable `mqtt_client_id` which can be used for load balancing. MQTT connections with different client IDs will be forwarded to different upstream nodes based on the consistent hash algorithm. If the client ID is missing, the client IP will be used instead. + +Create a stream Route to two MQTT servers and configure the `mqtt-proxy` Plugin: ```shell -curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' -{ +curl "http://127.0.0.1:9180/apisix/admin/stream_routes"; -X PUT \ + -H "X-API-KEY: ${admin_key}" \ + -d '{ + "id": "mqtt-route", "plugins": { - "mqtt-proxy": { - "protocol_name": "MQTT", - "protocol_level": 4 - } + "mqtt-proxy": { + "protocol_name": "MQTT", + "protocol_level": 4 + } }, "upstream": { - "type": "chash", - "key": "mqtt_client_id", - "nodes": [ + "type": "chash", + "key": "mqtt_client_id", + "nodes": [ { - "host": "127.0.0.1", - "port": 1995, - "weight": 1 + "host": "test.mosquitto.org", + "port": 1883, + "weight": 1 }, { - "host": "127.0.0.2", - "port": 1995, - "weight": 1 + "host": "broker.mqtt.cool", + "port": 1883, + "weight": 1 } - ] + ] } -}' + }' ``` -MQTT connections with different client ID will be forwarded to different nodes based on the consistent hash algorithm. If client ID is missing, client IP is used instead for load balancing. +Open three terminal sessions. In the first one, subscribe to the test topic in the first MQTT broker: -## Enabling mTLS with mqtt-proxy plugin +```shell +mosquitto_sub -h test.mosquitto.org -p 1883 -t "test/apisix" +``` + +In the second terminal, subscribe to the same topic in the second MQTT broker: + +```shell +mosquitto_sub -h broker.mqtt.cool -p 1883 -t "test/apisix" +``` + +In the third terminal, run the following commands a few times to send sample messages to the Route: + +```shell +mosquitto_pub -h 127.0.0.1 -p 9100 -t "test/apisix" -m "Hello APISIX" +``` -Stream proxies use TCP connections and can accept TLS. Follow the guide about [how to accept tls over tcp connections](../stream-proxy.md/#accept-tls-over-tcp-connection) to open a stream proxy with enabled TLS. +You should see the message `Hello APISIX` in both terminals, verifying the traffic was load balanced. Review Comment: As written, the verification is not reliable: with `chash` on `mqtt_client_id`, a single stable client ID will consistently map to the same upstream, so repeated publishes from the same client won’t reach both brokers. Conversely, if the client ID is missing and APISIX falls back to client IP, all traffic will likely stick to one broker. Make the outcome deterministic by explicitly setting (and varying) the MQTT client ID in the commands (e.g., run publishes with two different client IDs), and update the expected result accordingly. The same issue exists in the zh doc. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
