Tor Hidden Service: Vært Din Egen .onion I 11 Trin

En Tor hidden service, teknisk kaldet en onion service, lader dig køre en server der kun kan nås via Tor-netværket, uden at din rigtige IP-adresse nogensinde bliver synlig. Det bruges af alt fra journalister og whistleblower-platforme til almindelige nørder, der vil have et sted at dele filer eller køre et privat dashboard uden at eksponere en hjemmeadresse eller en portforward. I denne guide sætter vi en v3 onion service op fra bunden på en Debian/Ubuntu-server, kobler den til en lokal Nginx og går igennem de faldgruber, de fleste rammer første gang de prøver.

Modsat en VPN eller en almindelig webserver med HTTPS, skal en onion service ikke have en offentlig IP-adresse, et domænenavn eller et åbent indgående port. Tor-netværket håndterer hele routingen, og din server behøver aldrig at acceptere indgående forbindelser fra internettet. Det gør onion services til et af de få værktøjer, hvor serverens placering reelt er skjult, ikke bare krypteret i transit. Vi dækker både den grundlæggende opsætning og de sikkerhedsvalg, der afgør om den anonymitet rent faktisk holder i praksis.

Interessen for den slags selvhostede, decentrale infrastruktur er ikke tilfældig. Med debatten om digital suverænitet, skærpede krav til databeskyttelse under NIS2 og en stigende bevidsthed om, hvor meget metadata almindelig webtrafik lækker, søger flere nordiske organisationer og privatpersoner efter infrastruktur, de selv kontrollerer fra ende til ende. En onion service er en af de mest konkrete måder at opnå det på, fordi hverken serverens placering eller besøgendes identitet afhænger af en tredjeparts goodwill.

Hvad er en Tor hidden service, og hvornår giver det mening

En onion service er en server, der annoncerer sig selv til Tor-netværket via en kryptografisk adresse i stedet for en IP. Adressen ender på .onion og er afledt direkte af et offentligt nøglepar, så ingen central myndighed udsteder eller kan tilbagekalde den. Version 3 af protokollen, som har været standard siden 2021, bruger 56 tegn lange adresser baseret på ed25519-nøgler, og den ældre v2-protokol med 16-tegns adresser er helt udfaset af Tor Project.

Det typiske brugsmønster er tredelt. Første gruppe er whistleblower- og kildebeskyttelsesplatforme, hvor SecureDrop er referenceeksemplet, brugt af medier som The Guardian og New York Times til at modtage dokumenter uden at kunne spores tilbage til afsenderen. Anden gruppe er personlige og organisatoriske tjenester, hvor man vil tilbyde et sted at logge ind, dele filer eller køre et internt værktøj uden at offentliggøre serverens fysiske placering. Tredje gruppe er midlertidig fildeling og chat via OnionShare, hvor en onion service oprettes og lukkes igen inden for minutter eller timer.

Det er vigtigt at skelne mellem klientsiden (Tor Browser, som du sikkert allerede har stiftet bekendtskab med) og serversiden, som er det, vi bygger her. Hvis du endnu ikke har styr på selve browserdelen, er det en god idé at læse vores guide til Tor Browser opsætning først, så du har et testmiljø klar til at verificere din nye service.

Sådan fungerer onion routing i praksis

For at forstå hvorfor opsætningen virker, som den gør, hjælper det at kende de tre led i kæden. Når din Tor-daemon starter en hidden service, vælger den først et antal introduktionspunkter, almindelige Tor-relæer der har sagt god for at videresende forespørgsler på dine vegne uden selv at kende din servers rigtige placering. Din server opretter en krypteret kreds til hvert introduktionspunkt og venter der.

Dernæst publicerer din Tor-daemon en deskriptor, et lille signeret dokument der lister dine introduktionspunkter og er krypteret med en nøgle afledt af din onion-adresse. Deskriptoren lægges i Tors distribuerede hash-tabel, så kun en klient der allerede kender den fulde .onion-adresse kan finde og dekryptere den. Det er grunden til, at en onion-adresse ikke kan gættes eller crawles på samme måde som et almindeligt domæne; uden adressen er deskriptoren ren krypteret støj for omverdenen.

Når en besøgende i Tor Browser indtaster din adresse, slår klienten deskriptoren op, vælger selv et rendezvous-punkt (et tredje, neutralt relæ), og beder et af dine introduktionspunkter om at fortælle din server, at en klient venter ved det rendezvous-punkt. Din server opretter derefter sin egen kreds til samme rendezvous-punkt, og de to kredse mødes der. Resultatet er, at hverken du eller den besøgende kender hinandens virkelige IP-adresse, og rendezvous-punktet kender ingen af jeres identiteter, kun at det videresender trafik mellem to kredse. Det er denne trelagede konstruktion, introduktionspunkt, deskriptor og rendezvous-punkt, der gør, at onion services kan tilbyde gensidig anonymitet, hvor almindelig Tor-browsing kun skjuler klienten.

