When an application sees a 5xx spike, a backend becomes slow or a TLS handshake fails, the operations team needs data quickly. The traditional path is usually SSH, a jump host, VPN, a dedicated diagnostics machine and a manual command chain — losing time and making it hard to collect data from the exact point where the traffic problem is occurring.
Running dig on a separate server for DNS problems, conducting TLS scans on yet another machine and accessing the production device directly for packet capture all fragment the operation. When the network context where the issue exists differs from where the test is run, results can be misleading. The closer the diagnostic tool is to where traffic actually flows, the more valuable the result.
At the same time, granting full shell access in a production environment creates serious risk. Arbitrary command execution, deleting critical files with wrong parameters, unauthorized network scanning, unmonitored data export and missing audit trails are unacceptable in enterprise environments. Regulated infrastructures in particular require a clear answer to "who did what, and when?"
Safe diagnostics require two balances to hold at once: the operations team must have powerful enough tools, but those tools must not become a pass to run arbitrary commands. A whitelist, RBAC, audit log, sandbox and downloadable output management are critical for exactly this reason.
TR7's built-in network diagnostic approach meets production debug needs with a controlled command set — enabling packet, DNS, TLS, HTTP and system data collection without opening shell access.
TR7 makes network diagnostics safe through a whitelisted command set, controlled pipe chaining, downloadable output and an audit trail.
In TR7, diagnostic commands run against a pre-defined sys-cmd list. Users do not run free-form Linux commands — they diagnose through permitted tools and safe usage patterns only.
grep, wc, sort, head, tail, uniq, cut and to-file pipe operations are supported. This gives bash-like output processing convenience while staying under the control of the whitelist and depth limit.
Packet captures, TLS scans or any command output can be written to a file. Operations teams download the pcap or text artifact from the interface and use it for analysis, support or compliance review.
Command execution rights are controlled per role. Every invocation is recorded with user, timestamp, command and zone context, delivering fully auditable diagnostics in production.
TR7 Built-in Network Diagnostics consolidates core operations needs — from network connectivity to TLS, HTTP testing and system visibility — in a single controlled interface.
`ping`, `ping6`, `traceroute`, `fping`, `arping` and related tools let teams inspect connectivity and path issues. IPv4 and IPv6 access can be tested independently. Multi-host ping gives a quick status view across multiple targets. These tools help distinguish whether a backend access outage is network-related, route-related or target-related.
`dig` and `nslookup` query DNS records — A, AAAA, MX, TXT, CNAME and more. Running tests against different DNS servers reveals propagation gaps or resolver discrepancies. This is valuable after GTM changes, domain migrations or record updates. The team receives results from the network context where TR7 itself resides.
`curl` and `wget` directly test HTTP/HTTPS endpoints. Headers, status codes, content and redirect behavior can be inspected quickly. `h1load` and `wrk` enable controlled load tests or basic performance observations. This makes it easier to separate an application access problem from a network problem.
`sslscan` inspects protocol support, cipher suites and certificate behavior. `ssldump` provides more detailed tracing of TLS handshakes and packet flow. `tcpdump` captures packets on a specific interface, host or port. Output can be saved as a pcap via `to-file` and downloaded for deep analysis.
`netstat` and `ss` are available for open connections, listening ports and socket statistics. Heavy connection loads, TIME_WAIT increases, unexpected port usage or service listening state can all be checked quickly. Application-layer and OS connection state can be compared from the same screen during production incidents, accelerating response.
`ip`, `ipcalc`, `route-table`, `arp` and `htop` provide interface, subnet, route, ARP and process visibility. Core operations checks such as subnet planning, route validation and resource usage can be performed. Utility operations such as the disk extend wizard and temporary file management complete the diagnostic workflow, reducing the need for separate server access.
`nmap` enables port status checks, service detection and host discovery. `ftp` and `telnet` clients can be used for basic connectivity tests on legacy or custom protocol access. These tools are especially useful during internal service migrations to confirm that target ports are genuinely open and reachable. The whitelist approach ensures usage never devolves into uncontrolled shell access.
TR7 supports up to 8 levels of pipe chaining using grep, wc, sort, head, tail, uniq, cut and to-file. Operations teams can search large outputs, count lines, sort or trim results. `to-file` turns output into a downloadable file. This structure makes raw output more readable and shareable during rapid debugging sessions.
Built-in diagnostic tools are bounded by whitelist, sandbox, permission, output and audit controls so they operate safely in production.
The authoritative source for permitted commands is the sys-cmd and pipe lists in the WebConsole configuration. Users cannot run arbitrary system commands. This approach preserves debug power while constraining the executable surface.
Pipe chains are capped at 8 steps. This limit provides output-processing flexibility while preventing complex, hard-to-control command chains. Operations teams enjoy bash-like ergonomics, but system behavior remains predictable.
Command output can be retrieved in JSON, tab-separated, comma-separated, semicolon or compact formats. This supports both human-readable output and data intended for onward tooling. Format selection reduces effort during reporting and incident analysis.
Diagnostic commands run in a restricted shell and sandbox. Only the capabilities required for network diagnostics — NET_ADMIN and NET_RAW — are enabled; unnecessary system privileges are dropped. This model reduces the risk of command execution causing harm in the production environment.
Every sys-cmd invocation is logged with user, timestamp, command and zone context. These records are important for post-incident review and compliance audits. Who took which diagnostic step in production can be traced retrospectively.
`to-file` output makes pcap, text or scan result files available for download from the interface. Files can be shared with support teams, used for deep packet analysis or attached to incident records. Diagnostics cease to be ephemeral screen output and become persistent, shareable evidence.
The operations team can capture traffic to a specific backend using `tcpdump` with a bounded packet count. Once downloaded as a pcap, application, network and security teams can all analyze the same evidence.
When a client reports a TLS error connecting to a specific application, `sslscan` checks protocol support and cipher suite behavior. Results can be written to a file and shared with the customer or internal teams.
After a domain change, `dig` queries can be run against different DNS servers. The operations team sees which resolver returns which value for the record — directly from the TR7 interface.
`ping`, `tail`, `iftop` and socket tools enable inspection of latency, traffic load and connection state. This makes it faster to determine whether slowness stems from the network, service capacity or traffic volume.
Resolve network issues with ping, traceroute, tcpdump, sslscan and 28 tools — without granting shell access. Let's walk through a live demo on your own environment.