Dacă authentik instalat pe VPS-ul tău te trimite înapoi la login, te învârte între autentificare și aplicația protejată sau îți blochează complet accesul după ce ai pus un reverse proxy în față, cauza nu este de obicei „authentik e instabil”. De regulă, problema este mult mai banală: headere trimise greșit de proxy, un URL extern configurat prost, un outpost care nu mai este accesibil public pe calea corectă sau o nepotrivire de versiune între instanța principală și outpost. Modelul sigur pentru producție este simplu: TLS terminat curat, headere corecte, cale publică pentru outpost, URL extern coerent și cât mai puține artificii inutile în topologie.

Răspunsul direct

Pe un singur VPS, cea mai stabilă arhitectură pentru authentik este de obicei aceasta:

  • NGINX pe porturile 80 și 443
  • authentik în spatele lui, pe localhost sau pe o rețea Docker privată
  • outpostul integrat, dacă nu ai un motiv serios să îl separi
  • un domeniu public clar pentru authentik, de exemplu auth.example.com
  • aplicații publicate pe subdomenii curate, nu înghesuite în subdirectoare
  • calea /outpost.goauthentik.io expusă public exact acolo unde trebuie

Dacă pornești de aici, majoritatea incidentelor dispar. Dacă încerci să fii prea ingenios cu subpath-uri, porturi neobișnuite, reguli de proxy reciclate și outposturi lăsate în urmă, începi să-ți construiești singur următorul lockout.

Înainte să depanezi, separă cele trei componente

Foarte mulți administratori se încurcă pentru că tratează tot ansamblul ca pe o singură aplicație. Nu este.

  • authentik server este nucleul platformei: interfața de administrare, politicile, flow-urile și API-ul.
  • outpostul este componenta care intermediază protecția aplicațiilor prin proxy sau forward auth.
  • reverse proxy-ul este stratul care decide ce vede authentik în realitate: host, schemă, IP client, upgrade WebSocket și căi de acces.

Dacă unul dintre aceste straturi transmite informații greșite, celelalte două se comportă perfect logic, doar că pe baza unor date false. Așa apar buclele de redirecționare. Nu pentru că platforma ar fi arbitrară, ci pentru că topologia îi spune altceva decât crezi tu că îi spune.

Pe un VPS simplu, outpostul integrat este de cele mai multe ori alegerea cea mai sănătoasă. Rulează în același container principal și pe aceleași porturi ca authentik, ceea ce elimină o clasă întreagă de probleme de rețea și de aliniere a versiunilor. Un outpost separat are sens doar atunci când chiar ai nevoie de el.

Dacă vrei infrastructura potrivită pentru un serviciu de identitate și acces pe care îl controlezi cap-coadă, un VPS KVM este baza corectă. Aici ai nevoie de control real asupra TLS-ului, rețelei și proxy-ului, nu de limitări mascate frumos.

Greșeala 1: reverse proxy-ul îi spune lui authentik că rulează în altă lume

Asta este cea mai comună cauză pentru buclele de autentificare. Authentik trebuie să știe cu precizie patru lucruri: schema originală, IP-ul clientului, hostul cerut și dacă există upgrade la WebSocket. Dacă reverse proxy-ul nu transmite corect aceste informații, authentik începe să construiască URL-uri greșite, să valideze greșit callback-urile și să trateze comunicarea cu outpostul ca pe ceva suspect.

Un bloc NGINX minimal și sănătos pentru domeniul authentik arată așa:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl http2;
    server_name auth.example.com;

    ssl_certificate     /etc/letsencrypt/live/auth.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/auth.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

Aici nu există linii „opționale de bun-simț”. Fiecare contează. Dacă X-Forwarded-Proto este greșit, loginul și redirecționările pot porni pe schema greșită. Dacă Host este greșit, verificările de securitate și comunicarea cu outpostul se pot rupe. Dacă lipsesc headerele de upgrade, WebSocketurile nu mai funcționează cum trebuie. Dacă proxy-ul tău încă se comportă ca și cum ar vorbi HTTP/1.0, ai deja o problemă structurală.

Un detaliu omis frecvent este acesta: dacă reverse proxy-ul nu ajunge la authentik dintr-o gamă privată de adrese, trebuie să configurezi explicit AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS. Altfel, headerele de proxy nu sunt acceptate așa cum te aștepți.

environment:
  AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS: "127.0.0.1/32,10.0.0.0/8,192.168.0.0/16,203.0.113.10/32"

Folosește IP-urile sau rețelele tale reale. Nu copia exemple în producție doar pentru că par convenabile.

Greșeala 2: URL-ul extern este greșit sau incomplet