Forudsætninger og versioner

Før du går i gang, skal følgende være på plads. Listen er bevidst kort, fordi en onion service i sin kerne ikke kræver meget mere end en fungerende Tor-installation og en webserver.

En Linux-server, fysisk eller virtuel. Debian 12 eller Ubuntu 24.04 LTS er de mest afprøvede platforme til Tor-pakken.
Root- eller sudo-adgang til serveren.
Tor-daemonen installeret fra enten distributionens officielle repository eller Tor Projects eget apt-repo (anbefales, da distributionens version ofte halter).
Nginx som lokal webserver, eller en hvilken som helst applikation der kan lytte på localhost eller en Unix-socket.
Tor Browser installeret på en separat maskine til at teste adgangen, gerne nyeste udgave fra torproject.org.
Grundlæggende kendskab til at redigere konfigurationsfiler og genstarte systemd-services.
Minimum 15-30 minutter afsat, afhængigt af om du også sætter TLS og client authorization op.

Du kan altid tjekke den installerede version af Tor-daemonen direkte på serveren, så du ved præcis hvad du arbejder med:

tor --version

Bemærk at Tor Project også udvikler Arti, en nyere implementering skrevet i Rust, som fik versionerne 1.8.0 i december 2025 og 1.9.0 i januar 2026 med forbedringer til onion services. Arti og den klassiske tor-daemon har separate versionsnumre og separate udgivelsesplaner, så forveksl ikke de to når du læser release notes. Til denne guide bruger vi den klassiske, modne tor-daemon, fordi den stadig er standarden for produktionsdrift af onion services.

Vælg den rigtige server til din onion service

Valget af hostingmiljø påvirker, hvor meget din onion-opsætning reelt beskytter dig. En billig VPS betalt med et kreditkort, der er knyttet til dit navn, giver stadig en papirspor fra server til person, selv om serverens IP-adresse aldrig vises til dine besøgende. Hvis anonymitet over for hostingudbyderen selv er en del af din trusselsmodel, bør du overveje betalingsmetoder der ikke går tilbage til din identitet, og en udbyder hvis logningspolitik du reelt har læst, ikke bare antaget.

For de fleste praktiske formål, en personlig blog, et internt firmaværktøj eller en mindre fildelingstjeneste, er en almindelig VPS fra en europæisk udbyder fint, fordi truslen handler mere om at skjule serverens netværksplacering for besøgende end om at skjule den for udbyderen selv. For tjenester med en skarpere trusselsmodel, som en kildebeskyttelsesplatform, bør du overveje geografisk spredning af infrastruktur, separate udbydere til forskellige dele af opsætningen, og en klar plan for hvad der sker, hvis en server bliver beslaglagt.

Uanset udbyder gælder samme tekniske regler som i resten af denne guide: ingen offentligt bundet backend, logging holdt på et minimum, og krypterede backups af HiddenServiceDir et andet sted end selve serveren. Infrastrukturvalget ændrer trusselsmodellen, men det ændrer ikke de grundlæggende Tor-konfigurationsprincipper. Skal du i stedet beskytte en hel arbejdsstation frem for blot en server, kan vores guide til Whonix-opsætning være et naturligt supplement, da den dækker et komplet isoleret operativsystem bygget til at køre al trafik gennem Tor.

Trin 1: Installer Tor-daemonen

På Debian og Ubuntu er den hurtigste vej via distributionens pakker, men Tor Projects eget repository giver dig hurtigere sikkerhedsopdateringer. Start med den simple vej:

sudo apt update
sudo apt install -y tor

Vil du i stedet bruge Tor Projects eget repo for hurtigere patches, tilføjer du deres GPG-nøgle og kildeliste efter instruktionerne på deres officielle installationsside, og kører derefter samme apt install-kommando. Når installationen er færdig, kører Tor automatisk som en systemd-service under en dedikeret bruger, typisk debian-tor. Bekræft at den kører:

sudo systemctl status tor

Hvis statussen viser active (running), er grundinstallationen i hus. Hvis du i stedet skal køre Tor på et system med AI-sårbarhedsscanninger og automatiseret patching, kan det være relevant at kigge på vores gennemgang af nylige sårbarheder i Tor-netværket, inden du binder en produktionstjeneste op på en bestemt version.

Trin 2: Installer og konfigurer en lokal webserver

