A lecke végére meg tudod különböztetni a forward proxyt, a reverse proxyt és a CDN-t, meg tudod mondani, miért kerülnek közvetítők a kérés és a válasz útjába, és fel tudod ismerni egy valódi HTTP-válaszban a közvetítők nyomait.
Miért állnak közvetítők az úton?
Ha a böngésző és az alkalmazás között csak egy vezeték volna, a szolgáltatásnak minden feladatot egyedül kellene megoldania: a terheléselosztást, a titkosítást, a gyorsítótárazást, a támadások szűrését, a földrajzilag közeli kiszolgálást. A közvetítők ezeket a feladatokat veszik át, vagy adják hozzá a rendszerhez. Hátrányuk, hogy egy domain mögött nem egy gép áll, ezért a hibakeresésnél és a felelősségnél tudni kell, hány szereplő van az úton.
Ugyanaz a kurzusoldal, több közbülső szereplő
A hallgató felületén egyetlen domain látszik, de a forgalmat kliensoldali (például intézményi) proxy, szolgáltatói belépési pont, tartalomkézbesítő hálózat és reverse proxy is érintheti. Nem mindegyik van jelen minden rendszerben.
flowchart LR
B[Böngésző] --> P[Lehetséges kliensoldali proxy]
P --> C[CDN vagy szolgáltatói belépési pont]
C --> R[Reverse proxy]
R --> A[Alkalmazás]
Az ábra lehetséges felépítés, nem kötelező sor. Sok esetben a böngésző közvetlenül a szolgáltatói belépési ponthoz kapcsolódik. A CDN és a reverse proxy szerepe össze is érhet: egy CDN-szolgáltatás maga is fogadhat és továbbíthat kéréseket.
Forward proxy: a kliens oldalán
A forward proxy (hétköznapi szóhasználattal: proxy) a kliens nevében kommunikál a távoli szolgáltatással. Az MDN szerint a kliensek nevében jár el, elrejtheti azok azonosságát, és a sávszélesség csökkentésére vagy szabályozására tárolhat és továbbíthat forgalmat. Egy szervezeti hálózat használhatja hozzáférés szabályozására, naplózásra vagy gyorsítótárazásra. A böngésző a proxyhoz fordul, a proxy továbbítja a kérést.
HTTPS esetén a proxy nem olvassa automatikusan a TLS-sel védett tartalmat. A böngésző a CONNECT metódussal kér a proxytól egy „alagutat” a célhoz (általában a 443-as porton), a proxy pedig a titkosított bájtokat továbbítja. A pontos láthatóság a kapcsolat felépítésétől és a szervezeti beállítástól függ: bizonyos szervezeti környezetekben a proxy a saját tanúsítványával bonthatja a kapcsolatot, de ehhez a gépeknek előre meg kell bízniuk abban. A proxy puszta jelenléte tehát nem jelenti, hogy a védett üzenet minden közvetítő számára nyitott.
Reverse proxy: a szolgáltató oldalán
A reverse proxy a szolgáltató külső belépési pontja. Az MDN szerint a szerverek nevében jár el: tipikus feladatai a terheléselosztás, a statikus tartalom gyorsítótárazása és a tömörítés. Fogadja a böngésző kérését, majd belső szerverhez irányítja, kezelheti a TLS-kapcsolatot, és közben a böngésző számára ugyanaz a nyilvános domain marad.
Például a /kurzusok útvonal mehet a kurzusalkalmazáshoz, a /dokumentumok egy fájlszolgáltatáshoz. A reverse proxy nem javítja ki a mögötte futó alkalmazás hibáit: csak a saját feladatán belül tud segíteni.
A közvetítők a kérésbe nyomot hagynak, hogy az alkalmazás tudja, ki hívta eredetileg. A szabványos Forwarded fejléc, valamint a gyakran használt X-Forwarded-For (az eredeti kliens címe), X-Forwarded-Host és X-Forwarded-Proto (az eredeti protokoll) erre szolgál. A Via fejléc magukat a közvetítőket sorolja fel. Ez azért fontos, mert az alkalmazás számára a kapcsolat forrása a reverse proxy címe lenne, nem a felhasználóé; a valódi kliens azonosításához ezeket a fejléceket kell figyelembe venni. (A fejlécek megbízhatóságát az dönti el, hogy ki állíthatja be őket: a felhasználó is küldhet ilyet, ezért csak a saját közvetítőnk által hozzáadott érték megbízható.)
CDN: elosztott tartalomkézbesítés
A CDN az MDN meghatározása szerint olyan, sok földrajzi helyen elhelyezett szerverekből álló rendszer, amely ugyanazon adatok másolatait tárolja, hogy a kérést a felhasználóhoz legközelebbi szerver szolgálja ki. Gyakran képek, stíluslapok, programfájlok és más, sok felhasználónak azonos erőforrások kiszolgálására használják. Előnyei: kisebb késleltetés (a távolság arányosan számít), és kisebb terhelés az eredeti szerveren.
Egy valódi válasz fejlécei az example.com oldalról (2026. október 11.):
HTTP/2 200
server: cloudflare
age: 1950
cf-cache-status: HIT
A server: cloudflare azt mutatja, hogy a válasz nem közvetlenül az eredeti kiszolgálótól, hanem egy közvetítő szolgáltatótól jött.
Az age: 1950 az RFC 9111 szerinti Age fejléc: a küldő becslése arról, mennyi ideje készült a válasz, illetve mikor ellenőrizték utoljára az eredeti szervernél, másodpercben (itt kb. 32 perc).
A cf-cache-status: HIT szolgáltatóspecifikus fejléc, azt jelzi, hogy a válasz a gyorsítótárból származott.
A CDN előnye feltételes: függ a cache-találattól, az elhelyezkedéstől, az erőforrástól és a hálózati úttól. Az MDN három hátrányt is említ: függőség (ha a CDN kiesik vagy blokkolt egy régióban, az oldal elromolhat), biztonság (egy feltört CDN rosszindulatú tartalmat is kiszolgálhat; ellenszer például a Subresource Integrity) és teljesítmény (külső hoszt miatt több kapcsolat és névfeloldás kellhet).
Ki válaszolt ténylegesen?
Egy HTTP-válasz érkezhet az alkalmazástól, egy reverse proxy gyorsítótárából vagy egy CDN-csomóponttól. A böngésző a tartalmat és a státuszkódot látja; a belső út nem mindig állapítható meg a látható oldalból. Ezért a rendszer vizsgálatakor a közvetítő rétegeket is számításba kell venni. A következő leckéből látjuk, hogyan áll össze mindez egyetlen folyamattá.
Végigvezetett példa: a Kurzuspont belépési pontja
Elem
Feladat a Kurzuspontban
CDN
A logó, a stíluslap és a szkript kiszolgálása a hallgatóhoz közeli csomópontról.
Reverse proxy
A TLS lezárása, a kérések szétosztása az alkalmazáspéldányok között.
Alkalmazás
A jelentkezés szabályai.
Intézményi proxy
A hallgató hálózatában naplózás és szűrés.
Amikor a hallgató megnyitja a kurzuslistát, a stíluslap jó eséllyel CDN-ből jön (cache-találat), a lista maga viszont az alkalmazástól, mert személyre szabott. Ha valami nem működik, első kérdés: melyik szereplő adta a hibás választ?
Gyakori tévhitek
Állítás
Pontosítás
„A proxy és a reverse proxy ugyanazt a felet képviseli.”
Az előbbi a kliens, az utóbbi a szolgáltató oldalán áll.
„CDN esetén a válasz mindig gyorsítótárból jön.”
Cache-hiány vagy nem tárolható tartalom esetén az eredeti rendszerhez kell fordulni.
„Egy domain mögött egy szerver van.”
Közvetítők és több alkalmazáspéldány is állhat mögötte.
„A reverse proxy kijavítja az alkalmazás hibáját.”
Csak a saját feladatait látja el.
„A proxy mindig olvassa a HTTPS-forgalmat.”
A CONNECT alagútban a tartalom titkosítva halad át.
Röviden
A forward proxy a kliens, a reverse proxy a szerver nevében jár el.
A CDN földrajzilag elosztott, másolatokat tároló kiszolgálóhálózat.
A közvetítők nyomot hagynak a fejlécekben (Via, Forwarded, Age...).
A CDN előnye feltételes, és függőséget is jelent.
A válasz forrása nem mindig az alkalmazás.
Ellenőrző kérdések
Melyik oldalon áll a forward proxy, és melyiken a reverse proxy?
Mit mutat az Age fejléc?
Mi a hátránya annak, ha egy oldal egy külső CDN-től függ?
Miért nem látja az alkalmazás a felhasználó valódi IP-címét reverse proxy mögött, és mit tehet?
Proxyk, reverse proxyk és CDN-ek
Célok
A lecke végére meg tudod különböztetni a forward proxyt, a reverse proxyt és a CDN-t, meg tudod mondani, miért kerülnek közvetítők a kérés és a válasz útjába, és fel tudod ismerni egy valódi HTTP-válaszban a közvetítők nyomait.
Miért állnak közvetítők az úton?
Ha a böngésző és az alkalmazás között csak egy vezeték volna, a szolgáltatásnak minden feladatot egyedül kellene megoldania: a terheléselosztást, a titkosítást, a gyorsítótárazást, a támadások szűrését, a földrajzilag közeli kiszolgálást. A közvetítők ezeket a feladatokat veszik át, vagy adják hozzá a rendszerhez. Hátrányuk, hogy egy domain mögött nem egy gép áll, ezért a hibakeresésnél és a felelősségnél tudni kell, hány szereplő van az úton.
Ugyanaz a kurzusoldal, több közbülső szereplő
A hallgató felületén egyetlen domain látszik, de a forgalmat kliensoldali (például intézményi) proxy, szolgáltatói belépési pont, tartalomkézbesítő hálózat és reverse proxy is érintheti. Nem mindegyik van jelen minden rendszerben.
flowchart LR B[Böngésző] --> P[Lehetséges kliensoldali proxy] P --> C[CDN vagy szolgáltatói belépési pont] C --> R[Reverse proxy] R --> A[Alkalmazás]Az ábra lehetséges felépítés, nem kötelező sor. Sok esetben a böngésző közvetlenül a szolgáltatói belépési ponthoz kapcsolódik. A CDN és a reverse proxy szerepe össze is érhet: egy CDN-szolgáltatás maga is fogadhat és továbbíthat kéréseket.
Forward proxy: a kliens oldalán
A forward proxy (hétköznapi szóhasználattal: proxy) a kliens nevében kommunikál a távoli szolgáltatással. Az MDN szerint a kliensek nevében jár el, elrejtheti azok azonosságát, és a sávszélesség csökkentésére vagy szabályozására tárolhat és továbbíthat forgalmat. Egy szervezeti hálózat használhatja hozzáférés szabályozására, naplózásra vagy gyorsítótárazásra. A böngésző a proxyhoz fordul, a proxy továbbítja a kérést.
HTTPS esetén a proxy nem olvassa automatikusan a TLS-sel védett tartalmat. A böngésző a
CONNECTmetódussal kér a proxytól egy „alagutat” a célhoz (általában a 443-as porton), a proxy pedig a titkosított bájtokat továbbítja. A pontos láthatóság a kapcsolat felépítésétől és a szervezeti beállítástól függ: bizonyos szervezeti környezetekben a proxy a saját tanúsítványával bonthatja a kapcsolatot, de ehhez a gépeknek előre meg kell bízniuk abban. A proxy puszta jelenléte tehát nem jelenti, hogy a védett üzenet minden közvetítő számára nyitott.Reverse proxy: a szolgáltató oldalán
A reverse proxy a szolgáltató külső belépési pontja. Az MDN szerint a szerverek nevében jár el: tipikus feladatai a terheléselosztás, a statikus tartalom gyorsítótárazása és a tömörítés. Fogadja a böngésző kérését, majd belső szerverhez irányítja, kezelheti a TLS-kapcsolatot, és közben a böngésző számára ugyanaz a nyilvános domain marad.
Például a
/kurzusokútvonal mehet a kurzusalkalmazáshoz, a/dokumentumokegy fájlszolgáltatáshoz. A reverse proxy nem javítja ki a mögötte futó alkalmazás hibáit: csak a saját feladatán belül tud segíteni.A közvetítők a kérésbe nyomot hagynak, hogy az alkalmazás tudja, ki hívta eredetileg. A szabványos
Forwardedfejléc, valamint a gyakran használtX-Forwarded-For(az eredeti kliens címe),X-Forwarded-HostésX-Forwarded-Proto(az eredeti protokoll) erre szolgál. AViafejléc magukat a közvetítőket sorolja fel. Ez azért fontos, mert az alkalmazás számára a kapcsolat forrása a reverse proxy címe lenne, nem a felhasználóé; a valódi kliens azonosításához ezeket a fejléceket kell figyelembe venni. (A fejlécek megbízhatóságát az dönti el, hogy ki állíthatja be őket: a felhasználó is küldhet ilyet, ezért csak a saját közvetítőnk által hozzáadott érték megbízható.)CDN: elosztott tartalomkézbesítés
A CDN az MDN meghatározása szerint olyan, sok földrajzi helyen elhelyezett szerverekből álló rendszer, amely ugyanazon adatok másolatait tárolja, hogy a kérést a felhasználóhoz legközelebbi szerver szolgálja ki. Gyakran képek, stíluslapok, programfájlok és más, sok felhasználónak azonos erőforrások kiszolgálására használják. Előnyei: kisebb késleltetés (a távolság arányosan számít), és kisebb terhelés az eredeti szerveren.
Egy valódi válasz fejlécei az
example.comoldalról (2026. október 11.):server: cloudflareazt mutatja, hogy a válasz nem közvetlenül az eredeti kiszolgálótól, hanem egy közvetítő szolgáltatótól jött.age: 1950az RFC 9111 szerintiAgefejléc: a küldő becslése arról, mennyi ideje készült a válasz, illetve mikor ellenőrizték utoljára az eredeti szervernél, másodpercben (itt kb. 32 perc).cf-cache-status: HITszolgáltatóspecifikus fejléc, azt jelzi, hogy a válasz a gyorsítótárból származott.A CDN előnye feltételes: függ a cache-találattól, az elhelyezkedéstől, az erőforrástól és a hálózati úttól. Az MDN három hátrányt is említ: függőség (ha a CDN kiesik vagy blokkolt egy régióban, az oldal elromolhat), biztonság (egy feltört CDN rosszindulatú tartalmat is kiszolgálhat; ellenszer például a Subresource Integrity) és teljesítmény (külső hoszt miatt több kapcsolat és névfeloldás kellhet).
Ki válaszolt ténylegesen?
Egy HTTP-válasz érkezhet az alkalmazástól, egy reverse proxy gyorsítótárából vagy egy CDN-csomóponttól. A böngésző a tartalmat és a státuszkódot látja; a belső út nem mindig állapítható meg a látható oldalból. Ezért a rendszer vizsgálatakor a közvetítő rétegeket is számításba kell venni. A következő leckéből látjuk, hogyan áll össze mindez egyetlen folyamattá.
Végigvezetett példa: a Kurzuspont belépési pontja
Amikor a hallgató megnyitja a kurzuslistát, a stíluslap jó eséllyel CDN-ből jön (cache-találat), a lista maga viszont az alkalmazástól, mert személyre szabott. Ha valami nem működik, első kérdés: melyik szereplő adta a hibás választ?
Gyakori tévhitek
CONNECTalagútban a tartalom titkosítva halad át.Röviden
Via,Forwarded,Age...).Ellenőrző kérdések
Agefejléc?Tanulási források
CONNECT, aForwardedfejlécek, angolul.