Skip to guide

Documentation 9.6.24

Troubleshooting

Start with the exact server, installed version, time and visible error. Remove secrets from any logs you share.

The bridge returns no data#

Check that the connection is not turned off on the server’s Tosun Connect card, that server.cfg does not set tosun_db_bridge_manual "1" without tosun_db_bridge_enabled "1", and that the legacy mirror (ts.panelMirror.enabled) is off. Then check oxmysql, supported framework/schema and recent connection status. A tosun-ac package older than 9.6.14 still needs set tosun_db_bridge_enabled "1" in server.cfg until the new package is installed. Requests are paginated and include only supported fields; the bridge does not mirror your entire database.

Can protection be guaranteed?#

No. Server validation, bounded event handling and restricted upload credentials reduce specific risks. Keep resources patched, review false positives, protect administrator accounts and rotate exposed keys. Package encryption does not make client code impossible to inspect.

Classify the failure before retrying#

Identify the failing stage: account login, payment, package download, resource startup, panel connection, bridge request or website publication. Find the first unsuccessful step and record its expected result instead of changing every setting at once.

Record the last working time, a recent version or configuration change and the account seeing the error. Console errors and panel messages may differ; compare their timestamps. Do not use an old display status to decide the state of the current server. One controlled reproduction often explains more than repeated restarts.

For an uncertain payment or economy-write outcome, stop retrying and check the current invoice or balance. Do not enable write privileges to solve a read error. Investigating on a production server does not require banning a real player, granting money or running a bulk administrative action.

Investigate a rejected download or startup#

Downloads evaluate the account’s entitlement, access to the selected server and server-management permission. A visible button does not authorize a link belonging to another account or server. Obtain the package from your own account’s download screen.

  1. Select the correct account and server. Read any billing or permission notice instead of using someone else’s link.
  2. Keep the resource named tosun-ac and verify the package was extracted completely. Check that files from old and new releases were not mixed.
  3. Review dependencies and the server.cfg startup order. Resolve the first console error without moving the license into client code.
  4. Give support the version, server ID and error text with secrets removed. Keep the downloaded archive and license out of public file shares.

Handle a waiting website, bridge or 2FA setup#

Website creation may still be queued; do not create the same website again. Check active-site status and HTTPS separately. A custom domain needs both routing and ownership TXT records. Saving its name does not complete certificate preparation.

The bridge is on by default and needs no extra server.cfg line; reads and balance edits still require panel permission. It does not answer if the connection was turned off on the server’s Tosun Connect card, if manual mode (set tosun_db_bridge_manual "1") is used without set tosun_db_bridge_enabled "1", or if the legacy full mirror is on (ts.panelMirror.enabled = true in configs/anticheat_config.lua); in that last case the bridge stays off so the mirror keeps working. Packages older than 9.6.14 still need set tosun_db_bridge_enabled "1" until you install the new package. Check the supported framework and schema, oxmysql and the latest connection status. Unsupported fields or an empty page do not establish that the whole game database is empty. The bridge is not a general SQL browser.

If the ten-minute 2FA setup session expired, restart and use the new QR or key. QR generation is local, and manual key entry is available. For a rejected code, check the correct authenticator account and phone clock. Never send backup codes or the setup key to support.

Make a support request actionable#

Prepare a compact, complete record. Replace “it does not work” with the action, result and time. These details identify the same resource for investigation without exposing credentials or unrelated customer information.

  • Resource: server, website or invoice ID; installed version and relevant framework.
  • Reproduction: screen opened, action taken, expected result and visible error.
  • Time: date and timezone, last working state and any recently changed setting.
  • Privacy: remove licenses, passwords, tokens, QR codes, banking codes, full card details and unnecessary player information.

Isolate a browser issue without losing evidence#

If a page loads incorrectly, write down its address, selected account and visible message before refreshing. Identify whether the issue is visual, a refused save or a failed external redirect. These symptoms have different causes; clearing every browser setting immediately can erase useful context without fixing the underlying permissions or service state.

For a read-only display issue, compare the same page in a fresh browser session and check extensions that block scripts or navigation. Confirm you signed into the intended account again. If an old form reports an expired security session, reopen the page through normal navigation instead of repeatedly submitting the stale form.

