Whonix onion website / forum / debian package repository unreachable

mrxmr · July 13, 2026, 6:50am

Fail to refresh InRelease: tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion trixie InRelease from tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/trixie/InRelease
Fail to refresh InRelease: tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion trixie InRelease from tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/trixie/InRelease
Fail to refresh InRelease: tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion trixie InRelease from tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/trixie/InRelease
Fail to refresh InRelease: tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion trixie InRelease from tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/trixie/InRelease

mrxmr · July 14, 2026, 7:49am

Fail to refresh InRelease: tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion trixie InRelease from tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/trixie/InRelease
Fail to refresh InRelease: tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion trixie InRelease from tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/trixie/InRelease
Fail to refresh InRelease: tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion trixie InRelease from tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/trixie/InRelease
Fail to refresh InRelease: tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion trixie InRelease from tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/trixie/InRelease

nurmagoz · July 14, 2026, 1:57pm

The solution to the website onion services to make it reliable is to not use the anonymity benefit for the website and increase the speed and connection stability. This is adopted back in 2016 by facebook and riseup (and probably every project now which doesnt need anonymity).

Today, we are introducing Single Onion Services! With this new feature, a service can now specify in its configuration file that it does not need anonymity, thus cutting the 3 hops between the service and its Rendezvous Point and speeding up the connection.

github.com/torproject/torspec

proposals/260-rend-single-onion.txt

main

Filename: 260-rend-single-onion.txt
Title: Rendezvous Single Onion Services
Author: Tim Wilson-Brown, John Brooks, Aaron Johnson, Rob Jansen, George Kadianakis, Paul Syverson, Roger Dingledine
Created: 2015-10-17
Status: Finished
Implemented-In: 0.2.9.3-alpha

1. Overview

   Rendezvous single onion services are an alternative design for single onion
   services, which trade service-side location privacy for improved
   performance, reliability, and scalability.

   Rendezvous single onion services have a .onion address identical to any
   other onion service. The descriptor contains the same information as the
   existing double onion (hidden) service descriptors. The introduction point
   and rendezvous protocols occur as in double onion services, with one
   modification: one-hop connections are made from the onion server to the
   introduction and rendezvous points.

This file has been truncated. show original

Rendezvous single onion services are an alternative design for single onion services, which trade service-side location privacy for improved performance, reliability, and scalability.

Simple solution.

Even extra reliability/speed: We can host our own single node that the hidden service gonna use, this way we control the connection without relying on Tor network relays (but can be done later if needed).

cc @Patrick

Patrick · July 14, 2026, 9:02pm

Tor upstream DoS issue attacker can force intro point rotation by ddos reported by Tor developer Roger Dingledine. At the time of writing:

issue opened in year 2018,
Status Open, Not Scheduled,
last comment by Roger Dingledine in year 2023,
last ticket status change to Not Scheduled in December 2025.

nurmagoz · July 15, 2026, 4:53pm

Thats an assumption the mirrors are being attacked by ddos (we need an evidence otherwise its claim), but i think its a general design issue, which made projects are just skipping the anonymity of the server (since its not needed) and increasing the availability, thus everything is working fine on their side.

anon97457883 · July 19, 2026, 2:46am

Either DoS or lots of people updating/installing software in whonix. Is it due to the design and decision to host the forum and repo on same onion address?

Maybe one day there could have been an update to discourse forum software causing conflict now. Also people having the forum in RSS feed is another bandwidth point. I dont recall having this issue in the past (3-4 years ago) with reaching the deb repo.

Patrick · July 19, 2026, 8:53am

It’s not an assumption. It’s an example, that Tor upstream maintenance, stability of Tor onions is less than stellar.

More unresolved Tor upstream mysteries: Invalid HS descriptor.

Quote

Other project’s onion’s often also fail to pinpoint the exact reason for their onion reachablity issues, let alone apply durable stability fixes. Examples here:
Onion Domains by Other Projects

A wiki page to collect these kind of issues and troubleshooting tools has been created:

On general networking issues debugging (doesn’t even need to involve Tor, let alone onions):

Unsuitable, at the time of writing also has bugs and maintenance issues, documented here: OnionBalance

docker is a non-issue. download.whonix.org (or its onion) is simple, not docker.

And why do we need to even ask the question “is the onion fine, but the endpoint server broken?”

At least that one can be safely excluded somewhat easily: