De senaste veckorna fås ofta ett meddelande om att det inte går att ansluta till bloggens server, men även på andra sajter. Bloggen skulle behöva hjälp med felsökning och misstänker att det kan vara begränsat till vissa plattformar eller telekomoperatörer.
Felmeddelandet dyker upp med olika frekvens och jag har noterat det särskilt på vissa plattformar och telekom- eller Internetoperatörer.
Bloggen kör Cloudflare som avlastning, cache och brandvägg och om Cloudflare inte når den faktiska servern så kommer dett specifikt Cloudflaremeddelande upp på en websida, vilket det inte gör i dessa fall.
Således är det uppkopplingen mot Cloudflare som strular, vilket också förklarar att ett antal andra sajter som också använder Cloudflare som skydd och avlastning har fått detta felmmeddelande på sistone.
Ni som får motsvarande felmeddelande, kan ni i kommentarer ange vad för teknisk plattform ni använder:
- Webläsare, gärna version
- Klientplattoform (iPhone, Android, PC med Windows, Mac, Linux osv), gärna version
- Telekomoperatör eller Internetoperatör om känt
- Vad använder du för DNS – specifik DNS, i så fall vilken, t ex Googles Ulla-Bella* 8.8.8.8, eller operatörens inställning?
Själva bloggtrafiken verkar inte påverkats och bloggen har alltså inte färre visningar eller besök än vanligt, vilket ökar misstankarna att det är en mindre mängd bloggläsare som drabbas och att det är avgränsat till vissa förhållanden.
Själv laddar jag bara om så löser det hela sig, och tydligen gör andra av er också, men det är förstås irriterande och jag får en del mail och kommentarer i sociala medier om detta.
Det vore bra att kunna isolera ner vad för avgränsningar som gäller om några.
Om det nu är strul mot Cloudflare, som är byggt för att inte kunna överbelastas, så kan man bara spekulera på varför. Jag betalar förstås för Cloudflare, så det är ingen gratistjänst vi pratar om här. Men ska man felanmäla är det bra med lite på fötterna. Möjligt att någon angreppsvektor hittats mot Cloudflare, då andra sajter jag noterat problemet på är Ukrainarelaterade. Å andra sidan står Ukraina för 80% av mitt Internetbruk så det kan vara en snedtolkning.
Tillägg: Felet är nu isolerat tack vare läsaren Michael som skriver hur man upprepar felet med 100% säkerhet på en Appleprodukt, specifikt en iPhone. Byter man t ex wifinätverk eller annan uppkoppling verkar det samma gälla även på en Mac eller padda utan mobilstöd.
Enkelt sätt att för mig 100% kunna reproducera felet.
Börja på WiFi
Ladda en sida.
Stäng av WiFI så byt till mobildata
reload 1, ger felmeddelande
reload 2, laddar om sidan fint.
Sätt på WiFi
reload 3, ger felmeddelande
reload 4, laddar om sidan fint.Så byte mellan WiFi och mobildata (med IP, DNS och allt sånt) ger alltid för mig felet.
Samt efter en oklar period av inaktivitet både på WiFi (med 1.1.1.1 i mobilen) och mobildata men i båda fallen funkar snabba reloads med korta (<10sec) intervaller fint.”
Till detta kommer sajten man anropar ska använda Cloudflare. Det gäller således cornucopia.se eller kyivindependent.se men inte dn.se, där man fritt kan byta mellan wifi och mobiltelefoni utan att få dessa fel då de inte kör Cloudflare. Fastställt via kontroll om en sajt kör Cloudflare eller ej. Drabbar vad jag sett bara Cloudflaresajter.
Det kan till synes uppstå spontant på en iPhone i hemmet då Apple kan välja att gå via 5G istället för via wifi om wifitäckningen är dålig.
Felet har antagligen uppstått i Apples IP-stackar i någon programuppdatering under våren och beror rimligtvis på att beroende på var man kör via för operatör så byts IP-nummer för servern ut hos Cloudflare.
Behöver nog felanmälas till Apple och Cloudflare på något vis.
Tillägg 2: Problemet löst. En läsare som stött på problemet på annat håll hade efter flera dagars felsökning identifierat ner det hela till Cloudflare 0-RTT Connection Resumption. Bloggen har nu stängt av detta och felet uppstår inte längre, även om det tar lite längre att ladda in bloggen om man byter IP, t ex mellan wifi och 5G.
Tack alla för hjälpen.
*obskyr pop-kulturell referens
70 kommentarer
jag har sett felet då och då, och har tolkat det som ett DNS-problem. Har alltid funkat direkt vid omladdning. Är det Cloudflare som hanterar dina domäner också eller har du pekat dit från nån annan?
It’s not DNS.
It’s never DNS.
It was DNS.
Exakt. Jag har i alla fall använt Cloudflare mycket i tjänsten (även på deras gratis-nivå) och har aldrig varit med om att de inte svarar.
Kan ju vara så att vissa svenska Internetoperatörer slarvat lite med sin DNS-kapacitet. Kan förklara varför det fungerar olika på t ex desktop (med manuellt inställd DNS) och mobil.
Händer då och då och fungerar snabbt vid omladdning
Chrome Version 148.0.7778.179 (Officiell version) (x86_64)
iMac 3,8 GHz Quad-Core Intel Core i5
Bredband2
DNS?
Händer då och då på min MacBook Pro M1 (OS 26.3), där jag just nu använder en iPhone SE2 som modem. Däremot aldrig på telefonen (iOS 26.4.2) Kör Safari som webbläsare på bägge.
Har Comviq som operatör.
Även nån mer site som ger samma felmeddeleande på MBP’n men inte på telefonen.
Safari iOS (senaste)
iOS (senaste)
Telia (mobil & bredband)
DNS no?
Räcker med en refresh – har pågått i några veckor – nästa varje gång.
14:00, 14:05: Ukraina-artikeln?
Tack.
Chrome. Antar senaste version.
Apple iphone 15 pro max. Antar senaste version.
Vimla ( fast får det även när jag är på wifi)
Safari
macOS, iOS, senaste versionerna
Bahnhof, Telenor
Operatörs-dns
Har nog också sett det till o från i några veckor.
Har sett det mot andra tjänster med cloudflare med. Har inbillat mig att cloudflare gör något då vissa länder fått för sig att begränsa pga en del använder sig av iptv.
Men ja, mest en känsla och inte bekräftad.
Eller om det är 3/hallon som gör blocken
Brave 1.90.125, Chromium 148.0.7778.179
Operatör hallon/3
Jag har inte sett några problem, däremot blir jag utloggad oftare än tidigare.
Firefox
MacOS & Win11
Bredband2
DNS: Google tror jag
192.178.93.144, 192.178.93.147, 192.178.93.150, 192.178.93.154, 192.178.93.158, 192.178.94.21
Jag får det på min iphone, både när den är kopplad till wifi och när den inte är det. Använder Safari och har inte gjort några egna inställningar.
Det började inte direkt efter någon uppdatering i telefonen som man skulle kunna koppla det till.
Jag har inte haft några problem från datorn (pc/google chrome).
Varje gång..
Safari
iPad ver 8
Telia
DNS ?
Verkar dock som att det inte är några problem på min gamla iPhone
Jag får det felet lite då och då och inte då enbart på denna sida. Jag har trott att mitt problem beror på att jag har en linuxburk som kör Adguard som dns här, men kanske är det inte bara den enda sanningen? I övrigt snurrar hushållet på med mestadels Appleprylar och Bahnhof som isp. Använder Firefox på datorerna och Safari på bärbart.
Med en omladdning av sidan så fungerar det allt som oftast.
Det händer lite då och då på ipaden, osäkerpå om det hänt på iphonen som oftast är uppkopplad på hemnätverket precis som ipaden. Men bara att ladda om en gång så fungerar det. iPhone iOS 26.3.1 Med Tellit och IPad os26.5 med Telia mobilt bredband.
Jag har aldrig haft problemet på någon av mina enheter, varken över wifi eller över mobilnätet. Kan det vara webbläsaren?
Enhet 1:
MSEdge
iOS 26.5
Telia (mobilnät), Bahnhof (Wifi)
Standard-DNS för respektive
Enhet 2
MSEdge
Windows 11 Pro, 25H2 26200.8457
Bahnhof
Standard-DNS
Har aldrig hänt för mig.
Win 10 och 11 samt Linux Mint
Firefox senaste uppdat.
DNS 149.112.112.112
Operatör ownit (telenor)
Chrome (senaste versionen)
iPhone, iOS 26.5
Tele2
DNS: operatörens
Kan tillägga att jag har problem varje gång jag läser in bloggen sedan ett par veckor tillbaka.
Har aldrig sett detta. Chrome på mac, Bahnhof och deras DNS. Inte heller sett på Google Pixel 7 Pro med Chrome, varken på Wifi eller mobilnät.
Safari senaste
iPhone 12 mini
ios 26.4.2
Tele2
Dns ? vet ej
händer rätt ofta
laddar då om sidan o då funkar det
ibland även när jag loggar in
även då löser det sig med att ladda om
Händer titt som tätt sedan några veckor tillbaka. Aldrig sett det på MacBook eller iPad, men däremot relativt frekvent på iPhone 14 Pro senaste OS, Chrome webbläsare senaste version. 80% av mina besök är dock via telefonen så det är möjligt problemet finns på andra enheter också. Uppträder både via mobilnätet (Tre) och WiFi. En enda omladdning har alltid löst problemet.
DNS på eget nätverk: Körde Cloudflare 1.1.1.1 med 8.8.8.8 som sekundär fram tills för ett par veckor sedan. Då aktiverade jag AdGuard på ny router och hamnade på deras DNS, men det gjorde ingen skillnad för detta problem; det dyker upp ändå.
Har liksom vissa andra sett samma sak vid enstaka tillfällen på andra webbsajter under samma tidsperiod.
Händer titt som tätt sedan några veckor tillbaka. Aldrig sett det på MacBook eller iPad, men däremot relativt frekvent på iPhone 14 Pro senaste OS, Chrome webbläsare senaste version. 80% av mina besök är dock via telefonen så det är möjligt problemet finns på andra enheter också. Uppträder både via mobilnätet (Tre) och WiFi. En enda omladdning har alltid löst problemet.
DNS på eget nätverk: Körde Cloudflare 1.1.1.1 med 8.8.8.8 som sekundär fram tills för ett par veckor sedan. Då aktiverade jag AdGuard på ny router och hamnade på deras DNS, men det gjorde ingen skillnad för detta problem; det dyker upp ändå.
Har liksom vissa andra sett samma sak vid enstaka tillfällen på andra webbsajter under samma tidsperiod.
Händer nästan alltid vid omladdning av sidan, på magkänsla efter att ha varit inaktiv i nån minut eller mer. t.ex. ladda om sidan efter att ha läst ikapp ett gäng uppdateringar eller läst huvudartikeln. Eller när jag går tillbaka till en öppen tab och laddar om.
Får samma problem oavsett om jag kör på WiFi hemma eller via data.
iPhone iOS senaste (26.5)
Safari senaste (bundlad i 26.5)
Hemma WiFi:
Operatör: Tele2
DNS: 1.1.1.1
Mobildata:
Operatör: Tre
DNS: Operatörens
En faktiskt viktigt tillägg på Hemma WiFi. Kör mot egen DNS (Unifi Dream Machine SE, senaste uppdateringar) och den i sin tur använder 1.1.1.1
Så om det är DNS problem så är det Unifis DNS som beteer sig dåligt.
Testar att byta i mobilen till cloudflares 1.1.1.1 egna så den går direkt dit och rapporterar tillbaka om det gör någon skillnad.
Samma problem på iPhone iOS safari (26.5) på WiFi (Tele2 fiber operatör) med 1.1.1.1 som DNS konfigurerat direkt i mobilen utan att gå via Unifies DNS och efter total omstart av mobilen bara för att rensa det mesta.
Men felet verkar bara komma efter en liten tids inaktivitet. Om jag bara klickar reload hela tiden så kan jag ladda om sida hundra gånger utan ett enda fel.
Så Cloudflare-cachen dit Michaels DNS dirigerar honom har för kort stay-alive…?
(Vild gissning — aldrig varit nätverksproffs, eller ens spelat sådan på TV.)
Enkelt sätt att för mig 100% kunna reproducera felet.
Börja på WiFi
Ladda en sida.
Stäng av WiFI så byt till mobildata
reload 1, ger felmeddelande
reload 2, laddar om sidan fint.
Sätt på WiFi
reload 3, ger felmeddelande
reload 4, laddar om sidan fint.
Så byte mellan WiFi och mobildata (med IP, DNS och allt sånt) ger alltid för mig felet.
Samt efter en oklar period av inaktivitet både på WiFi (med 1.1.1.1 i mobilen) och mobildata men i båda fallen funkar snabba reloads med korta (<10sec) intervaller fint.
TACK!
Du har helt rätt. 100% reproducerbart.
Hjälpte inte att ställa in manuell DNS på wifit i mobilen, blev samma fel ändå.
SLUTSATS: Det har blivit något fel med Apples IP-stack i senaste uppdateringarna på MacOS, iPadOS och iPhoneOS
Har inte en enda applepryl, men det händer mig ändå.
Problem varje gång jag lämnar en kommentar via IPad. Safari eller chrome verkar inte spela någon roll. Problemet har varit några veckor.
Ska se…
Vad är då DNS-inställningarna på din padda och vilken Internetoperatör använder du?
Och nu funkade det så jag ser inte felmeddelandet :). Använde Chrome…
Och funkade i Safari också…
Njae, kan inte kontakta servern… men inlägget publiceras.
Använder ownit. Bara standardinställningar gällande DNS. Alltså operatörens DNS.
Jag har sett detta problem, och tolkat det som cloudflare fördröjning.
När jag, typ första gången på dagen, försöker få upp din hemsida, så dyker det upp en ruta på en blank websida som säger något i stil med att sidan inte kan nås. Strax därefter laddas sidan av sig själv om och den rätta sidan dyker upp. Dvs jag behöver inte själv ladda om sidan, men det verkar vara en fördröjning (förhandling?) som gör att den i första skedet inte dyker upp. Men jag får inte fram det just nu så jag kan inte säga exakt vad som står medan den “tänker”. Så här har det varit i några dagar, max en vecka.
OS: Mac Tahoe 26.5
Webläsare Vivaldi Version 8.0.4033.34
Internetleverantör: Bahnhof
DNS:
nameserver[0] : 8.8.8.8
nameserver[1] : 8.8.4.4
En liten not:
Ni som säger “kör operatörens DNS”. Skriv vilken DNS ni använder, annars blir det inte så givande information.
På windows, starta kommandofönster skriv ipconfig /all och se DNS.
På mac, starta terminalfönster skriv ipconfig
Och ni som kör Linux eller nått annat, vet redan hur man gör.
På macen kan man skriva “scutil –dns” i kommandofönstret för att få fram dns-infon.
Funkar alltid för mig, men jag använder inga apple prylar.
Win11
Firefox 151.0.2 (browser addons aktiva som tar bort reklam och tredjeparts cookies och lite annat)
DNS via Bahnhof (79.136.98.246 och 98.128.143.110)
Samsung Mobil via Tre – DNS 80.251.201.58
Får problem med åtkomst när jag är bakom Zscalers VPN/brandvägg/IP anonymisering. Vet inte exakt vad den gör … kanske inte helt ovanligt med sådana lösningar på större arbetsplatser.
Bara cornucopia som jag får detta felmeddelanden på, inga andra siter.
När jag kikade genom kommentarerna ser det primärt ut som det är apple enheter. Mina pengar är på att det enheter av lite nyare snitt som kör “Private Relay”, kanske i kombination med att man surfar privat och /eller att man inte är inloggad i typ chrome.
Lätt verifierbart om någon ovan med problem testar att stänga av “Private Relay” under Settings/Apple Account/iCloud.
Jag kör inte private relay, får problemet ändå.
Jag frågade Claude, som pekar på HTTP3/QUIC (enligt en artikel ett känt strul mellan iOS QUIC-implementation och Cloudflares QUIC-stack). Testa att slå av HTTP3/QUIC under din domän -> Speed -> Settings -> Protocol Optimization i Cloudflare.
Tack. Jag har felanmält till CF nu, tänker inte vidta din föreslagna åtgärd än innan jag får svar från dem.
Jag brukar använda både open DNS 208.67.222.222
208.67.220.220 och google
chrome 148.0.777 8.97 på MAC air M3 os Tahoe macOS 26.4.1 (25E253) Måste sända om för att skicka kommentarer , Mar svårt att uppdatera . Ibland kommer jag heller inte in i dagens längre text (fortsätt läsa här) utan får bara en lång kontinuerlig lista av de senaste dagarnas Blogg utan kommentarsfält. Enklast är då att gå över Senaste.
Om jag blockas nu när jag trycker så får jag lägga till felmeddelandet i ny kommentar
får refresha ett par gånger för att skicka post.
Webbplatsen kan inte nås
cornucopia.se stängde oväntat ner anslutningen.
Testa att
kontrollera anslutningen
kontrollera proxyn och brandväggen
ERR_CONNECTION_CLOSED
Banhof fiber .
1. Vivaldi 7.9.3970.47-1
2. OpenSUSE Linux 15.6
3. Bredband2
4. DNS över HTTPS till routern inställt, men routern har ju inte det.
I configen på routern hittar jag cloudflare DNS over TLS:
‘1.1.1.1’
‘1.0.0.1’
‘2606:4700:4700::1111’
‘2606:4700:4700::1001’
samt vanlig dns (de två första är bredband2)
‘79.138.0.180’
‘85.8.31.209’
‘8.8.8.8’
Generellt problem-område: en pryl kan ha flera uppkopplingar som wifi och mobil samtidigt. Dessutom är det sannolikt att mobiluppkopplingen nuförtiden har ipv6-adresser. Cloudflares ipv6-adresser är inte nåbara utan ipv6 så det kanske krävs en fel-laddning på telefonen för att den ska tömma sin lokala DNS-cache om den förlorar sin ipv6-uppkoppling.
Du verkar ha http3 påslaget på cloudflare. Kolla under Speed / Settings för din domän om du även har enablat 0-RTT Connection Resumption. Testa och stäng av den isåfall. Cloudflare har den inte påslagen som default, eftersom det finns lite risker med inställningen. Jag tror att den i kombination med nätverksbyte ger problem med http3/quic handshake i safari.
Tack, missade din kommentar i filtret, och fick motsvarande via mail. Lösningen fungerar.
Jag drabbas sporadiskt, och har inte sett något tydligt mönster än. Ska försöka skriva ner när det händer under den här kommentaren.
iPad 26.5, Chrome, wifi hemma med lokal DNS (bind). Använder Googles DNS för uppslagning av externa domäner. Internetport Sweden som ISP, fast publik IPv4-adress. GlobalConnect äger fibern.
Felmeddelande ERR_CONNECTION_FAILED
20:38, samma iPad, samma fel.
Jag skulle precis skapa ett konto för att skriva om samma fel och råkade ut för felet två gånger under registreringsprocessen.
Trodde först att det berodde på mitt nätverk pga nyligen installerad PiHole som verkar bråka med Apples relätjänster, men jag är tydligen inte ensam.
Efter att ha stängt av Mullvad och slagit på Apple Private Relay istället så har jag inte fått felet fler gånger.
Läst bloggen daglien i flera år. Aldrig stött på det fel, men kör ju inte Rotten Apple heller 😉
Telia
Windows med edge.
Android med chrome
Det låter som att man får problemet när man byter IP-adress och kanske även om man byter port.
Och fler och fler operatörer använder CGNAT, och då kan man få ny IP och port lite då och då.
Är det någon som kör IPv6 som har problem, för då har man inte CGNAT, och då är det troligen något annat problem (också).
Har du, eller din router en “publik” IPv4 adress som börjar på 100.x.x.x så har du CGNAT.
intervallet 100.64.0.0 – 100.127.255.255 skall det vara för CGNAT
## Analys av felet
Det här är ett välkänt och relativt subtilt nätverksproblem. Baserat på beskrivningen — särskilt det reproducerbara mönstret med WiFi↔mobildata-byte och att det *bara* drabbar Cloudflare-sajter — pekar allt mot en enda bov:
—
### Trolig orsak: HTTP/2- eller HTTP/3-anslutningsåteranvändning vid nätverksbyte
Apples nätverksstack (URLSession/CFNetwork) är aggressiv med att **återanvända etablerade TCP- och QUIC-anslutningar** för att spara tid. Problemet uppstår så här:
1. Du är på WiFi och har en öppen HTTP/2- eller HTTP/3-session mot Cloudflares edge-server
2. Du byter till mobildata → ny IP-adress, ny nätverksväg
3. Apple försöker *återanvända den gamla anslutningen* som nu är ogiltig (fel käll-IP, gammal session-ID)
4. Cloudflare avvisar den — **felmeddellande**
5. Reload 2: Apple ger upp den gamla anslutningen och skapar en ny — **fungerar**
Det förklarar **exakt** varför:
– Alltid fel på reload 1, alltid OK på reload 2
– Bara Cloudflare-sajter drabbas (de är extremt optimerade för anslutningsåteranvändning med HTTP/2 coalescing och HTTP/3/QUIC)
– dn.se inte drabbas (de kör troligen inte HTTP/3 och hanterar connection resets annorlunda)
– Det kan hända “spontant” när iOS WiFi Assist tyst byter till 5G
—
### Specifikt misstänkt: QUIC/HTTP/3
HTTP/3 körs över **UDP istället för TCP**, och QUIC har inbyggt stöd för *connection migration* (byta nätverk utan att tappa session) — men det kräver att *båda* sidor stödjer det korrekt. Om Cloudflares implementation och Apples stack inte handshake:ar migrationen rätt, blir det exakt det här symptomet.
**Att kontrollera:** Gå till Cloudflare-dashboarden → Speed → Optimization → Protocol Optimization. Testa att tillfälligt **stänga av HTTP/3 (QUIC)**. Om felet försvinner för iPhone-användare är det bekräftat.
—
### Vad man bör felanmäla och hur
**Till Apple** (Feedback Assistant, feedbackassistant.apple.com):
– Kategori: *Networking*
– Bifoga det reproducerbara steg-för-steg-scenariot (WiFi→mobildata→reload 1 fail→reload 2 OK)
– Ange iOS-version, operatör, och att det är konsistent på Cloudflare-sajter men inte andra
**Till Cloudflare** (support.cloudflare.com, kräver inloggning med betalplan):
– Skapa ett supportärende, inte community-inlägg
– Ange: domännamn, felkod (vilket Cloudflare-felmeddelande syns exakt?), reproduktionssteg, att det gäller Apple-enheter vid nätverksbyte
– Be dem kolla **QUIC connection migration handling** och eventuella edge-konfigurationer
—
### Snabb workaround att testa redan nu
I Cloudflare-dashboarden, prova i tur och ordning:
1. **Stäng av HTTP/3** (Speed → Optimization) — bevarar HTTP/2
2. Alternativt: kolla om **”Early Hints”** eller **”0-RTT Connection Resumption”** är på — stäng av dem och testa
Det är inget fel på bloggen, servern eller Cloudflare-kontot som sådant — det är ett edge case i hur Apples nätverksstack hanterar anslutningscachning vid nätverksbyte mot HTTP/3-optimerade CDN:er.
Har inte en enda applepryl, men det händer mig ändå. Har publik IPv4-address samt IPv6, alltså inget CGNAT. Men routern kör naturligtvis NAT.
Claude svarar:
Notera vad den här personen har: publik IPv4 + IPv6 samtidigt, alltså dual-stack.
Uppdaterad hypotes: Dual-stack + HTTP/2 connection coalescing
Det händer troligen så här:
Webbläsaren kopplar upp mot Cloudflare via antingen IPv4 eller IPv6
HTTP/2 (och HTTP/3) är aggressiva med att återanvända befintliga anslutningar — det sparar tid
Något förändras i nätverksvägen: ISP:n tilldelar ett nytt IPv6-prefix efter inaktivitet, routern gör en NAT-session-timeout, eller IPv6-rutten fluktuerar
Webbläsaren försöker återanvända den gamla anslutningen som nu är ogiltig hos Cloudflare
Fel på reload 1 — ny anslutning upprättas — OK på reload 2
Det är exakt samma mekanism som Apple-fallet, men triggern skiljer sig:
Apple: fysiskt nätverksbyte WiFi↔mobil
Dual-stack: IPv4/IPv6-rutten ändras tyst i bakgrunden
Vad det pekar mot
Felet är alltså inte Apple-specifikt utan anslutningscachning mot Cloudflare som inte hanterar stale connections tillräckligt robust. Apple-enheter drabbas oftare för att de byter nätverk mer aggressivt, men alla med instabila anslutningsförhållanden kan drabbas.
Stärker rekommendationen att testa stänga av HTTP/3/QUIC på Cloudflare som första debuggingsteg — det är den protokollkomponent som är mest känslig för exakt det här beteendet.
Offtopic men säljs fortfarande Lenas dold/ficktjuvssäkra system för att bära pass etc inpå kroppen? Har försökt goolga och söka utan att hitta något.
Ja, https://unipors.se
Felet är hittat och bloggaren har hittat ett sätt att komma runt det, för flera dagar sen, men jag vill tillägga att bilden högst upp på den här sidan visar varför jag avskyr moderna IT-system. Ett felmeddelande av typen “det gick inte”.
Programmen som körs har högst troligen betydligt mer att berätta om vad som gick fel och varför, men det gör de aldrig.