# DoS attack on my relay
**URL:** https://forum.torproject.org/t/dos-attack-on-my-relay/21867
**Category:** Relay Operator
**Created:** [July 13, 2026, 9:35am UTC](https://forum.torproject.org/t/dos-attack-on-my-relay/21867 "2026-07-13T09:35:47Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Vort](https://forum.torproject.org/u/Vort)
#### Post date: [July 13, 2026, 9:35am UTC](https://forum.torproject.org/t/dos-attack-on-my-relay/21867/1 "2026-07-13T09:35:47Z")
My relay (v 0.4.9.11) was working fine for 1.5 months, but today problem appeared:
It consumed 6 GB of RAM instead of usual 1 GB and started to print warnings to the log file:
```auto
Jul 13 02:47:02.000 [notice] HSDir cache exceeded limit (214770954 > 214748364 bytes). Pruned 50032667 bytes during an HS descriptor upload.
Jul 13 05:37:05.000 [notice] General overload -> Ntor dropped (10102743) fraction 38.5814% is above threshold of 0.5000%
```
Relay restart did not helped much, but it changed type of warnings:
```auto
Jul 13 07:42:48.000 [notice] We're low on memory (cell queues total alloc: 1012968000 buffer total alloc: 57765888, tor compress total alloc: 0 (zlib: 0, zstd: 0, lzma: 0), rendezvous cache total alloc: 3704468). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
Jul 13 07:42:48.000 [notice] Removed 108354576 bytes by killing 4901 circuits; 117229 circuits remain alive. Also killed 0 non-linked directory connections. Killed 0 edge connections
```
Is there a way of controlling RAM usage besides MaxMemInQueues (which does not help much)?
Is this attack new? Will developers modify relay code to add protection against such attack?
---
### Author:  [@akarincode2770](https://forum.torproject.org/u/akarincode2770)
#### Post date: [August 15, 2026, 3:33pm UTC](https://forum.torproject.org/t/dos-attack-on-my-relay/21867/2 "2026-08-15T15:33:23Z")
It looks like someone is trying to flood your Tor relay by creating a large number of circuits? Tor comes with some defense parameters, and there’s an introduction link below.
> **[Denial-of-service parameters - Tor network parameters - Tor Specifications](https://spec.torproject.org/param-spec.html#dos)**
>
> This file lists the recognized parameters that can appear on the “params” line of a directory consensus.
I previously configured it to use all consensus default parameters (as follows), and since enabling these defenses I haven’t encountered any issues (other than my relay complaining in heartbeat messages that it killed a large number of DoS attack circuits).
```auto
DoSCircuitCreationEnabled 1
DoSCircuitCreationDefenseType 2
DoSConnectionEnabled 1
DoSConnectionDefenseType 2
DoSRefuseSingleHopClientRendezvous 1
DoSStreamCreationEnabled 1
DoSStreamCreationDefenseType 3
```
---
### Author:  [@Vort](https://forum.torproject.org/u/Vort)
#### Post date: [August 16, 2026, 1:06pm UTC](https://forum.torproject.org/t/dos-attack-on-my-relay/21867/3 "2026-08-16T13:06:11Z")
Here are few observations regarding this attack:
It is rare. It happens about once a month.
Most likely, it targets some specific service, which is occasionally registered on my relay because of HSDir flag. When flag is gone, attack is gone as well.
Relay restart actually helps, but not immediately: after an hour attack stops and relay can be restarted once more to free more RAM.
Such properties make testing of different configuration parameters inconvenient. But I will keep in mind your suggestion and will try it if something changes. Thank you.
---
### Author:  [@akarincode2770](https://forum.torproject.org/u/akarincode2770)
#### Post date: [August 18, 2026, 4:18am UTC](https://forum.torproject.org/t/dos-attack-on-my-relay/21867/4 "2026-08-18T04:18:35Z")
> **[Tor 0day: Crashing the Tor Network - The Hacker Factor Blog](https://www.hackerfactor.com/blog/index.php?%2Farchives%2F897-Tor-0day-Crashing-the-Tor-Network.html)**
This reminds me of the attack vector mentioned here: the attacker’s goal is to DDoS a specific Onion service, but they do so by taking down the Tor guard relays and directory relays that the service relies on.
In this scenario, it no longer matters whether the attacker is targeting your relay or that ‘unknown Onion service’—you both end up as victims.