Outpostul integrat nu are o intuiție magică despre adresa publică pe care vrei să o folosească utilizatorii. La o instalare nouă, authentik tinde să preia URL-ul sub care a fost accesat inițial. Dacă acel prim acces a fost făcut prin IP, printr-un hostname temporar sau printr-un URL de test, ai toate șansele să însămânțezi redirecturi greșite încă din prima zi.

De aceea, valoarea asta contează enorm:

authentik_host: https://auth.example.com/

Trebuie să fie un URL complet. Nu doar un hostname. Nu doar un FQDN. Un URL complet, cu schemă și slash final.

Aici apar și multe probleme auto-provocate prin subpath-uri. Authentik poate fi servit și sub o cale de tip /authentik/, dar asta trebuie configurat explicit prin AUTHENTIK_WEB__PATH, cu slash la început și la final. Dacă nu ai un motiv puternic să folosești subpath-uri, nu o face. Un domeniu dedicat pentru authentik este mai curat, mai ușor de depanat și mai puțin predispus la surprize.

Pe românește: auth.example.com bate aproape întotdeauna un setup improvizat de tip example.com/auth.

Greșeala 3: ai blocat exact calea care trebuie să rămână publică

Aceasta este una dintre cele mai frecvente și mai frustrante greșeli. Tot ce este sub /outpost.goauthentik.io trebuie să rămână public accesibil, pentru că acolo se află o parte esențială din mecanismul de autentificare. Dacă protejezi acea cale cu aceeași barieră de autentificare care depinde de ea, ai creat o buclă perfectă.

Cel mai simplu test de sănătate este și cel mai util:

curl -vk https://app.example.com/outpost.goauthentik.io/ping

Un setup corect răspunde cu HTTP 204. Dacă nu primești asta, nu începe să cauți probleme în flow-uri, politici sau expresii. Mai întâi repară traseul de request.

Pentru o aplicație protejată cu NGINX și outpost integrat, forma de bază arată așa:

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_http_version 1.1;

    auth_request /outpost.goauthentik.io/auth/nginx;
    error_page 401 = @goauthentik_proxy_signin;

    auth_request_set $auth_cookie $upstream_http_set_cookie;
    add_header Set-Cookie $auth_cookie;

    auth_request_set $authentik_username $upstream_http_x_authentik_username;
    proxy_set_header X-authentik-username $authentik_username;
}

location /outpost.goauthentik.io {
    proxy_pass http://127.0.0.1:9000/outpost.goauthentik.io;
    proxy_set_header Host $host;
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
}

location @goauthentik_proxy_signin {
    internal;
    return 302 /outpost.goauthentik.io/start?rd=$scheme://$http_host$request_uri;
}

Regula este clară: aplicația poate fi protejată, dar calea outpostului nu trebuie blocată de aceeași regulă.

Dacă după activarea authentik începi să vezi în NGINX erori legate de headere prea mari, nu da vina pe platformă. Mărește bufferele de proxy. Asta este o problemă de proxy, nu o dovadă că autentificarea „se rupe aleator”.

Greșeala 4: lași outpostul în urmă și apoi te miri că nu mai vorbește corect

Outposturile nu sunt accesorii. Sunt componente critice din calea de autentificare.

Outposturile gestionate direct de authentik, prin integrarea Docker sau Kubernetes, sunt actualizate automat de platformă. Outposturile instalate manual nu sunt. Dacă rulezi un outpost separat într-un proiect Compose distinct și uiți să îl actualizezi odată cu instanța principală, ai introdus o nealiniere exact în componenta de care depind utilizatorii pentru acces.

Dacă alegi un outpost separat, fixează explicit tagul imaginii și tratează-l ca pe o parte din planul de upgrade:

services:
  authentik-outpost:
    image: ghcr.io/goauthentik/proxy:2026.2
    container_name: authentik-outpost
    restart: unless-stopped

După fiecare actualizare, verifică în interfața de administrare secțiunea Applications > Outposts. Dacă vezi avertismente în coloana Health and Version, nu le ignora. În autentificare, diferențele mici de versiune nu sunt cosmetice.

Există și o capcană mai discretă. Începând cu versiunile mai noi, fișierele nu mai sunt servite prin aceleași căi vechi. Dacă ai cărat înainte o regulă de proxy veche și ai lăsat-o neatinsă, poți rupe elemente vizuale sau resurse auxiliare într-un mod care pare fără legătură cu autentificarea, dar care vine din aceeași sursă: reguli istorice reciclate fără verificare.

Greșeala 5: ai ales o topologie care te obligă să depanezi mai mult decât trebuie

Nu orice problemă authentik este o problemă de headere. Unele sunt pur și simplu greșeli de arhitectură.

