Cloudflare Tunnel i 2026: Bedre overblik, sværere spørgsmål

Cloudflare Tunnel løser stadig et reelt problem: Du kan publicere interne eller kundevendte tjenester uden at eksponere origin-serveren direkte på det offentlige internet. En letvægtsproces, cloudflared, opretter forbindelser til Cloudflare, som udelukkende er udgående, og derfor er modellen attraktiv ud fra et sikkerhedsperspektiv. Den driftsmæssige ulempe er, at Tunnel også gør det meget nemt at ophobe enkeltstående løsninger: en connector til staging, et hostname, der blev tilføjet under en lancering, eller en produktionsafhængighed, som »bare virker«, men som ingen ejer. I juni 2026 havde Cloudflare forbedret overblikket over Tunnel så meget, at disse huller ikke længere er svære at få øje på. Det er godt nyt for driftsteams – og mindre behageligt for dem, der sidder med en udokumenteret jungle af tunnels.

For virksomhedsejere og bureauledere handler det ikke om teknisk pertentlighed. Det handler om risikostyring. Hvis en kundevendt tjeneste afhænger af en tunnel, bør du hurtigt kunne besvare fire grundlæggende spørgsmål: Hvad router den, hvem ejer den, hvordan håndterer den failover, og hvordan fejlfindes den, når den ikke opfører sig som forventet? Opdateringerne fra 2026 gør det lettere at indsamle svarene. De gør det samtidig sværere at bortforklare utilstrækkelige svar.

Hvad blev forbedret i 2026?

Tre ændringer er væsentlige. Den 20. februar 2026 flyttede Cloudflare Tunnel ind i det primære dashboard under Networking > Tunnels med lifecycle management, tunnelstatus, overblik over replikaer og et routingkort, der viser offentlige applikationer, private hostnames, private CIDR-blokke og Workers VPC-tjenester samlet ét sted. Den 19. marts 2026 tilføjede Cloudflare kommandoerne wrangler tunnel, så teams kan oprette, inspicere, opliste, køre og slette tunnels fra terminalen. Den 20. marts 2026 opdaterede Cloudflare visningen i Cloudflare One, så en tunnels oversigtsside viser alle aktive replikaer og understøtter samtidig logstreaming fra flere replikaer.

Denne kombination er vigtig, fordi tunneladministration ikke længere er gemt væk i opsætningsforløb eller spredt ud over kopierede UUID’er. I praksis er dashboardet nu bedre til at gennemgå den samlede installation, mens CLI’en er bedre til gentagelige driftsopgaver og overdragelse. Hvis jeres primære use case er at beskytte origin-servere og offentlige applikationer, er det primære dashboard det naturlige udgangspunkt. Hvis jeres team hovedsageligt arbejder med adgangsflows i Zero Trust, er Cloudflare One-dashboardet stadig relevant. Uanset hvad er overblikket markant bedre, end det var ved årets begyndelse.

Hvad det bedre overblik afslører

De fleste problemer med tunnels er ordinære snarere end dramatiske. Et hostname i produktion resolver stadig, men ingen ved, hvilket team der ejer tunnelen. En tjeneste, som burde kunne overleve et hostnedbrud, afhænger i praksis af én velfungerende connector. DNS peger på noget fornuftigt, men origin-mappingen blev sat op i hast og aldrig gennemgået. Bureauer oplever ofte en variant af dette under en kundeoverdragelse: Implementeringen virker, men driftsmodellen findes kun i én persons hukommelse.

Derfor er observability vigtigt her. Bedre overblik hjælper ikke kun under incidents; det ændrer også governance. Når routes, status og replikaer kan gennemgås centralt, holder »vi er ikke helt sikre på, hvad der er i brug« op med at lyde som en platformsbegrænsning og begynder at lyde som en ledelsesbeslutning.

Behold de nyttige kommandoer, men brug dem bevidst

Cloudflares aktuelle dokumentation understøtter stadig et praktisk sæt kommandoer. Til kortlægning og hurtig inspektion er npx wrangler tunnel list og npx wrangler tunnel info <TUNNEL> nu reelt nyttige. De gør det lettere at auditere en konto, sammenholde det eksisterende med det forventede og udarbejde dokumentation, som andre faktisk kan følge. Det vigtige forbehold er, at Cloudflare stadig markerer alle wrangler tunnel-kommandoer som eksperimentelle. Hvis I bygger automatisering omkring dem, bør I derfor fastlåse versionerne og dokumentere den forventede adfærd.

Ved fejlfinding er remote logstreaming langt bedre end »log ind på serveren via SSH, og håb på det bedste«. Cloudflares aktuelle logdokumentation bekræfter, at logs kan streames fra dashboardet eller fra en lokal maskine, hvor cloudflared er installeret. De centrale CLI-mønstre, som stadig er værd at gemme, er cloudflared tail <UUID> og cloudflared tail --connector-id <CONNECTOR ID> <UUID>, når du har brug for én bestemt replika. Hvis du ønsker struktureret output, er cloudflared tail --output=json <UUID> | jq . stadig et fornuftigt valg. Du kan også reducere støjen med filtre som --event, --level og --sampling.

Begrænsningerne er lige så vigtige som kommandoerne. Logstreams i dashboardet fungerer kun for fjernadministrerede tunnels, kræver redigeringsrettigheder og er kun nyttige, når tunnelen er aktiv og modtager requests. Remote logging-sessioner er begrænset til én time, og for tunnels med høj throughput prioriterer Cloudflare udtrykkeligt stabil drift frem for perfekt levering af logs. Hvis I har brug for fuld dækning til audit eller analyse efter en incident, bør I også gemme vedvarende logs på serversiden, eksempelvis med cloudflared tunnel --loglevel info --logfile cloudflared.log run <UUID> eller en tilsvarende servicekonfiguration.

En rationel gennemgang af Cloudflare Tunnel

Hvis I allerede er afhængige af Tunnel, er det klogeste næste skridt som regel rationalisering – ikke udvidelse. En nyttig gennemgang bør omfatte:

Kortlægning: Knyt hver tunnel til dens routes, tilhørende DNS, miljø, origin-tjeneste og navngivne ejer.
Robusthed: Undersøg, hvor en forretningskritisk tjeneste reelt hænger på én connector, og afgør, om flere replikaer er nødvendige.
Logging: Definér, hvad der skal gemmes lokalt, hvad der kan streames remote, og hvem der må se følsomme logs.
Lifecycle: Afgør, hvilke opgaver der hører hjemme i dashboardet, hvilke der hører til i dokumenterede CLI-procedurer, og hvilke der bør være API-drevne.
Overdragelse: Sørg for, at en intern driftsansvarlig eller et nyt bureau kan forstå opsætningen uden at skulle reverse-engineere den under tidspres.

Her ligger den kommercielle værdi af forbedringerne fra 2026. Cloudflare har gjort Tunnel lettere at overskue, administrere og fejlfinde. Det fjerner ikke behovet for standarder. Det betyder blot, at standarderne nu kan håndhæves med mindre friktion.

Hvis I ønsker en mere enkel driftsmodel

Hvis jeres team har flere tunnels, uklart ejerskab eller for meget incident response baseret på hukommelsen, er det sandsynligvis tid til en gennemgang. Greg kan hjælpe med at forvandle en fungerende, men skrøbelig tunnelinstallation til noget, der er dokumenteret, supportérbart og lettere at overdrage. Start dialogen her.

Har I brug for hjælp til denne type opgave?

Drøft en rationaliseringsgennemgang af Cloudflare Tunnel – kontakt Greg.

Kilder

Sidst ændret

2026-09-01