Keep payment attempts and economy writes outside this comparison until their original outcome is known. Do not copy session cookies or authentication headers into a support request. Report the browser version and whether the fresh session changed the result, alongside the original error and time.

Create a short reproduction with a clear stopping point#

Choose the smallest sequence that reaches the reported error using an account allowed to perform the action. For example, select a server, open its player list and record the response; there is no need to edit balances to demonstrate a read failure. State what should have happened at each step.

If the problem only occurs after a particular resource update or during a specific gameplay action, include that condition. Compare it with the last working setup and the relevant version. Stop after capturing the first failure, rather than accumulating repeated requests, restarts or extra changes that obscure the original cause.

Describe what you already checked and which results were unchanged. Share only the console lines surrounding the relevant error, removing secrets and unrelated player information. A compact reproduction gives an investigator a testable case and a clear boundary for deciding whether a proposed fix worked.

Confirm the fix against the original symptom#

After applying a proposed fix, repeat the original read or gameplay scenario under comparable conditions. Check both the immediate response and the relevant panel or console record. A disappeared banner alone does not prove that a download, server connection, website provision or payment confirmation reached its expected result.

Keep the old and new version or setting values in your change record. For a gameplay issue, try the affected ordinary action and a nearby unaffected action. For a website issue, verify the intended address and HTTPS result. For billing, use the existing invoice outcome rather than generating a test charge.

If the symptom returns, report the recurrence time and which conditions changed since verification. Restore a known working configuration only through your prepared recovery procedure. Retain the concise case history so the next investigation starts from verified observations rather than repeating the same unsuccessful guesses.

Prepare a support ticket with an anonymous worked example#

Open a new ticket in the panel’s Support area; your account needs support.create permission. Fill subject, category, priority and message using the fictional example below. A player-list read issue uses the technical category and normal priority. Choose priority according to the actual impact: a problem on one read screen is not an outage of the whole server. Display labels may change with the interface language; the values in parentheses are the current form choices. A support ticket does not require your licence, password or database access.

The server and reference names in this example are not customer records. Identify the relevant server in your authorised private ticket, and anonymise appropriately if you later share the text publicly. The message includes repeat steps and a stopping point: no balance was changed and no new job was started. The form checks a minimum of five characters for subject and ten for message; a concise title and explanation already satisfy these checks. Add later observations to the same ticket. Use only sanitised lines related to the problem instead of sending the entire console, an SQL dump or cookies. Selecting a priority does not guarantee a response time.

Subject: Player-list request does not complete
Category: Technical (technical)
Priority: Normal (normal)
Message:
Server: TEST-SERVER — anonymised for this example
Version / framework: 9.6.3 / QBCore — example values
Time: 2026-09-26 14:03 UTC
Steps: Selected the server; opened the player list once.
Expected: A completed first player page.
Observed: pending followed by a network timeout.
Reference: TEST-REQUEST — not a real request ID
Checked: resource started; the relevant read permission is present.
Stopping point: No new job or balance change was started.
Secrets, cookies, _csrf and player identifiers removed.

Choose the next step and stopping point from the symptom#

This decision sequence helps find the first failed step; it is not an automatic fix or a retry rule for every error. If the player list cannot open, first inspect the HTTP result: 401 points to the session, 419 to the form security value, 403 to account or service permissions, and 429 to capacity or waiting. If only one entry appears empty, check the character and supported schema. Similar symptoms can have different causes: a completed empty page and a rejected request are different events. Preserve existing evidence before following any branch.

For a pending economy write or a payment with an uncertain outcome, take the stop branch: inspect the existing request, invoice and current state before starting another operation. A resource that will not start leads to installation and the first console error; a legitimate movement flagged by AC leads to its integration and narrow permission duration. Do not disable all protection as a workaround. If a site is active but HTTPS fails, inspect domain and certificate stages separately. A changed local clock or screen is not completion of the server-side operation. Tell support which observation selected the branch; do not label an unknown result as successful. Record waiting, permission rejection and completed empty results separately.