dsh bot on QQ not replying: bridge config and logs

The top cause of "dsh bot on QQ does not reply" is not configuration; it is the wrong plugin. dsh-bot bridges Telegram and WeChat. For QQ, use dsh-qq, dsh-qqbot, or dsh-im.

Correct the name first

The dsh-bot description is explicit: it turns Telegram and WeChat into workspace entry points. There is no QQ channel (source).

So "installed dsh bot, QQ does nothing" is not a failure. The plugin never connected to QQ; no configuration will produce a message.

Same-name and near-name plugins are common. dsh-bot, dsh-qqbot, dsh-qq, and dsh-im have similar names and different channels. Searching "QQ bot" often installs the wrong one; check owner and description.

Three QQ-capable plugins

At least three implementations connect to QQ, with different interaction models. Choose one.

dsh-qq is for group replies. It sends and receives on a local QQ client, ships a web panel, and applies default rate limits (source).

dsh-qqbot is for conversation. You talk to the agent in private or group chats, execute tools, and manage sessions; credentials and access control are the main configuration (source).

dsh-im is for multi-channel. It supports nine channels via QR or credentials; choose it when QQ is one of several platforms (source).

Do not install several QQ plugins at once. Two listeners on one account compete for messages, duplicate replies, or reply only once; uninstall before switching.

Configuration chain: credentials, port, allowlist

Configuration causes most no-reply cases. Check in order.

1. Credentials: login state, token, or QR authorization. Expired credentials let messages reach the platform but not the plugin.
2. Port and callback: the local service port must be free and the callback reachable; a port conflict lets the plugin start but receive nothing.
3. Access control: allowed accounts, groups, and trigger mode. Unmatched messages are silently ignored.
4. Rate limits: default limits drop bursts; check logs before adjusting intervals.

Silent ignore is the hardest configuration problem. It produces no error and no prompt, just silence; check the allowlist and trigger conditions before the model.

Expired credentials leave traces. Recovery after re-login or re-scan means credentials; total silence means check the port and plugin load.

Four-stage trace

Split the chain into four stages and confirm each.

1. Message arrival: did the platform receive it? Send from another client and check the plugin panel for a record.
2. Plugin load: does dsh plugin --profile web list contain the plugin, and are logs free of load failures?
3. Permission and access control: is the sender, group, and trigger mode allowed? Excluded messages never reach the agent.
4. Model response: if the first three pass, check whether the session has a request and whether the model errors or times out.

Do not reverse the order. Starting with the model misreads "plugin not installed" as "model broken"; starting with arrival eliminates half the cases.

Keep evidence per stage. Panel records, system logs, and session records; "I sent it" is not evidence.

Three typical scenes

The same silence has three different causes.

1. Neither private nor group replies: usually plugin not loaded or credentials expired; check list and login state, then the port.
2. Private works, group does not: usually access control or an @ requirement; confirm the group ID and trigger mode.
3. Replies once then silent: usually rate limiting or a session lock; read the limit records and adjust the interval.

"Replies once" is easily mistaken for a model crash. A crash usually has an error or timeout; rate limiting silently drops messages.

Group chat has one extra variable: whether an @ mention is required. Some implementations trigger only on mention, others on every message; confirm expectations first.

Verify and roll back

After changes, verify in three steps; roll back if it fails.

1. Single message: send from an allowed account and confirm a reply.
2. Group message: send in the target group using the expected trigger and confirm.
3. Burst: send three messages and confirm rate limiting and cooldown behave as expected.

Rollback beats continued tuning. After three configuration changes, return to the last working configuration and change one thing at a time.

Keep a verification record. Account, group, trigger mode, and result; the next incident can compare directly.

Next steps

Confirm the right plugin first, then trace four stages. For the IM bridge landscape, read How to connect WeChat, QQ, and Lark. For generic IM configuration, read How to connect DSH plugins to IM tools. For dsh-bot itself, read What dsh bot is.

Sources: dsh-qq plugin page, dsh-qqbot plugin page, dsh-im plugin page, dsh-bot plugin page