Service status & availability Crypto-only billing · No-KYC signup

Network & protection

Request DDoS protection changes

Understand the baseline and advanced protection labels, preserve incident evidence, and queue a protection request without assuming it has been activated.

Tungsto documentation · Updated · 3 min read

On this page
  1. Before you start
  2. Understand the protection states
  3. Prepare a useful incident record
  4. Queue and escalate the change
  5. Validate the operational result
  6. Related resources

Before you start

  • A signed-in account with the target server visible in Account > Servers or Network.
  • The affected address, service, protocol, port, region, and incident start time in UTC.
  • Local application and interface observations that do not contain secrets or customer payloads.
  • A record of the server and incident details to include in a contact request.

Understand the protection states

Baseline DDoS protection is listed as included with every configuration. Advanced protection is an additional quoted option. The selected mode expresses your request. Filtering thresholds, protected protocols, mitigation locations, detection times, clean-traffic capacity, and the activation time must be confirmed with the operator.

Saving Advanced records the requested mode. The account does not display independent confirmation from the filtering service. Confirm the quote, protected traffic and activation time with the operator before relying on the new protection.

Prepare a useful incident record

DDoS mitigation and ordinary capacity troubleshooting overlap. High CPU, disk saturation, a software limit, a route problem, and hostile traffic can look similar from one application. Record evidence without claiming an attack before it is corroborated. Do not retaliate, scan suspected sources, or publish unverified attribution.

  • Server name, region, affected IPv4 or IPv6 address, and the service port or protocol.
  • Start time and last-known-normal time in UTC, plus whether the event is still active.
  • Observed symptom: timeout, latency, packet loss, connection exhaustion, or application overload.
  • Local interface error/drop counters and application health indicators before and during the event.
  • Representative source networks or destinations, without disclosing credentials or customer content.

Queue and escalate the change

The confirmation says the request was queued when the mode changes, or that the mode is already selected when unchanged. Neither message verifies upstream filtering. Repeating the same mode does not create another change or speed up activation.

  1. Open the target server in Account > Servers and confirm its name and region.
  2. Review the current displayed mode as a requested state, not a provider confirmation.
  3. Choose Baseline or Advanced and select Update protection once.
  4. Record the displayed confirmation, selected mode, server name and request time.
  5. For Advanced, contact the operator for the quote, supported traffic profile, and explicit activation confirmation.
  6. For an active incident, send the evidence package through Contact and state the impact and start time. Request submission alone does not provide an immediate response or mitigation guarantee.

Validate the operational result

After operator confirmation, validate the application from approved monitoring locations and compare interface and application metrics with the pre-incident baseline. Record the effective time, scope, and any limitations communicated by the operator. If service remains degraded, continue diagnosis rather than toggling modes repeatedly.

If the request was saved but no operator confirmation exists, describe it internally as pending. The present product does not expose mitigation telemetry, action polling, or an automated provider callback, so those gaps cannot be resolved from the account page alone.

EvidenceWhat it confirmsWhat remains unknown
Dashboard modeThe desired mode stored for the serverProvider activation and scope
Queued confirmationThe request was recordedCompletion or success
Operator activation messageThe operator reports fulfilmentWorkload behavior under real traffic
Application and network recoveryThe service is responding againCause unless separately investigated