I used to run a Tor bridge on Windows at home, where I have a 300/150 Mbps ISP. This Windows has memory leak and crashes after some hours, ad I believe that was making my bridge never get traffic.

A few weeks ago I moved it to a Ubuntu server, also at home. I use uptimerobot.com to monitor if its port is reachable from outside and healthchecks.io to monitor if traffic entering from its local SOCKS port is reaching check.torproject.org. It's always up and reachable.

But nyx reports it's rarely getting any traffic, and its bandwidth never surpasses 1KB/s. Its log heartbeat reports very little download and upload and always claims to has seen 0 unique clients. But how come, if my healthchecks.io monitor's curl call uses it every few minutes?

metrics.torproject.org reports correct dates and uptime. Advertised Bandwidth is 58KB/s, way above what nyx reports. Flags are Fast, Running, V2Dir, Valid.

What might be wrong? Or is it normal for a Tor bridge relay be this idle? This is my torrc removing identifiable data.

## Configuration file for a typical Tor user
## Last updated 9 October 2013 for Tor 0.2.5.2-alpha.
## (may or may not work for much older or much newer versions of Tor.)

## A handle for your relay, so people don't have to refer to it by key.
Nickname MyNick
ContactInfo mycontact

## Entry policies to allow/deny SOCKS requests based on IP address.
SocksPort 9031
#SocksPort ::9031
#SocksPort 0.0.0.0:80
#SOCKSPolicy accept 192.168.*

## Send all messages of level 'notice' or higher to /var/log/tor/notices.log
Log notice file /var/log/tor/notices.log
## Send every possible message to /var/log/tor/debug.log
#Log debug file /var/log/tor/debug.log
## Use the system log instead of Tor's logfiles
#Log notice syslog

## Uncomment this to start the process in the background... or use
RunAsDaemon 1

## The directory for keeping all the keys/etc. By default, we store
## things in $HOME/.tor on Unix, and in Application Data\tor on Windows.
DataDirectory /var/lib/tor

## The port on which Tor will listen for local connections from Tor
## controller applications, as documented in control-spec.txt.
ControlPort 9051

## If you enable the controlport, be sure to enable one of these
## authentication methods, to prevent attackers from accessing it.
CookieAuthentication 1

################ This section is just for relays #####################
#
## See https://www.torproject.org/docs/tor-doc-relay for details.

## The IP address or full DNS name for incoming connections to your
## relay. Leave commented out and Tor will guess.
Address hikari.mydomain.com

## Required: what port to advertise for incoming Tor connections.
ORPort 80

## Uncomment this to mirror directory information for others. Please do
## if you have enough bandwidth.
DirPort 9030 # what port to advertise for directory connections

ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy
#ExtORPort 0.0.0.0:8000
ExtORPort 9041

## Uncomment to return an arbitrary blob of html on your DirPort. Now you
## can explain what Tor is if anybody wonders why your IP address is
## contacting them. See contrib/tor-exit-notice.html in Tor's source
## distribution for a sample.
#DirPortFrontPage /etc/tor/tor-exit-notice.html


ExitPolicy reject *:*       # don't run as an exit node
BridgeRelay 1               # bridge
PublishServerDescriptor 1   # published on bridge directory DB
BridgeRecordUsageByCountry 1 # it's nice to see the country codes of users you are assisting
#BandwidthRate 512000
#RelayBandwidthBurst 512000
#RelayBandwidthRate 512000

CellStatistics 1
PaddingStatistics 1
DirReqStatistics 1
EntryStatistics 1
ExitPortStatistics 1
ConnDirectionStatistics 1
HiddenServiceStatistics 1
ExtraInfoStatistics 1

#If non-zero, try to write to disk less frequently than we would otherwise. This is useful when running on flash memory or other media that support only a limited number of writes. (Default: 0)
AvoidDiskWrites 0