Din onion service skal pege på noget. Vi bruger Nginx, fordi det er let, velafprøvet og nemt at låse ned til kun at lytte lokalt:

sudo apt install -y nginx

Opret en minimal konfiguration, der kun lytter på localhost. Det er afgørende: hvis Nginx også lytter på den offentlige netværksinterface, har du lige lavet en offentligt tilgængelig server ved siden af din “skjulte” tjeneste, hvilket underminerer hele pointen.

server {
    listen 127.0.0.1:8080;
    server_name _;

    root /var/www/onion-site;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Gem filen i /etc/nginx/sites-available/onion-site, link den til sites-enabled, og test konfigurationen før genstart:

sudo ln -s /etc/nginx/sites-available/onion-site /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

Lav en simpel testside, så du har noget at verificere med senere:

sudo mkdir -p /var/www/onion-site
echo "Min onion service virker
" | sudo tee /var/www/onion-site/index.html

Tjek at den svarer lokalt, inden Tor overhovedet kommer i spil:

curl http://127.0.0.1:8080

Trin 3: Konfigurer onion service i torrc

Nu kommer kernen i opsætningen. Åbn Tor-daemonens konfigurationsfil, typisk /etc/tor/torrc, og tilføj følgende tre linjer:

HiddenServiceDir /var/lib/tor/my-website/
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:8080

Her betyder HiddenServiceDir den mappe, hvor Tor gemmer din onion-identitet (de private nøgler og den genererede adresse). HiddenServiceVersion 3 slår fast at du bruger den aktuelle protokolversion. HiddenServicePort kortlægger den offentlige onion-port (80, altså almindelig HTTP set fra Tor Browser) til din lokale Nginx-instans på 127.0.0.1:8080.

Hvis du foretrækker Unix-sockets i stedet for TCP, et lidt mere avanceret men marginalt mere effektivt setup, ser konfigurationen sådan ud:

HiddenServiceDir /var/lib/tor/my-website/
HiddenServiceVersion 3
HiddenServicePort 80 unix:/var/run/tor/my-website.sock

Opret selve mappen med de rigtige ejerskaber og rettigheder, inden du genstarter. Tor nægter at starte en hidden service, hvis mappen har forkerte rettigheder, som en sikkerhedsforanstaltning mod at nøglefiler bliver læsbare for andre brugere på systemet:

sudo install -d -o debian-tor -g debian-tor -m 0700 /var/lib/tor/my-website

Valider konfigurationen før genstart, så du fanger syntaksfejl uden at tage produktionen ned:

sudo tor --verify-config -f /etc/tor/torrc
sudo systemctl restart tor

Trin 4: Find din onion-adresse

Når Tor genstarter med en ny HiddenServiceDir, genererer den automatisk et nøglepar og udleder din .onion-adresse fra den offentlige nøgle. Adressen ligger i en fil kaldet hostname inde i den mappe, du angav:

sudo cat /var/lib/tor/my-website/hostname

Output ligner noget i denne stil (eksemplet er opdigtet og peger ikke på en reel adresse):

a3x7k9m2qp5rtn8vwzb4chdflgs6yuio1e0jxcv9mkl2oqprstu.onion

De 56 tegn er ikke tilfældige i betydningen “arbitrære”, de er matematisk afledt af din offentlige ed25519-nøgle, hvilket er præcis det, der gør adressen selvcertificerende. Du behøver ingen certificeringsmyndighed, intet DNS-opslag, og ingen tredjepart kan udstede en falsk adresse der matcher din nøgle.

Trin 5: Test adgang via Tor Browser

Åbn Tor Browser på en anden maskine (eller samme maskine hvis du kun tester), og indtast adressen fra hostname-filen i adressefeltet. Du bør se din testside med “Min onion service virker”. Hvis siden ikke loader, er fejlsøgningsafsnittet længere nede i denne guide dit næste stop.

Det er værd at bemærke, at onion-adresser ikke kræver certifikater for at blive vist som “sikre” i browseren, fordi hele Tor-forbindelsen allerede er end-to-end krypteret af selve protokollen. Det betyder dog ikke, at du kan ignorere applikationssikkerhed, det betyder bare at transportlaget er dækket af Tor i stedet for af TLS.

Trin 6: Lås adgangen med client authorization (valgfrit, men anbefalet til private tjenester)

Hvis din onion service er tiltænkt en lille, kendt gruppe (en SecureDrop-redaktion, et internt team, en håndfuld samarbejdspartnere), kan du kræve at klienter har en specifik nøgle for overhovedet at kunne nå frem til tjenesten. Det kaldes client authorization og forhindrer, at adressen bliver nyttig for andre end dem, du selv har godkendt, selv hvis adressen lækker.

Først genererer du et nøglepar til klienten:

mkdir -p ~/onion-auth
cd ~/onion-auth
openssl genpkey -algorithm x25519 -out client-priv.pem
openssl pkey -in client-priv.pem -pubout -out client-pub.pem

Du skal derefter konvertere nøglerne til det format, Tor forventer (base32-kodede nøgler uden padding), og placere den offentlige del i en authorized_clients-mappe under din HiddenServiceDir, samt pege torrc på mappen med ClientOnionAuthDir. Den private nøgle distribueres separat og sikkert til den person, der skal have adgang, og lægges i deres Tor-klients onion-auth-mappe. Når det er sat op korrekt, vil ubudne besøgende der kender adressen, men ikke har nøglen, blot se en fejl om at tjenesten ikke kunne nås, i stedet for noget der afslører at tjenesten overhovedet eksisterer for dem.

Trin 7: Opsæt logging og begræns hvad der gemmes

Standard Nginx-logs gemmer klient-IP, men når trafikken kommer via Tor, vil den “klient-IP” du ser altid være en lokal loopback-adresse eller en Tor-relænode, ikke den rigtige besøgendes adresse. Det er i sig selv fint for anonymiteten, men betyder også at dine logs ofte er mindre nyttige til fejlsøgning end du er vant til, og at de i stedet primært indeholder tidsstempler og URL-stier, som kan være sensitive i deres egen ret.

En fornuftig balance er at reducere logniveauet til kun fejl, rotere logs aggressivt, og undgå at logge forespørgselsparametre som kan indeholde personlige data:

access_log off;
error_log /var/log/nginx/onion-error.log warn;

Sæt dette i din server-blok, og beslut dig for en konkret retentionspolitik: hvor længe skal fejlelogs ligge, før de slettes automatisk. En simpel logrotate-regel med en kort retention er ofte nok.

Trin 8: Beskyt den private nøgle

Filerne i din HiddenServiceDir, særligt hs_ed25519_secret_key, er din onion-services identitet. Hvis de lækker, kan en anden part klone din adresse et andet sted og udgive sig for at være dig, uden at nogen besøgende kan se forskel. Tor Project advarer eksplicit om dette i deres egen dokumentation om onion service-nøgler.

Konkret betyder det tre regler, som er nemme at overtræde ved et uheld:

Kopier aldrig HiddenServiceDir ind i en webroot, en backup-mappe der synkroniseres til cloud, eller et versioneret repository.
Hold mappen på 0700-rettigheder ejet af tor-brugeren. En verdenslæsbar mappe er samme risiko som en lækket nøgle.
Hvis du skal flytte adressen til en ny server, kopier hele mappen (ikke bare hostname-filen) via en krypteret kanal, og slet den fra den gamle server bagefter.

Trin 9: Hærd applikationslaget, ikke kun transportlaget

Det mest almindelige fejlsyn er at tro, at Tor “gør tjenesten sikker”. Tor skjuler serverens placering og krypterer transporten. Den retter ikke sårbarheder i WordPress, PHP, en database eller din egen applikationskode. En onion service, der kører en forældet CMS-version, er lige så udnyttelig som en klarnet-server med samme sårbarhed, bare uden det ekstra lag af at kunne finde serveren ved at scanne IP-ranges.

Konkret bør du som minimum: holde applikationssoftware opdateret, undgå unødvendige admin-paneler tilgængelige fra onion-adressen, validere al input, sætte rate limiting på tunge endpoints, og bruge en dedikeret systembruger til webapplikationen i stedet for at køre den som root. Overvej også AppArmor eller SELinux-profiler, hvis din distribution understøtter det godt, som et ekstra lag omkring webserverprocessen.

Du kan desuden overveje at bruge Fail2ban mod gentagne login-forsøg på administrative endpoints, men husk at det er en beskyttelse mod brute-force, ikke en anonymitetsmekanisme i sig selv.

Trin 10: Undgå at lække identitet gennem indhold

Selv en teknisk perfekt onion-opsætning kan afsløre driftsherren via indholdet, der serveres. Absolutte links der peger på dit klarnet-domæne, tredjeparts-fonts og analytics-scripts der ringer hjem til et eksternt domæne, kan hver især lække forbindelsen mellem onion-adressen og din virkelige identitet. Et favicon eller en unik fejlside, der er identisk med en klarnet-side du allerede driver, kan være nok til at en modstander kan korrelere de to.

Dokumenter og billeder er en særlig risiko. EXIF-data i billeder, forfatterfelter i PDF-filer og endda skrivestil kan afsløre hvem der driver tjenesten. Hvis du uploader dokumenter eller billeder til din onion service, er det værd at køre dem gennem et metadata-fjernelsesværktøj først. Vi har tidligere gennemgået både MAT2 og ExifTool til netop dette, og begge er relevante at have i sin værktøjskasse, hvis onion-tjenesten modtager filer fra brugere.

Trin 11: Overvåg driftstid og automatiser sundhedstjek

En onion service, der falder ned uden at du ved det, er værre end ingen service, fordi besøgende blot ser en generisk timeout uden forklaring. Det nemmeste værktøj til at tjekke, om din tjeneste reelt svarer via Tor-netværket (ikke bare lokalt på serveren), er torsocks, som lader dig køre en almindelig curl-kommando gennem Tor-kredse:

sudo apt install -y torsocks
torsocks curl -s -o /dev/null -w '%{http_code}\n' http://DIN-ONION-ADRESSE.onion

Får du et 200-svar, er tjenesten reelt nåelig udefra, ikke kun på localhost. Byg dette ind i et lille overvågningsscript, der kører fra en helt anden maskine end selve serveren (ellers overvåger du ikke andet end, at din egen server kan nå sig selv):

#!/bin/bash
ONION="DIN-ONION-ADRESSE.onion"
CODE=$(torsocks curl -s -o /dev/null -w '%{http_code}' --max-time 30 "http://$ONION")
if [ "$CODE" != "200" ]; then
    echo "ADVARSEL: onion service svarede med $CODE klokken $(date)" >> /var/log/onion-watch.log
fi

Sæt scriptet i en cronjob, der kører hvert 10.-15. minut, og send dig selv en notifikation (mail, Signal, eller hvad du nu bruger) når loggen vokser. Hold øje med responstider over tid også: en gradvis stigning i svartid kan være et tidligt tegn på at serveren er ved at blive overbelastet, eller at et introduktionspunkt har problemer, længe inden tjenesten helt falder ned.

Komplet eksempel: en minimal onion-blog fra start til slut

Sætter vi alle trinene sammen, ser den fulde torrc-sektion og filstruktur for et minimalt, statisk onion-site sådan ud:

# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/my-blog/
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:8081

# /etc/nginx/sites-available/my-blog
server {
    listen 127.0.0.1:8081;
    server_name _;
    root /var/www/my-blog;
    index index.html;
    access_log off;
    error_log /var/log/nginx/my-blog-error.log warn;
}

Komplet kommandosekvens fra en frisk server til en kørende onion-blog:

sudo apt update && sudo apt install -y tor nginx
sudo mkdir -p /var/www/my-blog
echo "Velkommen til min onion-blog" | sudo tee /var/www/my-blog/index.html
sudo ln -s /etc/nginx/sites-available/my-blog /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl restart nginx
sudo install -d -o debian-tor -g debian-tor -m 0700 /var/lib/tor/my-blog
sudo tor --verify-config -f /etc/tor/torrc
sudo systemctl restart tor
sleep 5
sudo cat /var/lib/tor/my-blog/hostname

Efter disse kommandoer har du en fungerende, om end helt minimal, onion service. Resten af arbejdet, client authorization, hærdning og indholdsgennemgang, er lag du bygger på toppen afhængigt af hvor sensitiv tjenesten er.

Følgeprogrammer: OnionShare som alternativ til manuel opsætning

Hvis du kun skal dele filer midlertidigt eller hoste en kortvarig side uden at bygge en hel server-stak, er OnionShare et modent alternativ. Programmet pakker hele torrc-konfigurationen, nøglegenerering og en indbygget webserver ind i en grafisk klient, så du aldrig selv skal røre torrc. OnionShare 2.6.3, udgivet i februar 2025, indeholdt sikkerhedsrettelser til sti-sanitisering, bedre modstandsdygtighed mod denial-of-service i Receive-mode, og hærdning af sessions- og brugernavne-håndtering i Chat-mode.

OnionShare er det rigtige valg, når du vil dele et dokumentsæt med en enkelt kilde, modtage filer anonymt fra en kontakt, eller køre en engangs-chat, og det er markant hurtigere at sætte op end den manuelle Nginx/Tor-stak. Til vedvarende, produktionsagtige tjenester, som en redaktions tiplinje eller et internt firmaværktøj, er den manuelle opsætning stadig den rigtige vej, fordi du får fuld kontrol over logging, hærdning og driftskontinuitet.

Sammenligning: onion service vs. traditionel server med VPN

Egenskab	Tor onion service	Traditionel server + VPN
Kræver offentlig IP	Nej	Ja, eller en VPN-udbyders IP
Kræver portforwarding	Nej	Ofte ja
Skjuler serverens placering	Ja, som designmål	Nej, kun klientens placering skjules
Kræver DNS/domæne	Nej	Normalt ja
Typisk ventetid for besøgende	Højere, pga. relæ-routing	Lavere, direkte routing
Beskytter mod applikationssårbarheder	Nej	Nej
Kræver certifikat for “sikker” status	Nej, Tor krypterer transporten	Ja, TLS-certifikat nødvendigt

Onion service vs. OnionShare: hvornår bruger man hvad

Scenarie	Manuel Tor + Nginx	OnionShare
Vedvarende tjeneste over måneder	Anbefalet	Ikke tiltænkt
Engangs-fildeling med en kilde	Overkill	Anbefalet
Fuld kontrol over logging	Ja	Begrænset
Kræver teknisk opsætning	Ja, torrc og webserver	Nej, grafisk klient
Passer til organisationer (SecureDrop-stil)	Ja, med videre hærdning	Kun til mindre ad hoc-brug

5 almindelige fejl, du bør undgå

De fleste problemer med onion services opstår ikke i selve Tor-konfigurationen, men i de beslutninger der omkranser den. Her er de fem, vi ser oftest.

At binde backend-webserveren til en offentlig interface. Hvis Nginx eller din applikation lytter på 0.0.0.0 i stedet for 127.0.0.1, har besøgende en genvej uden om Tor, og din server har pludselig en synlig IP-adresse alligevel.
At kopiere HiddenServiceDir ind i en backup der synkroniseres et usikkert sted hen. Den private nøgle i den mappe er hele identiteten. Et uheld her kan ikke rulles tilbage.
At bruge klarnet-ressourcer inde på siden. Fonts, analytics, billeder hostet på et andet domæne, eller endda absolutte links tilbage til en klarnet-version af siden, kan afsløre forbindelsen mellem de to identiteter.
At tro Tor erstatter applikationssikkerhed. En forældet plugin-version eller en SQL injection-sårbarhed er lige så farlig bag en onion-adresse som på en almindelig server.
At flytte eller slette HiddenServiceDir uden en plan. Gør du det ved en fejl, mister du adressen permanent, og alle der har gemt den gamle adresse kan ikke længere nå tjenesten.

Fejlsøgning: når tjenesten ikke virker som forventet

Her er de problemer, der dukker op oftest, og hvordan du løser dem.

Tor starter ikke efter ændring i torrc. Kør sudo tor –verify-config -f /etc/tor/torrc og læs fejlbeskeden, den peger som regel direkte på linjenummeret med problemet.
hostname-filen findes ikke. Mappen havde sandsynligvis forkerte rettigheder, eller Tor nåede ikke at genstarte korrekt. Tjek sudo journalctl -u tor -n 50 for fejl i loggen.
Onion-adressen loader ikke i Tor Browser. Bekræft først at backend-serveren svarer lokalt med curl http://127.0.0.1:PORT, inden du leder efter fejl i Tor-laget.
“Permission denied” i Tor-loggen omkring HiddenServiceDir. Rettighederne er ikke 0700, eller mappen ejes ikke af tor-brugeren. Kør install-kommandoen fra trin 3 igen.
Siden virker, men meget langsomt. Det er delvist forventet, da trafik routes gennem flere Tor-relæer. Store billeder og tunge scripts forstærker problemet markant mere på Tor end på almindelig HTTP.
Adressen stopper med at virke efter en servermigrering. Du har sandsynligvis ikke kopieret hele HiddenServiceDir, kun hostname-filen. Hostname er et afledt output, ikke identiteten selv.
Client authorization blokerer også dig selv. Tjek at din egen Tor Browser-klient har den private nøgle lagt korrekt i sin onion-auth-mappe, og at nøgleformatet er base32 uden padding, som Tor forventer.
Nginx-loggen viser ingen besøgende overhovedet. Det er normalt hvis access_log er slået fra, hvilket vi anbefalede i trin 7. Slå den midlertidigt til under fejlsøgning, og sluk den igen bagefter.
Mistanke om at tjenesten er langsommere end normalt pga. et DDoS-forsøg. Overvej rate limiting på applikationsniveau, og separer offentligt tilgængeligt indhold fra administrative endpoints, så et angreb på det ene ikke lammer det andet.

Avancerede tips til produktionsdrift

Når grundopsætningen kører stabilt, er der et par ekstra lag der er værd at overveje, særligt hvis tjenesten skal køre i længere tid eller håndtere sensitivt indhold.

Overvej at køre flere onion-instanser af samme tjeneste på forskellige servere med load balancing på applikationsniveau, så et enkelt serverudfald ikke tager tjenesten helt ned. Tor understøtter desuden flere HiddenServicePort-linjer under samme HiddenServiceDir, hvis du skal eksponere mere end én port, for eksempel både HTTP og et separat API.

Hold et øje med Tor Projects sikkerhedsannonceringer, og opdater pakken så snart en ny stabil version udkommer. Skelnet klart mellem meddelelser om den klassiske tor-daemon og meddelelser om Arti, da de to har separate sårbarhedsspor; Arti fik for eksempel rettet to mellemsvære denial-of-service-sårbarheder, kaldet TROVE-2026-024 og TROVE-2026-027, i version 2.5.0 i juni 2026, men det siger ikke noget om tilstanden i den klassiske tor-daemon.

Til organisationer der driver en tiplinje eller lignende, er det værd at bygge på et modent framework som SecureDrop i stedet for at opfinde logikken selv, fordi den slags projekter allerede har løst mange af de operationelle detaljer omkring kildebeskyttelse, som er lette at overse i en hjemmelavet løsning.

Endelig: tag regelmæssige, krypterede backups af HiddenServiceDir, gemt et sikkert sted uden offentlig adgang. Mister du den mappe uden backup, mister du adressen permanent, og der er ingen “gendan adgangskode”-funktion for en onion-identitet.

Praktisk backup af onion-identiteten

En simpel, men effektiv tilgang er at pakke HiddenServiceDir ind i en GPG-krypteret arkivfil og flytte den væk fra serveren via en allerede krypteret kanal som SSH. Stop aldrig Tor-processen midt i en kopiering, da det kan give en delvist skrevet nøglefil:

sudo tar -czf - -C /var/lib/tor my-website | \
  gpg --symmetric --cipher-algo AES256 -o onion-backup-$(date +%F).tar.gz.gpg

Flyt den krypterede fil til et separat system, gerne offline eller i en separat administrativ zone, og test jævnligt at du faktisk kan dekryptere og gendanne den. En backup, du aldrig har testet gendannelse af, er i praksis ikke en backup. Når du skal flytte tjenesten til en ny server, genopretter du blot mappen med samme rettigheder som i trin 3, før du peger den nye torrc på den:

gpg -d onion-backup-2026-10-01.tar.gz.gpg | sudo tar -xz -C /var/lib/tor
sudo chown -R debian-tor:debian-tor /var/lib/tor/my-website
sudo chmod 0700 /var/lib/tor/my-website
sudo systemctl restart tor

Adressen fra den gamle server dukker nu op igen på den nye, uændret, fordi identiteten ligger i nøglefilerne, ikke i hvilken fysisk maskine der kører dem.

Hærdning af Tor-processen med systemd

De fleste moderne distributioner leverer allerede en rimeligt hærdet systemd-unit til Tor, men det er værd at tilføje et sæt yderligere begrænsninger via en override-fil, så processen har så lidt adgang til resten af systemet som muligt:

sudo systemctl edit tor

Indsæt følgende i den tomme override-fil, der åbnes:

[Service]
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tor /var/log/tor

Gem filen, genindlæs systemd, og genstart Tor for at anvende ændringerne:

sudo systemctl daemon-reload
sudo systemctl restart tor
sudo systemctl status tor

Disse direktiver betyder i praksis, at selv hvis der skulle opstå en sårbarhed i Tor-processen, kan den ikke skrive til resten af filsystemet, ikke læse brugernes hjemmemapper, og ikke hæve sine egne rettigheder. Det er et billigt ekstra lag, der tager to minutter at sætte op.

Beskyt mod guard discovery med Vanguards

En af de mere avancerede trusler mod en langvarig onion service er, at en modstander, der kan observere nok trafik over tid, i teorien kan forsøge at identificere din servers guard-relæ, det første relæ i dine Tor-kredse, og derfra nærme sig din virkelige placering. Tor Projects eget tillæg Vanguards er udviklet specifikt til at reducere denne risiko ved at styre, hvordan og hvor ofte dine kredse vælger mellemliggende relæer.

Vanguards er særligt relevant for tjenester, der kører i måneder eller år og derfor giver en modstander lang tid til at samle observationer. Til en kortvarig test eller en lavrisiko-blog er det sjældent nødvendigt, men til en whistleblower-platform eller lignende med en skarp trusselsmodel er det et lag, der er værd at undersøge og installere, sammen med at følge Tor Projects egen dokumentation om emnet tæt, da præcise konfigurationsdetaljer ændrer sig med nye udgivelser.

Juridiske og etiske overvejelser for et nordisk publikum

At drive en onion service er ikke i sig selv ulovligt i Danmark eller de øvrige nordiske lande. Det samme ansvar for indhold, databeskyttelse og håndtering af misbrug gælder, uanset om tjenesten nås via klarnet eller via Tor. Hvis din tjeneste indsamler persondata, for eksempel i form af kontaktformularer eller filupload fra identificerbare personer, gælder GDPR fuldt ud, og du skal stadig have en lovlig hjemmel og en opbevaringspolitik for de data.

Driver du en tjeneste tiltænkt at modtage sensitivt materiale, som dokumenter fra en kilde, er det værd at have en skriftlig proces for, hvordan modtaget materiale opbevares, hvem der har adgang, og hvor længe det ligger, inden du går live. Det er lettere at designe de processer ind fra starten end at lappe dem på bagefter. Du kan finde flere af vores guides til krypteret kommunikation og anonymitet under privatliv-sektionen på shattered.io.

Ofte stillede spørgsmål

Er en Tor onion service det samme som at bruge Tor Browser?
Nej. Tor Browser er klientsiden, den du bruger til at browse anonymt. En onion service er serversiden, altså en tjeneste du selv driver, der kun kan nås via Tor-netværket. De to bruger samme underliggende netværk, men løser forskellige opgaver.

Kræver det en offentlig IP-adresse at køre en onion service?
Nej, det er netop pointen. Serveren behøver ingen offentlig IP, intet domænenavn og ingen portforwarding. Tor-netværket håndterer hele routingen til din onion-adresse.

Hvor mange onion services findes der aktivt i 2026?
Der findes ikke et autoritativt, entydigt tal. Offentligt tilgængelige estimater varierer afhængigt af målemetode, om tjenester med client authorization tælles med, og om man måler unikke deskriptorer eller faktisk nåelige tjenester. Tor Projects egen metrics-side er det mest troværdige udgangspunkt, hvis du vil følge udviklingen, men selv der skal man læse metodebeskrivelsen før man citerer et tal.

Er onion services langsommere end almindelige websites?
Ja, typisk. Trafikken routes gennem flere lag af Tor-relæer for at bevare anonymiteten, hvilket lægger mere ventetid på end direkte routing. For lette, statiske sider er forskellen ofte til at leve med; for tunge, interaktive applikationer kan den være markant.

Kan jeg bruge et almindeligt SSL/TLS-certifikat på min onion-adresse?
Det er ikke nødvendigt for sikkerheden, fordi Tor allerede krypterer hele forbindelsen end-to-end. Nogle driftsherrer vælger alligevel at anskaffe et onion-specifikt certifikat for at signalere autenticitet i browseren, men det er et valg om tillid og brugeroplevelse, ikke et krav for grundlæggende kryptering.

Hvad sker der, hvis jeg taber den private nøgle i HiddenServiceDir?
Du kan ikke genskabe den samme onion-adresse uden den. Tor genererer en helt ny adresse, hvis mappen er tom eller slettet. Derfor er en krypteret backup af hele mappen afgørende, ikke valgfri, hvis adressen skal overleve en servermigrering eller et diskudfald.

Beskytter en onion service mig mod sårbarheder i min egen webapplikation?
Nej. Tor skjuler serverens netværksplacering og krypterer transporten, men patcher ikke din CMS, dit framework eller din egen kode. Du skal stadig holde software opdateret og følge almindelig applikationshærdning.

Er OnionShare et godt alternativ til den manuelle opsætning i denne guide?
Til kortvarig fildeling, engangs-chat eller en hurtig midlertidig side, ja. Til en vedvarende tjeneste, hvor du skal styre logging, hærdning og driftskontinuitet over tid, er den manuelle Tor- og Nginx-opsætning stadig det rigtige valg.

Er det lovligt at køre en Tor onion service i Danmark?
Ja, selve det at drive en onion service er ikke ulovligt i Danmark eller de øvrige nordiske lande. Du er dog stadig underlagt det samme ansvar for indholdet, du publicerer, og for persondata du behandler, som hvis tjenesten lå på et almindeligt domæne. Det er indholdet og brugen, der kan være ulovlig, ikke teknologien i sig selv.

Kan en onion service blive fundet alligevel?
Teknisk set gør v3-protokollen det meget svært at finde serverens placering gennem Tor-netværket alene. Risikoen ligger typisk andre steder: fejl i applikationen, metadata i uploadet indhold, lækkede nøglefiler, eller langvarig trafikanalyse mod en tjeneste der kører år efter år uden ekstra beskyttelse som Vanguards. Sikkerheden er summen af hele opsætningen, ikke kun af selve Tor-protokollen.

Tor Hidden Service: Vært Din Egen .onion I 11 Trin [2026]