Dacă folosești forward auth, decide de la început dacă protejezi o singură aplicație sau un grup întreg de aplicații de sub același domeniu. Pentru o aplicație izolată, modul pentru o singură aplicație este aproape întotdeauna mai ușor de înțeles și de depanat. Pentru mai multe servicii sub aceeași umbrelă, modul la nivel de domeniu poate avea sens. Dar dacă amesteci subdomenii, subdirectoare, moduri diferite de forward auth și outposturi puse la întâmplare, nu mai ai o soluție. Ai un joc de logică pe care trebuie să-l rezolvi de fiecare dată când cade ceva.

Regula practică este simplă:

  • o aplicație, un subdomeniu, o regulă clară: păstrează-l simplu;
  • mai multe aplicații sub aceeași politică: folosește un model coerent, nu improvizații amestecate;
  • aplicații servite din subdirectoare: acceptă că vei avea mai multe colțuri ascuțite și mai mult timp pierdut.

Un serviciu de identitate și acces trebuie să fie previzibil. Nu sofisticat de dragul sofisticării.

Arhitectura pe care chiar am avea încredere să o lăsăm în producție

Pentru un deployment authentik single-node pe un VPS Linux, configurația cea mai sănătoasă este de obicei aceasta:

  • Debian 12 sau Ubuntu 24.04
  • NGINX pe host pentru terminarea TLS
  • authentik server și worker în Docker Compose
  • PostgreSQL pe același VPS, accesibil doar intern
  • outpost integrat, dacă nu ai un motiv real să îl separi
  • subdomeniu dedicat pentru authentik și subdomenii separate pentru aplicațiile protejate

Nu este cea mai „interesantă” soluție. Tocmai de aceea este bună. Sistemele de identitate trebuie să fie plictisitor de previzibile.

Dacă ridici un ecosistem self-hosted mai mare în jurul lui, merită să citești și gestionarea Docker și a containerelor pe un VPS. Dacă încă proiectezi infrastructura de bază, ghidul de self-hosting pentru website în 2026 este companionul potrivit. Iar dacă ai tendința să lași componentele critice să plutească fără control de versiune, ghidul despre Git self-hosted rămâne relevant măcar ca disciplină de operare.

Checklist de recuperare când deja te-ai blocat afară

  • Verifică dacă domeniul authentik răspunde cu certificatul corect și fără redirecționări bizare.
  • Verifică dacă https://app.example.com/outpost.goauthentik.io/ping răspunde cu 204.
  • Confirmă dacă proxy-ul trimite către outpostul integrat sau către unul separat.
  • Compară versiunea outpostului cu versiunea instanței principale.
  • Verifică valoarea authentik_host și orice URL extern folosit de utilizatori.
  • Verifică headerele Host, X-Forwarded-Proto, X-Forwarded-For și upgrade-ul WebSocket.
  • Verifică faptul că pathul outpostului nu este prins din greșeală într-o regulă de autentificare sau redirect global.

Primele comenzi utile sunt directe:

curl -vk https://auth.example.com/
curl -vk https://app.example.com/outpost.goauthentik.io/ping
docker compose ps
docker compose logs --tail 200 authentik-server authentik-worker
docker logs --tail 200 authentik-outpost

Dacă depanezi un outpost integrat, ridică logarea la trace suficient cât să vezi ce primește. Dacă depanezi un outpost separat, uită-te direct în logurile acelui container. În multe cazuri, acolo vezi imediat schema greșită, hostul greșit sau URL-ul original greșit.

Răspunsul practic

Cele mai multe situații în care authentik te lasă fără acces pe un VPS vin dintr-un set mic de greșeli repetitive: headere greșite, URL extern greșit, cale de outpost blocată sau nealiniere de versiune între outpost și instanța principală. Remedierea nu înseamnă să te afunzi și mai mult în flow-uri și expresii. Înseamnă să simplifici topologia, să cureți proxy-ul, să păstrezi calea outpostului publică și să tratezi outposturile ca pe piese critice, nu ca pe niște anexe.

Dacă vrei un mediu în care să controlezi singur proxy-ul, certificatele, rețeaua și serviciile din jurul authentik, începe cu un VPS KVM de la ServerSpan. Authentik nu este dificil pentru că identitatea ar fi magică. Este dificil pentru că o singură presupunere greșită la nivel de proxy te poate scoate din propriul sistem.

Versiunea în engleză: Authentik on a VPS: the redirect loops, outposts, and reverse-proxy mistakes that lock you out
Sursă și Atribuire

Aceast articol se bazează pe date originale ale serverspan.com. Pentru metodologia completă și pentru a asigura integritatea datelor, articolul original trebuie citat. Sursa canonică este disponibilă la: Authentik pe un VPS: buclele de redirecționare, outposturile și greșelile de reverse proxy care te pot lăsa fără acces.