Getting support

Where to ask about Nasnet Linux, what to put in a bug report, and how to share logs without leaking your secrets.

Last updated Aug 17, 2026View as Markdown

Overview

Nasnet Linux is maintained in the open by the people who use it. Questions go to the Telegram group, reproducible bugs go to the issue tracker, and anything with a security impact goes through a private channel. Whichever you pick, the panel logs are what turn a guess into an answer.

Before you ask

  1. Read Troubleshooting, where logins that will not stick, certificates that will not issue and empty subscription links are all covered with their causes.

  2. Read the logs, because the panel names the failing step in almost every case.

    docker compose logs -f app        # Compose install
journalctl -u nasnet-panel -f     # systemd install

  3. Confirm the panel restarted after your last .env change. Editing the file is not enough.

  4. Check your server against System requirements.

Where to go

Channel Use it for Where
Telegram Questions, setup help, sanity checks t.me/joinnasnet
GitHub issues Reproducible bugs and feature requests nasnet-panel-linux/issues
Security reports Anything with a security impact, never a public issue Report privately

Redact before you paste

The panel’s logs and .env are full of things that should not go into a public issue. Strip these every time:

  • JWT_SECRET_KEY and ADMIN_PASSWORD_HASH
  • DB_PASSWORD and any full database URL
  • TELEGRAM_BOT_TOKEN and WEBHOOK_URL
  • Subscription link keys, because a /sub/{key} URL is the credential
  • Your server’s public IP and domain, if you would rather not publish them

Replace each with a placeholder rather than deleting the line; knowing a value was set is often the point.

Reporting a bug

Include:

  • What you did, what happened, what you expected.
  • The version, given as a release tag or commit SHA.
  • How it is deployed, whether Docker Compose, systemd, a binary, or the offline bundle.
  • Which database you chose, PostgreSQL or SQLite.
  • The relevant log lines, redacted as above, with enough context around them to see what came before the failure.

Reporting a security problem

Do not open a public issue. Use GitHub’s private vulnerability reporting on the repository. Include reproduction steps, the version you tested against, and how the panel was deployed. Coordinated disclosure is preferred, so you will be asked to agree a publication date before an advisory goes out.