GYIK

xHOSTING – Gyakran Ismételt Kérdések

Ki csatlakozhat az xHOSTING közösséghez?

Röviden: érvényes meghívóval azonnal lehet rendelni, meghívó nélküli regisztráció esetén pedig elfogadott hozzáférési kérelem szükséges a rendeléshez.

Bővebben: az xHOSTING kontrollált hozzáférésű, közösségi alapú rendszer. Meghívóval történő regisztráció esetén a felhasználó külön kérelem nélkül rendelhet. Meghívó nélküli nyilvános regisztráció esetén rendelni csak akkor lehet, ha a felhasználó hozzáférési kérelmet nyújt be, és azt a rendszer automatikusan vagy adminisztrátori ellenőrzés után elfogadja. A cél továbbra is a közösség minőségének, biztonságának és fenntarthatóságának megőrzése.

Hogyan lehet regisztrálni és hozzáférést kérni?

Ha van érvényes meghívód, azzal regisztrálva azonnal kapsz rendelési jogosultságot, külön hozzáférési kérelem nélkül.

Ha nincs meghívód, akkor nyilvánosan is regisztrálhatsz az ügyfélrendszerben. Ilyenkor a fiók létrejön, de rendeléshez hozzáférési kérelmet kell benyújtani. A kérelem tartalma alapján az automata rendszer elfogadhatja, elutasíthatja, vagy további adminisztrátori ellenőrzésre továbbíthatja.

Ki jogosult meghívót küldeni?

Meghívót kizárólag megfelelő jogosultsággal rendelkező xHOSTING tag küldhet.

A meghívási jog nem alapértelmezett jog, hanem státuszhoz és közösségi feltételekhez kötött. Az, hogy egy tag rendelkezik-e aktív meghívási jogosultsággal, a közösségi szabályzatban rögzített feltételektől és az xHOSTING üzemeltetőinek döntésétől függ.

Van-e korlátozva, hogy egy tag hány meghívót küldhet?

Igen, a meghívások száma korlátozott.

Egy jogosult tag összesen meghatározott számú meghívót használhat fel ami jelenleg: 1 meghívó. A meghívási jog nem halmozható, nem újul meg automatikusan, és minden meghívó véglegesen felhasználásra kerül annak elfogadásával. A korlátozás célja az erőforrások védelme és az oversell kizárása.

Mit jelent a meghívóhoz kapcsolódó felelősség?

A meghívó kiállítása felelősséggel jár.

A meghívóval rendelkező tag felelősséget vállal azért, hogy a meghívott személy megismeri és betartja az xHOSTING szabályait, különösen a viselkedési szabályokat és az elfogadható használati irányelveket (AUP). Ismételt vagy súlyos visszaélések esetén a meghívó jogosultság korlátozható vagy visszavonható.

Mi történik, ha a meghívott megszegi a szabályokat?

Szabálysértés esetén az xHOSTING az eset súlyosságától függően intézkedik.

Ez figyelmeztetést (WARN), szolgáltatás-korlátozást vagy akár a tagság megszüntetését is jelentheti. Súlyos vagy ismétlődő szabálysértések esetén a meghívót kibocsátó tag meghívási jogosultsága vagy tagsága is érintett lehet.

Visszavonható vagy lejárhat egy meghívó?

Igen, a meghívó visszavonható és érvényessége korlátozott lehet.

Az xHOSTING fenntartja a jogot arra, hogy egy meghívót technikai, biztonsági vagy közösségi okokból visszavonjon. A fel nem használt meghívók lejárhatnak, illetve érvénytelenné válhatnak, ha a meghívót kibocsátó tag elveszíti meghívási jogosultságát.

Eladható vagy átruházható egy meghívó?

Nem. A meghívó sem el nem adható, sem át nem ruházható.

A meghívó kizárólag arra a személyre vonatkozik, akinek azt a jogosult tag eredetileg szánta. A meghívók értékesítése, cseréje vagy harmadik fél részére történő továbbadása súlyos szabálysértésnek minősül, és azonnali szankciókat vonhat maga után.

Miért kontrollált hozzáférésű rendszer az xHOSTING?

Az xHOSTING kontrollált hozzáférési modellje a közösség minőségének, biztonságának és fenntarthatóságának védelmét szolgálja.

A nyitott regisztráció nem jelenti azt, hogy bárki automatikusan rendelhet szolgáltatást. Automatikus rendelési jogosultságot érvényes meghívó ad; meghívó nélkül a hozzáférési kérelem segít abban, hogy a közösség létszáma és erőforrás-használata kontrollált maradjon, és csökkenjen a visszaélések, túlterhelések és jogi kockázatok esélye.

Miben különbözik az xHOSTING egy hagyományos tárhelyszolgáltatótól?

Az xHOSTING nem klasszikus tárhelyszolgáltató, hanem egy közösségi technikai infrastruktúra.

Nincs nyilvános csomagkínálat, SLA, ügyfélszolgálati prioritás vagy garantált rendelkezésre állás. A rendszer nem üzleti logika mentén működik, hanem közösségi hozzájárulásokra és önkéntes üzemeltetésre épül.

Üzleti szolgáltatásnak minősül az xHOSTING?

Nem, az xHOSTING közösségi kezdeményezés, nem üzleti tárhelyszolgáltatás.

A közösségi (ingyenes) szolgáltatások nem minősülnek kereskedelmi hostingnak vagy elektronikus hírközlési szolgáltatásnak. Egyes külön szolgáltatások (például domain regisztráció) külön jogviszony alapján, díjköteles szolgáltatásként érhetők el.

Kötelező fizetni a csatlakozáshoz vagy a tagsághoz?

Nem, a tagság önmagában nem díjköteles.

Az xHOSTING működését a közösség önkéntes támogatásai segítik. Ezek nem minősülnek vásárlásnak vagy előfizetésnek, és nem járnak automatikus jogosultságokkal vagy garanciákkal.

Mit jelent a „közösségi alapú működés” a gyakorlatban?

A közösségi alapú működés azt jelenti, hogy az xHOSTING nem ügyfél–szolgáltató viszonyban működik.

A tagok közösen járulnak hozzá a rendszer fenntartásához, betartják a közösségi szabályokat, és felelősen használják az erőforrásokat. A hangsúly a bizalmon, az együttműködésen és a fenntarthatóságon van.

Mit kap egy tag a közösségi tagságért cserébe?

A tag hozzáférést kap az xHOSTING közösségi infrastruktúrájához.

Ez magában foglalhat webes tárhelyet, e-mail szolgáltatásokat, adatbázisokat, SSH-hozzáférést és az xHOSTING Control Panel (XCP) használatát. A pontos lehetőségek az aktuális erőforrás-kapacitástól és beállításoktól függenek.

Milyen esetben szűnhet meg egy tagság?

A tagság megszűnhet szabálysértés, visszaélés vagy közösségi döntés alapján.

Súlyos vagy ismétlődő szabályszegés, az AUP megsértése, illetve a közösség működését veszélyeztető magatartás a tagság megszüntetését eredményezheti.

Lemondható-e a tagság önkéntesen?

Igen, a tagság bármikor önkéntesen megszüntethető.

A tag kérheti fiókja lezárását, amely után a közösségi (ingyenes) szolgáltatásokhoz való hozzáférés megszűnik. A megszűnés nem jár kötelezettségekkel vagy szankciókkal.

Mi történik a szolgáltatásokkal tagság megszűnésekor?

A közösségi szolgáltatásokhoz való hozzáférés megszűnik.

Az xHOSTING a megszűnést követően korlátozott ideig megőrizheti az adatokat technikai célból, majd azokat véglegesen törli. A díjköteles szolgáltatások (például domain szolgáltatás) külön jogviszony alapján továbbra is elérhetők maradhatnak.

Hol érhetők el az xHOSTING szabályai és irányelvei?

Az xHOSTING szabályai és irányelvei nyilvánosan elérhetők a hivatalos weboldalon.

Ide tartozik különösen a Szabályzat (Policy), az Elfogadható Használati Szabályzat (AUP), az Adatkezelési Tájékoztató és a Süti (Cookie) Szabályzat. Ezek a dokumentumok a csatlakozás előtt és a tagság teljes időtartama alatt is hozzáférhetők, és a közösségi tagság alapját képezik.

Milyen magatartást vár el az xHOSTING a tagoktól?

Az xHOSTING a tagjaitól kulturált, tiszteletteljes és bizalmi alapú magatartást vár el.

A tagok kötelesek betartani a szabályzatot, mások erőforrásait és jogait tiszteletben tartani, valamint tartózkodni minden olyan tevékenységtől, amely a közösség működését, hírnevét vagy biztonságát veszélyezteti.

Mi az a WARN, és mikor alkalmazható?

A WARN hivatalos figyelmeztetés, amelyet szabályszegés esetén alkalmazhatnak az Üzemeltetők.

WARN adható például az Elfogadható Használati Szabályzat megsértése, közösségi normákat sértő viselkedés, erőforrásokkal való visszaélés vagy ismétlődő kisebb szabálytalanságok esetén. A WARN célja nem a büntetés, hanem a figyelemfelhívás és a közösség védelme.

Van-e fellebbezési lehetőség közösségi döntések esetén?

A közösségi döntések nem hatósági vagy hivatalos jogi döntések.

Az Üzemeltetők lehetőséget adhatnak egyeztetésre vagy konzultációra, azonban a tagsági, moderációs vagy közösségi működéssel kapcsolatos döntések nem minősülnek fellebbezhető közigazgatási határozatnak.

Befolyásolja-e a közösségi viselkedés a későbbi jogosultságokat?

Igen, a közösségi viselkedés közvetlen hatással lehet bizonyos jogosultságokra.

A szabálykövető, együttműködő magatartás feltétele lehet például a meghívási jogosultság megszerzésének vagy megtartásának. Aktív WARN, visszaélések vagy ismétlődő szabályszegések esetén egyes jogosultságok korlátozhatók vagy visszavonhatók.

Mi az XBASIC csomag célja az xHOSTING-ben?

Az XBASIC az egységes, ingyenes webtárhelyprofil belső, az xHOSTING Control Panel (XCP) felületén használt csomagneve. Nem fizetős „Basic” szint, és nem tartozik hozzá „Pro” csomaglépcső.

Célja egy stabil, átlátható és fenntartható technikai alap biztosítása weboldalakhoz, e-mailhez és kisebb online projektekhez a közösségi elvek tiszteletben tartásával.

Kinek ajánlott az XBASIC csomag?

Az XBASIC csomag azoknak ajánlott, akik megbízható, de nem üzletszerű tárhelyet keresnek.

Különösen alkalmas magánprojektekhez, bemutatkozó oldalakhoz, kisebb webalkalmazásokhoz, levelezéshez, tanulási vagy fejlesztési célokra, illetve olyan felhasználóknak, akik elfogadják a közösségi működés és az erőforrás-megosztás elveit.

Van-e más csomag az XBASIC-en kívül?

Jelenleg egyetlen egységes, ingyenes webtárhelyprofil van; ennek belső XCP-csomagneve az XBASIC.

Az elnevezés nem fizetős csomaghierarchiát jelent. Az egységes profil segíti az átlátható működést, a túlterhelés elkerülését és a közösségi erőforrások igazságos elosztását.

Bővíthető vagy módosítható-e később az XBASIC csomag?

Az XBASIC csomag alapvetően fix keretekkel rendelkezik.

Bizonyos jogosultságok vagy technikai lehetőségek – például speciális hozzáférések – egyedi elbírálás alapján, kérésre engedélyezhetők, ha az nem veszélyezteti a közösség működését. Klasszikus értelemben vett csomagbővítés vagy skálázás nem része a rendszernek.

Mit jelent az, hogy az erőforrások közösségi elven működnek?

A közösségi elv azt jelenti, hogy az xHOSTING infrastruktúráját a tagok közösen használják, egymásra tekintettel.

Az erőforrások nem garantált, elkülönített kapacitások, hanem megosztott technikai lehetőségek. Ezért elvárás, hogy minden tag rendeltetésszerűen használja a szolgáltatásokat, kerülje a túlzott terhelést, és tiszteletben tartsa a közösség érdekeit.

Mit jelent a 25 GiB tárhely a gyakorlatban?

A 25 GiB tárhely az xHOSTING-ben a webes fájlok, adatbázisok, e-mail fiókok és kapcsolódó adatok együttes tárolására szolgál.

A használható webhelyek vagy alkalmazások száma nem rögzített: a tényleges kihasználtság a fájlok, adatbázisok és levelezési adatok méretétől függ. A kapacitásérték önmagában nem jelent alkalmazáskompatibilitási ígéretet.

Mit jelent a 10 TiB forgalmi keret?

A 10 TiB az egységes webtárhelyprofil publikus adatforgalmi kerete.

Az érték nem jelent garantált sávszélességet vagy üzleti SLA-t; a tényleges felhasználás a kiszolgált tartalomtól és a forgalomtól függ.

Mi történik a forgalmi keret elérésekor?

A publikus profil nem rögzít automatikus sebességcsökkentési vagy felfüggesztési szabályt.

Az aktuális kezelésről a Támogatási rendszerben kérhető tájékoztatás; a dokumentált keretből nem következik korlátlan forgalom vagy garantált teljesítmény.

Mi történik, ha elfogy a tárhelyem?

Az egységes profil tárhelykerete 25 GiB. A további adatokhoz előbb szabad tárhelyet kell biztosítani, például szükségtelen saját fájlok vagy e-mailek eltávolításával.

A publikus profil nem rögzít automatikus korlátozási vagy felfüggesztési szabályt. Az aktuális kezelésről a Támogatási rendszerben kérhető tájékoztatás.

Milyen típusú fájlokat tárolhatok a tárhelyen?

A tárhelyen elsősorban weboldalak működéséhez szükséges fájlok, adatbázisok, e-mail adatok és kapcsolódó tartalmak tárolhatók.

Tilos a jogszabályba ütköző, szerzői jogot sértő, káros (pl. malware), illetve a közösségi erőforrásokat indokolatlanul terhelő tartalmak elhelyezése. A részletes tiltások az Elfogadható Használati Szabályzatban (AUP) találhatók.

Mit jelent az, hogy 5 domain használható?

Az egységes webtárhelyprofilban egy tag összesen legfeljebb 5 különálló domainnevet használhat.

Ezek lehetnek önálló weboldalak vagy külön funkciót ellátó domainek. A limit célja a közösségi erőforrások kiegyensúlyozott használata, nem pedig a mesterséges korlátozás.

Használhatok saját domain nevet az xHOSTING-en?

Igen. Az xHOSTING teljes mértékben támogatja saját tulajdonú domainek használatát.

A domain lehet máshol regisztrált, ebben az esetben a DNS beállításokat az xHOSTING által megadott értékekre kell irányítani. A domainkezelés és DNS-szerkesztés az xHOSTING Control Panel (XCP) felületén érhető el.

Mit jelent az összesen 10 aldomain?

Az aldomain egy fő domain alá tartozó külön cím, például blog.pelda.hu vagy dev.pelda.hu.

Az egységes webtárhelyprofilban összesen 10 aldomain használható. Ez a teljes profil közös kerete, nem domainenként járó mennyiség.

Lehet-e később további domaineket hozzáadni?

Az egységes profil 5 domain használatát engedélyezi. Ez a dokumentált keret; a felület nem ígér automatikus bővítést ezen felül.

Törölhetem vagy cserélhetem a fő domainemet?

Igen. A fő domain törlése és cseréje engedélyezett az XCP felületén.

A művelet előtt a tag felelőssége a kapcsolódó weboldalak, e-mail fiókok és adatok mentése. A domain törlése után a hozzá kapcsolódó szolgáltatások megszűnhetnek vagy újrakonfigurálást igényelhetnek.

Mit jelent a 10 e-mail-fiók és a 20 e-mail-cím/alias?

Az egységes profilban legfeljebb 10 önálló e-mail-fiók hozható létre, amelyek saját postaládával és bejelentkezéssel rendelkeznek.

Az e-mail-címek és aliasok ettől külön, összesen 20 darabos keretet alkotnak.

Mi a különbség az e-mail fiók és az e-mail cím között?

Az e-mail fiók egy technikai postaláda, amelyhez tartozik felhasználónév, jelszó és tárhely.

Az e-mail cím viszont egy elérési cím (pl. info@domain.hu), amely egy e-mail fiókra mutat, vagy továbbításként más címekre irányít.

Egy e-mail-fiókhoz több e-mail-cím is rendelhető aliasként; a profil összesen 20 e-mail-címet és aliast engedélyez.

Használható-e catch-all (gyűjtőcím) funkció?

Igen. Az XBASIC csomag támogatja a catch-all (gyűjtőcím) funkciót.

A catch-all lehetővé teszi, hogy a domainre érkező minden, nem létező címre küldött levél egy megadott e-mail fiókba érkezzen. A beállítás az XCP felületén végezhető el.

Állíthatók-e be e-mail továbbítások?

Igen. Az egységes profil legfeljebb 20 e-mail-továbbítás létrehozását teszi lehetővé.

A továbbítás segítségével egy e-mail címre érkező levelek automatikusan másik címre (például külső levelezőszolgáltatóhoz) kerülnek továbbításra, postaláda létrehozása nélkül is.

Használható-e külső levelezőkliens (pl. Outlook, Thunderbird)?

Igen. Az xHOSTING e-mail szolgáltatása teljes mértékben kompatibilis a szabványos levelezőprotokollokkal.

A levelezés használható külső klienssel (pl. Outlook, Thunderbird, Apple Mail) IMAP/POP3 és SMTP protokollon keresztül. A szükséges kiszolgálóadatok az XCP felületén érhetők el.

Mit jelent az 5 adatbázisos keret?

Az egységes profilban legfeljebb 5 adatbázis hozható létre az XCP felületén.

Ez a limit az adatbázisok számára vonatkozik (pl. site1_db, site2_db, wp_db), nem pedig a táblák számára. Egy adatbázison belül tetszőleges számú tábla lehet, amíg a tárhely- és erőforrás-keretekbe belefér.

Milyen webes alkalmazások kompatibilisek az xHOSTING adatbázis-rendszerével?

Egy alkalmazás akkor használható biztonságosan, ha adatbázis-, PHP- és erőforrásigénye megfelel az aktuális tárhelykörnyezetnek és a dokumentált profilkereteknek.

A publikus profil nem rögzít konkrét alkalmazáskatalógust, adatbázismotort vagy motorverziót. Telepítés előtt az alkalmazás követelményeit és az XCP felületén ténylegesen elérhető környezetet kell összevetni.

Telepíthető-e webes alkalmazás vagy CMS?

Igen, ha az adott alkalmazás megfelel az AUP-nak, a tárhelyprofil erőforráskereteinek és az aktuálisan elérhető futtatókörnyezetnek.

Telepítés előtt ellenőrizni kell az alkalmazás követelményeit. A rögzített PHP-limitek közé tartozik a 256M memory_limit és a 128M upload_max_filesize; ezek saját php.ini fájllal és az XCP felületén sem módosíthatók.

Van-e alkalmazástelepítő az xHOSTING Control Panel (XCP) felületén?

Igen. Az XBASIC csomagban engedélyezett az „Alkalmazások” jogosultság: ez hozzáférést ad az XCP alkalmazástelepítő funkciójához, amellyel több népszerű webes alkalmazás telepítése egyszerűsíthető.

A pontosan elérhető alkalmazáslista az XCP-ben látható, és idővel változhat.

Használhatok saját fejlesztésű alkalmazást?

Igen. Saját fejlesztésű webalkalmazást is futtathatsz, ha betartod az xHOSTING szabályait (különösen az AUP-t), és az alkalmazás nem terheli aránytalanul a közösségi erőforrásokat.

Az XBASIC csomag támogatja a tipikus webes stack-et (FTP, PHP, SSH, adatbázis), így egyedi PHP-projektek, statikus oldalak, illetve kontrollált környezetben futó alkalmazások is megvalósíthatók.

Mit jelent az 5 FTP-felhasználós keret?

Az egységes profilban legfeljebb 5 különálló FTP-felhasználót hozhatsz létre az XCP felületén.

Minden FTP felhasználó saját felhasználónévvel és jelszóval rendelkezik, és külön-külön használható fájlok feltöltésére, módosítására vagy törlésére. Ez hasznos például akkor, ha több weboldalt, aldomaint vagy fejlesztőt szeretnél elkülöníteni.

Elérhető-e böngészőből használható fájlkezelő?

Igen. Az XCP tartalmaz böngészőből használható fájlkezelőt.

A fájlkezelő lehetővé teszi többek között:

  • fájlok feltöltését és letöltését,
  • könyvtárak létrehozását és törlését,
  • fájlok szerkesztését (pl. konfigurációs fájlok),
  • jogosultságok alapvető kezelését.

Ez különösen hasznos, ha gyors módosítást szeretnél végezni FTP-kliens használata nélkül.

Használható-e SFTP vagy titkosított kapcsolat?

Igen. Az xHOSTING környezetben a fájlok eléréséhez titkosított kapcsolat is használható.

Amennyiben az SSH engedélyezve van a fiókodhoz, az FTP-felhasználók SFTP-n keresztül is csatlakozhatnak, amely az SSH protokollt használja, így az adatforgalom titkosított.

Ez ajánlott megoldás nyilvános hálózatokon, illetve érzékeny adatok kezelésekor.

Korlátozhatók-e az FTP felhasználók jogosultságai?

Az FTP-felhasználó tényleges könyvtári hatóköre az aktuális XCP-beállításoktól függ, ezért létrehozáskor ellenőrizni kell, hogy pontosan mely fájlokhoz kap hozzáférést.

A publikus profil az FTP-felhasználók számát rögzíti, de nem ígér meghatározott izolációs technológiát vagy minden környezetben azonos jogosultsági modellt.

Milyen PHP verziók érhetők el?

Az xHOSTING Control Panel (XCP) felületén a PHP-verzió domainenként választható.

Aktívan frissülő ágak; mindegyikből az adott ág legfrissebb stabil javítókiadása érhető el:

  • PHP 8.5
  • PHP 8.4
  • PHP 8.3
  • PHP 8.2

Kompatibilitási célból elérhető, rögzített régi verziók:

  • PHP 8.1.34
  • PHP 8.0.30
  • PHP 7.4.33
  • PHP 7.3.33
  • PHP 7.2.34
  • PHP 7.1.33
  • PHP 7.0.33
  • PHP 5.6.40

A régi verziók új projektekhez nem ajánlottak. Az ionCube Loader azokhoz a PHP-verziókhoz érhető el, amelyekhez hivatalos, stabil ionCube Loader-kiadás áll rendelkezésre.

Módosíthatók-e a PHP beállítások (memory_limit, upload size stb.)?

Nem. Az alábbi négy PHP-erőforráslimit központilag rögzített:

  • memory_limit: 256M
  • max_execution_time: 180 másodperc
  • post_max_size: 128M
  • upload_max_filesize: 128M

Az értékek saját php.ini fájllal és az XCP felületén sem módosíthatók. A domainenkénti PHP-verzió-választás ettől külön funkció.

Mit jelent az open_basedir és a disable_functions megjelenítése?

Az open_basedir a PHP-szkriptek könyvtárhozzáférését korlátozhatja, a disable_functions pedig meghatározott PHP-függvények letiltására használható.

A publikus profil nem rögzíti e beállítások konkrét értékét, hatókörét vagy XCP-beli megjelenítését. Egy alkalmazás követelményeit mindig az aktuális PHP-környezet tényleges beállításaival kell összevetni.

Mit jelent a PHP-FPM működési módja?

Az ondemand pm a PHP-FPM (Process Manager) központilag beállított működési módja.

Ebben a módban:

  • a PHP folyamatok csak akkor indulnak el, amikor tényleges kérés érkezik,
  • inaktív állapotban nem fogyasztanak erőforrást,
  • hatékonyabb memóriahasználatot biztosít közösségi környezetben.

Ez a működés különösen alkalmas alacsony vagy közepes forgalmú weboldalakhoz, és jól illeszkedik az xHOSTING fenntartható erőforrás-kezelési elvéhez.

Mit jelentenek a pm.max_children és pm.max_requests értékek?

Ezek a PHP-FPM működését szabályozó, központilag rögzített szerveroldali paraméterek; a felhasználó nem módosíthatja őket.

pm.max_children:

  • meghatározza, hogy egyszerre hány PHP folyamat futhat,
  • az egységes profilban ez az érték: 3,
  • ez védi a rendszert a túlterheléstől.

pm.max_requests:

  • megadja, hogy egy PHP folyamat hány kérés kiszolgálása után induljon újra,
  • az egységes profilban: 1000,
  • segít megelőzni a memória-szivárgásból eredő problémákat.

Ezek az értékek biztosítják az egyensúlyt a stabilitás, a teljesítmény és a közösségi erőforrás-használat között.

Van-e SSH hozzáférés az XBASIC csomagban?

Igen. Az egységes webtárhelyprofil korlátozott SSH-környezetet biztosít parancssoros, tárhelyhez kapcsolódó feladatokhoz.

Ez nem teljes rendszerszintű hozzáférés; a ténylegesen elérhető parancsokat és lehetőségeket mindig az aktuális tárhelykörnyezetben kell ellenőrizni.

Mit jelent a korlátozott SSH környezet?

A korlátozott SSH-környezet tárhelyhez kapcsolódó parancssoros hozzáférést ad, de nem jelent teljes rendszerszintű jogosultságot.

A publikus profil nem ígér meghatározott izolációs technológiát vagy állandó parancskészletet. Egy feladat előtt az aktuális környezetben kell ellenőrizni a szükséges eszköz elérhetőségét.

Futtathatok saját parancsokat SSH-n keresztül?

A korlátozott SSH-környezetben az ott elérhető, tárhelyhez kapcsolódó parancsok futtathatók.

A publikus profil nem garantál konkrét fejlesztői eszközt vagy parancsot. Használat előtt ellenőrizd az aktuális környezet képességeit, és csak a saját tárhelyedhez tartozó műveleteket végezd el.

Kérhető-e egyedi esetben külső (remote) adatbázis-hozzáférés?

Röviden: a távoli adatbázis-kapcsolat alapértelmezetten nem érhető el, és a TCP/3306 port zárva van.

Kivétel kizárólag a Támogatási rendszerben benyújtott, részletes technikai indoklással ellátott egyedi kérelem alapján, külön jóváhagyás esetén, 1 előre megadott forrás-IP-címre engedélyezhető.

Kérhető-e egyedi engedély adatbázishoz?

Igen, de ez nem alapértelmezett csomagfunkció. A kérelmet a Támogatási rendszerben kell benyújtani részletes technikai indoklással.

A hozzáférés nem automatikus: egyedi jóváhagyást igényel, és jóváhagyás esetén is csak 1 előre megadott, konkrét forrás-IP-címre korlátozható.

Elérhető-e biztonságimentés-funkció?

Igen. Az egységes webtárhelyprofil része a biztonságimentés-funkció.

A publikus profil nem ígér meghatározott gyakoriságot, megőrzési időt vagy garantált visszaállítást. A fontos adatokról ezért mindig tarts saját, ellenőrzött másolatot is.

Hol ellenőrizhetők a mentési lehetőségek?

Az aktuálisan elérhető mentési lehetőségeket az xHOSTING Control Panel (XCP) felületén kell ellenőrizni.

A publikus profil nem rögzít konkrét célponttípust, díjazást vagy önálló visszaállítási garanciát.

Garantált-e egy konkrét mentési mód vagy célpont?

Nem. A publikus webtárhelyprofil biztonságimentés-funkciót rögzít, de nem ígér konkrét protokollt, külső szolgáltatót vagy célponttípust.

Mindig az XCP felületén látható aktuális lehetőségekből indulj ki.

Visszaállíthatók-e a mentések önállóan?

Az önálló visszaállítás lehetősége az aktuális mentési beállításoktól függ; a publikus profil erre nem ad általános garanciát.

Minden fontos adat esetén tarts saját, rendszeresen ellenőrzött mentést, és a visszaállítás módját még szükséghelyzet előtt próbáld ki.

Miért helyez hangsúlyt az xHOSTING a biztonságra a csomagok kialakításánál?

Az xHOSTING kontrollált hozzáférésű, közösségi alapú rendszerként működik, ahol több tag osztozik ugyanazon infrastruktúrán. Emiatt a biztonság nem csak egyéni, hanem közösségi érdek is.

A csomagok kialakításánál a cél az, hogy minden tag stabil, kiszámítható és biztonságos környezetben dolgozhasson, anélkül hogy egyetlen felhasználó tevékenysége veszélyeztetné a teljes rendszert.

Hogyan védi az xHOSTING a közösségi infrastruktúrát a visszaélésektől?

A dokumentált közösségi védelem többek között az alábbiakra épül:

  • erőforrás-korlátok (CPU, memória, folyamatok);
  • korlátozott SSH hozzáférés;
  • közösségi moderáció és szabályzat alapú fellépés.

A publikus profil nem nevez meg konkrét felhasználó-izolációs technológiát vagy megfigyelési megoldást.

Miben különbözik egy közösségi alapú hosting biztonsági modellje a kereskedelmitől?

Közösségi alapú hosting esetén a hangsúly a megosztott felelősségen és fenntarthatóságon van, nem pedig az egyéni túlhasználat kiszolgálásán.

Míg egy kereskedelmi szolgáltató gyakran túlfoglalással (overselling) és SLA-val dolgozik, az xHOSTING modellje inkább a:

  • konzervatív erőforrás-kiosztásra,
  • előrelátható terhelésre,
  • és a közösségi szabályok betartására

épül, ami hosszabb távon stabilabb és biztonságosabb működést tesz lehetővé.

Miért fontos az erőforrás-korlátok betartása minden Tag számára?

Az erőforrás-korlátok betartása biztosítja, hogy minden tag egyenlő és kiszámítható hozzáférést kapjon a közösségi infrastruktúrához.

Ha egy tag túllépi vagy figyelmen kívül hagyja ezeket a korlátokat, az:

  • más tagok szolgáltatásait lassíthatja vagy akadályozhatja;
  • stabilitási és biztonsági kockázatot jelenthet;
  • közösségi intézkedéseket (WARN, korlátozás) vonhat maga után.

Az xHOSTING működésének alapja a tudatos, felelős erőforrás-használat.

Miért nem érhető el minden funkció alapértelmezetten?

Az xHOSTING csomagjai tudatosan konzervatív alapbeállításokkal kerülnek kialakításra. Ennek célja a közösségi infrastruktúra stabilitásának, biztonságának és hosszú távú fenntarthatóságának megőrzése.

Egyes funkciók – például a távoli adatbázis-hozzáférés vagy speciális futtatási lehetőségek – fokozott kockázatot vagy erőforrás-terhelést jelenthetnek, ezért ezek nem érhetők el automatikusan minden tag számára.

Mit jelent az, hogy egy funkció „kérésre engedélyezhető”?

A „kérésre engedélyezhető” funkciók olyan lehetőségek, amelyek nem részei az alapcsomagnak, de indokolt esetben, egyedi elbírálás alapján aktiválhatók.

Ez azt jelenti, hogy a Tag megindokolhatja a funkció szükségességét (pl. fejlesztési, tesztelési vagy kompatibilitási okból), és az xHOSTING üzemeltetése mérlegeli, hogy az engedélyezés nem veszélyezteti-e a közösségi működést. A Technikai üzemeltető ebben az esetben kiemelt figyelemmel monitorozza az engedélyezett funkció erőforrás-használat mértékét, és annak a özösségi infrastruktúrára gyakorolt hatását.

Milyen szempontok alapján bírálják el az egyedi kéréseket?

Az egyedi kérések elbírálása során az alábbi fő szempontok kerülnek mérlegelésre:

  • a kért funkció technikai és biztonsági kockázata;
  • a várható erőforrás-használat mértéke;
  • a közösségi infrastruktúrára gyakorolt hatás;
  • a Tag korábbi közösségi magatartása és szabálykövetése;
  • a kérés indokoltsága és célja.

Az elbírálás célja nem az akadályozás, hanem a felelős, közösségbarát működés fenntartása.

Elutasítható-e egy kérés, és ha igen, miért?

Igen, egyedi kérés elutasítható, ha annak teljesítése:

  • biztonsági kockázatot jelentene;
  • aránytalan erőforrás-terhelést okozna;
  • ellentétes lenne az xHOSTING közösségi elveivel;
  • más tagok szolgáltatásait veszélyeztetné;
  • nem megfelelően indokolt.

Az elutasítás nem minősül szankciónak, hanem a közösségi működés védelmét szolgáló technikai döntés.

Elérhető-e a Perl/CGI?

Igen. A Perl/CGI az egységes webtárhelyprofil elérhető funkciója.

Használata során ugyanúgy be kell tartani az elfogadható használati szabályokat és a közösségi erőforrás-kereteket, mint más futtatási lehetőségeknél.

Mire kell figyelni Perl/CGI használatakor?

A Perl/CGI elérhető, de a szkripteket ugyanúgy biztonságosan és takarékosan kell üzemeltetni, mint más szerveroldali kódot:

  • tartsd naprakészen a használt kódot és függőségeket;
  • ne tárolj hitelesítő adatot nyilvánosan elérhető fájlban;
  • kerüld a túlzott erőforrás-használatot és a nem szükséges futtatást;
  • ellenőrizd a bemeneteket és a fájljogosultságokat.

Szükséges-e egyedi kérelem a Perl/CGI használatához?

Nem. A Perl/CGI az egységes webtárhelyprofil része, ezért a profil szerinti használatához nem szükséges egyedi engedélykérelem.

A használat továbbra is az elfogadható használati szabályok és a dokumentált erőforrás-keretek hatálya alá tartozik.

Milyen környezetben fut a Perl/CGI?

A Perl/CGI a webtárhely aktuális szerveroldali beállításai szerint fut.

A publikus profil nem állít konkrét izolációs vagy könyvtárhozzáférési modellt. Biztonsági szempontból csak a saját tárhelyedhez tartozó fájlokra és erőforrásokra támaszkodj.

Miért nem érhető el alapból a távoli adatbázis-hozzáférés?

A távoli adatbázis-kapcsolat alapértelmezetten nem érhető el, a TCP/3306 port zárva van.

Ez csökkenti a nyilvános hálózati támadási felületet; az alapértelmezett használat a tárhelykörnyezeten belüli adatbázis-kapcsolat.

Milyen kockázatokkal jár a nyilvános adatbázis-elérés?

A nyilvános adatbázis-elérés tipikus kockázatai:

  • brute-force (jelszópróbálgatás) és automata bot támadások;
  • sebezhetőségek kihasználása (régi kliensek, hibás konfiguráció, protokoll-támadások);
  • adatkiszivárgás gyenge jelszó vagy hibás jogosultságok esetén;
  • DoS / túlterhelés (sok kapcsolat, nagy lekérdezésszám, erőforrás-kimerítés);
  • rosszul beállított kliens miatti folyamatos reconnect, ami terhelést generál.

Mivel a támadók jellemzően tömegesen pásztázzák az internetet adatbázis-portokra, a nyilvános elérés önmagában is célponttá teszi a szolgáltatást.

Milyen esetben kérhető távoli adatbázis-hozzáférés?

Kizárólag akkor kérhető, ha részletesen megindokolható a technikai szükséglet.

A kérelmet a Támogatási rendszerben kell benyújtani; az engedélyezés minden esetben egyedi elbírálás és külön jóváhagyás alapján történik.

Hogyan történik a távoli adatbázis-hozzáférés biztonságos korlátozása?

Jóváhagyás esetén a kivétel kizárólag 1 előre megadott, konkrét forrás-IP-címre engedélyezhető.

Ez nem korlátlan vagy nyilvános internetes adatbázis-hozzáférés, és a TCP/3306 port más források számára zárva marad.

Miért korlátozott az SSH környezet az XBASIC csomagban?

A korlátozott SSH tárhelyhez kapcsolódó parancssoros munkát tesz lehetővé teljes rendszerszintű hozzáférés nélkül.

Ez a közösségi erőforrások kiszámítható használatát támogatja, de a publikus profil nem állít konkrét izolációs technológiát.

Használható-e az SSH fejlesztési vagy karbantartási célokra?

Igen, a korlátozott SSH-környezet az ott ténylegesen elérhető tárhelykezelési, fejlesztési vagy karbantartási feladatokra használható.

Egy konkrét eszköz vagy parancs elérhetőségét használat előtt az aktuális környezetben kell ellenőrizni.

Hol ellenőrizhető a korlátozott SSH parancskészlete?

A publikus webtárhelyprofil nem tart fenn garantált engedélyezett vagy tiltott parancslistát.

A szükséges parancs elérhetőségét az aktuális SSH-környezetben kell ellenőrizni; a hozzáférés nem jelent teljes rendszerszintű jogosultságot.

Mi számít túlzott vagy indokolatlan erőforrás-használatnak?

Túlzott vagy indokolatlan erőforrás-használatnak minősül minden olyan működés, amely aránytalanul nagy terhelést ró az xHOSTING közösségi infrastruktúrájára, és ezzel más Tagok szolgáltatásait is hátrányosan érintheti.

Ilyennek számít különösen:

  • tartósan magas CPU- vagy memóriahasználat;
  • nem optimalizált vagy hibás alkalmazások folyamatos futtatása;
  • indokolatlanul nagy I/O vagy adatbázis-terhelés;
  • automatizált szkriptek, crawlerek vagy háttérfolyamatok túl gyakori futtatása;
  • a csomag rendeltetésével össze nem egyeztethető terhelés (pl. bányászat, stresszteszt).

A megítélés mindig a közösségi működés és az adott csomag kereteinek figyelembevételével történik.

Hogyan érzékeli a rendszer a rendellenes terhelést?

Az xHOSTING infrastruktúra több szinten figyeli az erőforrások használatát. A rendszer automatikus monitorozással és naplózással érzékeli azokat a mintákat, amelyek eltérnek a megszokott, rendeltetésszerű működéstől.

A megfigyelés kiterjedhet többek között:

  • CPU- és memóriahasználati csúcsokra;
  • hosszú ideig futó vagy beragadt folyamatokra;
  • szokatlan adatbázis- vagy fájlműveletekre;
  • aránytalan hálózati forgalomra.

A cél nem a Tagok folyamatos ellenőrzése, hanem a közösségi stabilitást veszélyeztető helyzetek korai felismerése.

Mi történik, ha egy Tag folyamatosan túlterheli az erőforrásokat?

Ha egy Tag erőforrás-használata tartósan vagy ismétlődően túlterhelést okoz, az xHOSTING jogosult beavatkozni a közösség védelme érdekében.

A lehetséges intézkedések fokozatosak lehetnek, például:

  • érintett folyamatok ideiglenes korlátozása vagy leállítása;
  • adott szolgáltatás ideiglenes felfüggesztése;
  • a jogosultságok szűkítése;
  • súlyos vagy ismétlődő esetben a tagság megszüntetése.

A cél minden esetben a közösségi működés helyreállítása, nem pedig a büntetés.

Van-e figyelmeztetés a korlátozás előtt?

Igen, az xHOSTING törekszik arra, hogy a Tagokat előzetesen tájékoztassa a problémáról, amennyiben erre technikailag és időben lehetőség van.

A gyakorlatban ez jellemzően:

  • figyelmeztetés (WARN) formájában történik;
  • rövid magyarázattal az észlelt problémáról;
  • ajánlásokkal a terhelés csökkentésére vagy az alkalmazás javítására.

Azonnali beavatkozásra csak akkor kerül sor figyelmeztetés nélkül, ha a terhelés közvetlenül veszélyezteti a rendszer vagy más Tagok működését.

Mit jelent a 10 ütemezett feladatos keret?

Egy xHOSTING-fiókban legfeljebb 10 különálló időzített (cron) feladat hozható létre. Ezek a feladatok meghatározott időközönként futhatnak például karbantartási műveletekhez vagy alkalmazásfeladatokhoz.

A korlát célja nem a funkcionalitás szűkítése, hanem annak biztosítása, hogy az ütemezett folyamatok száma arányban maradjon a közösségi erőforrásokkal.

Használhatók-e cron feladatok hosszú futású műveletekre?

Az ütemezett feladatok elsősorban rövid ideig futó, jól körülhatárolt műveletekre szolgálnak. Hosszú futású vagy folyamatosan terhelő feladatok (például nagy adatfeldolgozás vagy végtelen ciklusok) futtatása cronból nem javasolt.

Amennyiben egy feladat rendeltetésszerűen hosszabb ideig futna, célszerű azt optimalizálni, feldarabolni, vagy egyedi egyeztetés alapján megoldást keresni. Az ilyen jellegű terhelések a közösségi infrastruktúra stabilitását veszélyeztethetik.

Miért fontos az ütemezett feladatok korlátozása közösségi környezetben?

Közösségi alapú hosting környezetben az ütemezett feladatok különösen érzékeny pontot jelentenek, mivel egyszerre, kiszámíthatatlan időben terhelhetik a rendszert.

A korlátozás célja:

  • a hirtelen terhelési csúcsok elkerülése;
  • a közösségi erőforrások igazságos megosztása;
  • annak megakadályozása, hogy egyetlen Tag automatikus folyamatai mások szolgáltatásait rontsák;
  • a rendszer hosszú távú stabilitásának megőrzése.

Az ütemezett feladatok tudatos használata minden Tag közös érdeke a megbízható működés érdekében.

Miért nem biztosít az xHOSTING SLA-t?

Az xHOSTING nem klasszikus, üzleti alapú hosting szolgáltatás, hanem egy közösségi, önkéntes hozzájárulásokon alapuló rendszer. Ennek megfelelően nem vállal szerződéses szolgáltatási szintet (SLA), mert az SLA jogilag és műszakilag is üzletszerű működést, garantált erőforrásokat és folyamatos rendelkezésre állást feltételezne.

A közösségi modell célja a fenntartható, korrekt és átlátható működés, nem pedig a kereskedelmi kötelezettségvállalások teljesítése.

Mit jelent a gyakorlatban, hogy nincs garantált uptime?

A garantált uptime hiánya azt jelenti, hogy az xHOSTING nem vállal konkrét százalékos rendelkezésre állási ígéretet. A szolgáltatások jellemzően stabilan működnek, azonban előfordulhatnak átmeneti kiesések.

A rendszer üzemeltetése során törekvés van a folyamatos működésre, de nincs jogi vagy pénzügyi kötelezettség egy adott üzemidő teljesítésére.

Milyen szerződéses vállalások nem járnak a közösségi szolgáltatáshoz?

Az ingyenes közösségi szolgáltatáshoz nem tartoznak a klasszikus üzleti hostingra jellemző szerződéses vállalások:

  • nincs SLA vagy garantált uptime;
  • nincs kieséshez kötött kötbér vagy jóváírás;
  • nincs fizetett ügyfélszolgálati prioritás.

Ez a kérdés a vállalások körét tisztázza; a közösségi működési modell általános különbségeit a korábbi áttekintő kérdés ismerteti.

Milyen esetekben fordulhat elő szolgáltatáskimaradás?

Szolgáltatáskimaradás előfordulhat többek között az alábbi esetekben:

  • tervezett karbantartás vagy frissítés során;
  • váratlan hardver- vagy szoftverhiba esetén;
  • biztonsági incidens megelőzésekor vagy kezelésekor;
  • külső infrastruktúra (pl. hálózati kapcsolat, energiaellátás) problémái miatt;
  • rendellenes vagy túlzott terhelés következményeként.

Az ilyen helyzetek kezelése mindig a közösség egészének védelmét és a hosszú távú működést szolgálja.

Mi az xHOSTING Control Panel (XCP), és mire szolgál?

Az xHOSTING Control Panel (XCP) az xHOSTING saját, egységes vezérlőfelülete, amelyen keresztül a Tagok kezelhetik a tárhelyükhöz és szolgáltatásaikhoz kapcsolódó beállításokat.

Az XCP segítségével többek között kezelhetők:

  • domainek és aldomain-ek;
  • e-mail fiókok és továbbítások;
  • adatbázisok;
  • fájlok és FTP/SFTP hozzáférések;
  • PHP-verzió kiválasztása és a rögzített PHP-limitek megtekintése;
  • biztonsági mentések;
  • tanúsítványok és domainbiztonsági funkciók.

A vezérlőpanel célja az önálló, átlátható és biztonságos adminisztráció biztosítása külön kliensprogramok telepítése nélkül.

Milyen rendszerre épül az xHOSTING Control Panel (XCP)?

Az xHOSTING Control Panel (XCP) műszaki alapját egy modern, Linux-alapú tárhelykezelő rendszer biztosítja.

Az xHOSTING több éves szakmai kapcsolatot alakított ki a vezérlőpanel fejlesztőivel, a rendszer hivatalos nyelvi honosítója, így a kereskedelmi változat teljes funkcionalitásával rendelkező hozzáféréssel rendelkezik, előre értesül a kiadás előtt minden frissítésről, változtatásról. Az XCP az xHOSTING működéséhez és szabályrendszeréhez igazított, testreszabott felületet és jogosultsági modellt alkalmaz, így a felhasználók számára egységes xHOSTING-élményt nyújt.

Miért az xHOSTING Control Panel (XCP) került kiválasztásra vezérlőpanelként?

Az xHOSTING Control Panel (XCP) kiválasztása több szakmai és közösségi szempont eredménye:

  • modern, aktívan fejlesztett rendszer;
  • átlátható jogosultságkezelés és erőforrás-korlátozás;
  • jó integráció PHP, FTP, SSH, e-mail és mentési funkciókkal;
  • nincs szükség felhasználónkénti licencelésre;
  • alkalmas közösségi alapú hosting modellhez.

A rendszer lehetővé teszi, hogy az xHOSTING biztonságos, fenntartható és rugalmas infrastruktúrát működtessen üzleti jellegű kötöttségek nélkül.

Miben különbözik az XCP egy klasszikus cPanel vagy Plesk rendszertől?

Az XCP eltér a klasszikus, kereskedelmi vezérlőpanelektől (mint a cPanel vagy a Plesk) több lényeges ponton:

  • nagyon felhasználóbarát;
  • nem üzleti hosting modellhez igazodik;
  • nem tartalmaz SLA-hoz vagy ügyfélszolgálati prioritáshoz kötött funkciókat;
  • szigorúbb, közösségi alapú erőforrás- és jogosultságkezelést alkalmaz;
  • a biztonság és a fenntarthatóság elsődleges szempont.

Míg a cPanel és a Plesk tömeges, kereskedelmi ügyfélkiszolgálásra készült, az XCP kifejezetten egy kontrollált hozzáférésű közösség igényeire lett hangolva.

Böngészőből használható-e minden funkció telepítés nélkül?

Igen. Az xHOSTING Control Panel (XCP) teljes mértékben webböngészőből használható, külön szoftver vagy kliens telepítése nélkül.

A legtöbb adminisztrációs feladat – például fájlkezelés, adatbázis-adminisztráció, e-mail beállítások vagy mentések kezelése – közvetlenül a böngészőn keresztül elérhető.

Egyes haladó funkciókhoz (pl. FTP kliens, SSH kapcsolat, külső levelezőprogram) opcionálisan használhatók külső eszközök, de ezek nem feltételei az XCP használatának.

Hogyan történik a belépés az xHOSTING Control Panel (XCP) felületére?

Az xHOSTING Control Panel (XCP) felületére egy egyedi felhasználónév és jelszó megadásával lehet belépni HTTPS-kapcsolaton keresztül.

A belépési adatok a tagság aktiválásakor kerülnek létrehozásra, és kizárólag a Tag saját fiókjához kapcsolódnak. A kapcsolat minden esetben titkosított, így a hitelesítési adatok nem kerülnek továbbításra nyílt formában.

Használható-e kétfaktoros hitelesítés (2FA) az XCP-ben?

Igen. Az xHOSTING Control Panel támogatja a kétfaktoros hitelesítést (2FA), amely további védelmi réteget biztosít a felhasználói fiókok számára.

A 2FA engedélyezése után a belépéshez a jelszó mellett egy időalapú, egyszer használatos kód is szükséges, amelyet egy hitelesítő alkalmazás (pl. mobiltelefonon futó authenticator) generál.

A kétfaktoros hitelesítés használata erősen ajánlott minden Tag számára.

Mit tehet a Tag, ha elfelejti a jelszavát?

Elfelejtett jelszó esetén a Tag a belépési oldalon elérhető jelszó-visszaállítási funkciót használhatja.

A rendszer ilyenkor egy ellenőrző üzenetet küld a fiókhoz tartozó kapcsolattartási e-mail címre, amelyen keresztül új jelszó állítható be.

Biztonsági okokból a régi jelszó nem visszaállítható, kizárólag új jelszó hozható létre.

Naplózza-e a rendszer a belépéseket és sikertelen próbálkozásokat?

Igen. Az xHOSTING Control Panel naplózza a sikeres és sikertelen belépési kísérleteket biztonsági célból.

A naplózás segít a gyanús tevékenységek felismerésében, a fiókok védelmében, valamint az esetleges visszaélések kivizsgálásában.

Ismétlődő sikertelen belépési próbálkozások esetén a rendszer automatikus védelmi intézkedéseket alkalmazhat (pl. ideiglenes korlátozás).

Hogyan lehet új domaint hozzáadni az XCP-ben?

Új domain hozzáadása az xHOSTING Control Panel (XCP) domainkezelő menüpontján keresztül történik.

A Tag megadhatja a domain nevét, kiválaszthatja annak típusát (fődomain, alias vagy aldomain), majd beállíthatja a hozzá tartozó webes, e-mail és DNS-paramétereket. A domain aktiválása után a rendszer automatikusan létrehozza a szükséges könyvtárstruktúrát és alapértelmezett beállításokat.

Mi a különbség a fődomain, alias domain és aldomain között?

Fődomain: önálló domain, saját webtartalommal és beállításokkal (pl. sajatdomain.hu).

Alias domain: egy meglévő fődomainre mutató kiegészítő domain, amely ugyanazt a tartalmat szolgálja ki (pl. sajatdomain.com → sajatdomain.hu).

Aldomain: a fődomain alá tartozó logikai egység, külön elérési úttal (pl. blog.sajatdomain.hu), amely külön könyvtárhoz és akár külön alkalmazáshoz is kapcsolódhat.

Hány domain és aldomain használható az XBASIC csomagban?

Az egységes profilban legfeljebb 5 domain és a teljes profilban összesen 10 aldomain használható.

A domainek elosztása rugalmas, azonban a megadott keretek a közösségi erőforrás-használat kiegyensúlyozása érdekében nem léphetők túl.

Törölhető-e egy fődomain az XCP-ből?

Igen. A Tag jogosult a saját fődomainjeinek törlésére az xHOSTING Control Panelen keresztül.

A törlés előtt a rendszer figyelmeztetést jelenít meg, mivel a művelet visszafordíthatatlan, és a domainhez kapcsolódó szolgáltatások megszűnnek.

Mi történik a domainhez tartozó adatokkal törléskor?

A domain törlésekor a hozzá kapcsolódó webes fájlok, adatbázis-kapcsolatok, e-mail fiókok és egyéb beállítások inaktívvá válnak, majd technikai késleltetést követően véglegesen törlésre kerülhetnek.

A Tag felelőssége, hogy törlés előtt gondoskodjon az adatok mentéséről. Az xHOSTING nem vállal felelősséget a törlésből eredő adatvesztésért.

Milyen DNS rekordok kezelhetők az XCP-ben?

Az xHOSTING Control Panel (XCP) felületén a leggyakrabban használt DNS rekordtípusok teljes körűen kezelhetők.

Ilyenek különösen az A, AAAA, CNAME, MX, TXT, SRV és CAA rekordok. Ezek segítségével beállítható a webes kiszolgálás, az e-mail forgalom, valamint különböző biztonsági és hitelesítési mechanizmusok (pl. SPF, DKIM, DMARC).

Használható-e saját DNS szerver domainenként?

Igen. A Tag dönthet úgy, hogy egy adott domainhez nem az xHOSTING által biztosított DNS-kezelést használja, hanem saját vagy külső DNS szervereket állít be.

Ebben az esetben a domain névszervereit (NS rekordokat) a regisztrátornál kell módosítani. Fontos, hogy ilyen konfigurációnál a DNS működéséért és a hibákért a Tag viseli a felelősséget.

Milyen esetben nem javasolt a DNS manuális szerkesztése?

A DNS rekordok kézi módosítása nem javasolt, ha a Tag nem biztos a beállítások hatásában vagy nincs tapasztalata DNS konfigurációk kezelésében.

Hibás bejegyzések esetén a weboldal, az e-mail szolgáltatás vagy egyéb kapcsolódó funkciók átmenetileg vagy tartósan elérhetetlenné válhatnak. Különösen körültekintően kell eljárni az MX és TXT rekordok módosításakor.

Mennyi idő alatt érvényesülnek a DNS módosítások?

A DNS módosítások érvényesülése nem azonnali, hanem az úgynevezett DNS propagáció függvénye.

Ez jellemzően néhány perctől akár 24–48 óráig is eltarthat, attól függően, hogy az adott rekord TTL értéke, valamint az internetszolgáltatók gyorsítótárazási gyakorlata hogyan alakul.

Melyek az xHOSTING saját névszerverei?

Az xHOSTING saját, központilag üzemeltetett névszervereket biztosít a közösségi tárhelyszolgáltatáshoz.

Az aktuális, hivatalos xHOSTING névszerverek listája mindig az xHOSTING Control Panel (XCP) felületén, valamint a dokumentációban érhető el. Ennek oka, hogy az infrastruktúra fejlődése vagy technikai átalakítása esetén a névszerverek címei változhatnak, és mindig az ott megadott adatok tekintendők hitelesnek.

Jelenlegi névszerverek:

  • ns1.xhostingcore.xyz
  • ns2.xhostingcore.xyz

A változtatás után a DNS delegáció frissülése általában néhány perctől akár 24–48 óráig is eltarthat, ez a globális DNS-rendszer működéséből adódik.

Hogyan állíthatom be más szolgáltatónál a domainem névszervereit az xHOSTING-ra?

Ha a domained egy külső regisztrátornál vagy szolgáltatónál van nyilvántartva, a névszervereket ott kell módosítanod.

A beállítás lépései általánosságban:

  • belépsz a domainregisztrátor kezelőfelületére
  • megkeresed a domain névszerver (nameserver) beállításait
  • lecseréled az ott megadott névszervereket az xHOSTING által biztosított névszerverekre
  • elmented a módosítást

A változtatás után a DNS delegáció frissülése általában néhány perctől akár 24–48 óráig is eltarthat, ez a globális DNS-rendszer működéséből adódik.

Ha saját vagy más szolgáltató névszervereit használom, hogyan irányítsam az xHOSTING-os tárhelyemre?

Ebben az esetben a domain DNS-zónáját nem az xHOSTING kezeli, hanem a külső névszerver szolgáltató.

Ilyenkor a következő DNS rekordokat kell megfelelően beállítani:

  • A rekord – a domain(ek)et az xHOSTING szerver IP-címére kell irányítani
  • AAAA rekord – ha IPv6 használatban van, az IPv6 cím megadásával
  • MX rekord – ha az xHOSTING levelezést is használsz, az e-mail szerverekhez tartozó rekordokkal
  • TXT rekordok – szükség esetén (pl. SPF, DKIM, DMARC)

Az XCP minden domainhez megjeleníti azokat az IP-címeket és ajánlott rekordértékeket, amelyek szükségesek ahhoz, hogy a webes és levelezési szolgáltatások megfelelően működjenek.

Fontos: ha külső DNS-t használsz, a DNS-konfiguráció pontossága teljes mértékben a domain tulajdonosának felelőssége. Hibás vagy hiányzó rekordok esetén a weboldal vagy az e-mail szolgáltatás nem fog megfelelően működni.

Milyen fájlkezelési lehetőségeket biztosít az XCP?

Az xHOSTING Control Panel (XCP) többféle fájlkezelési lehetőséget biztosít a Tagok számára.

A fájlok kezelhetők hagyományos FTP / SFTP kapcsolaton keresztül, valamint az XCP-be épített böngészőalapú fájlkezelő segítségével is. Ezekkel a módszerekkel lehetőség van fájlok feltöltésére, letöltésére, törlésére, átnevezésére, jogosultságok módosítására és könyvtárszerkezetek kezelésére.

Használható-e a beépített fájlkezelő FTP nélkül?

Igen. Az XCP beépített fájlkezelője teljes mértékben használható FTP vagy külső kliens nélkül.

A fájlkezelő webböngészőből érhető el, és alapvető adminisztrációs feladatokra (gyors módosítások, konfigurációs fájlok szerkesztése, kisebb feltöltések) kifejezetten praktikus megoldást nyújt.

Milyen jogosultságokkal érhetők el a fájlok?

A tényleges fájlhozzáférési hatókört az aktuális fiók- és könyvtárjogosultságok határozzák meg; fájlkezeléskor csak a saját tárhelyhez tartozó erőforrásokra szabad támaszkodni.

A publikus profil nem rögzít konkrét izolációs technológiát vagy részletes fájlrendszer-jogosultsági modellt.

Visszaállíthatók-e törölt fájlok az XCP-ből?

A publikus profil nem garantál lomtárat, verziókövetést vagy automatikus visszaállítást. Az aktuális lehetőségeket az XCP felületén kell ellenőrizni.

Visszaállítás csak használható korábbi mentésből lehetséges, ezért fontos saját, ellenőrzött másolatot tartani és annak visszaállíthatóságát rendszeresen próbával igazolni.

Hogyan hozható létre új FTP felhasználó?

Új FTP felhasználó az xHOSTING Control Panel (XCP) felületén hozható létre, önállóan, adminisztrátori beavatkozás nélkül.

A létrehozás általános lépései:

  • belépés az XCP-be
  • FTP felhasználók menüpont megnyitása
  • új FTP felhasználó hozzáadása
  • felhasználónév és jelszó megadása
  • a kezdőkönyvtár kiválasztása

A létrehozott FTP felhasználó azonnal használható a megadott hozzáférési adatokkal.

Korlátozható-e egy FTP felhasználó egy adott könyvtárra?

Igen. Az XCP lehetőséget biztosít arra, hogy egy FTP felhasználó kizárólag egy meghatározott könyvtárhoz férjen hozzá.

A könyvtárkorlátozás előnyei:

  • a felhasználó nem látja a teljes tárhelystruktúrát
  • csökkenti a véletlen vagy szándékos adatkárosítás kockázatát
  • ideális fejlesztők, alvállalkozók vagy részfeladatok esetén

A korlátozás már a felhasználó létrehozásakor vagy később is beállítható.

Az FTP-felhasználói keret domainenként vagy profilonként értendő?

A keret a teljes webtárhelyprofilra vonatkozik: összesen 5 FTP-felhasználó hozható létre, nem domainenként ennyi.

Egy már nem szükséges FTP-felhasználó törlése felszabadít egy helyet a dokumentált kereten belül.

Használható-e FTPS vagy SFTP az XCP-ben?

Igen. Az xHOSTING az FTP mellett titkosított kapcsolatokat is támogat.

Elérhető lehetőségek:

  • FTPS – FTP titkosított TLS kapcsolaton keresztül
  • SFTP – SSH-alapú biztonságos fájlátvitel

Az SFTP használatához szükséges az SSH hozzáférés engedélyezése, míg az FTPS külön SSH hozzáférés nélkül is használható.

A titkosított kapcsolatok használata erősen ajánlott, különösen nyilvános vagy nem megbízható hálózatról történő csatlakozás esetén.

Hogyan választható ki a PHP verzió domainenként?

Az xHOSTING Control Panel (XCP) lehetőséget biztosít arra, hogy a PHP verzió domainenként külön legyen kiválasztva.

A beállítás folyamata:

  • belépés az XCP-be
  • a domainek kezelése menüpont megnyitása
  • a kívánt domain kiválasztása
  • PHP verzió beállítása a domainhez

Ez lehetővé teszi, hogy egy tárhelyen belül több weboldal is eltérő PHP verzióval fusson, az adott alkalmazás igényeihez igazodva.

Mit mutat az XCP a rögzített PHP-limitekről?

Az XCP megjelenítheti a központilag rögzített PHP-erőforráslimiteket:

  • memory_limit: 256M
  • max_execution_time: 180 másodperc
  • post_max_size: 128M
  • upload_max_filesize: 128M

Ezek az értékek az XCP felületén és saját php.ini fájllal sem módosíthatók. A PHP-verzió domainenkénti kiválasztása külön funkció.

Mit jelentenek a rögzített PHP-erőforráslimitek?

A központi profil négy rögzített értéke: memory_limit 256M, max_execution_time 180 másodperc, post_max_size 128M és upload_max_filesize 128M.

  • memory_limit – egy PHP folyamat által maximálisan használható memória
  • max_execution_time – egy PHP szkript maximális futási ideje
  • post_max_size – egy POST-kérés maximális mérete
  • upload_max_filesize – egyetlen feltöltött fájl maximális mérete

Ezek a korlátok segítenek:

  • megelőzni a túlzott erőforrás-használatot
  • stabilan tartani a közösségi környezetet
  • csökkenteni a hibás vagy rosszindulatú szkriptek hatását

A limitek saját php.ini fájllal és az XCP felületén sem módosíthatók.

Mi az open_basedir, és miért fontos?

Az open_basedir egy PHP biztonsági korlátozás, amely meghatározza, hogy egy PHP szkript mely könyvtárakhoz férhet hozzá.

A publikus webtárhelyprofil nem állítja, hogy ez a beállítás milyen értékkel vagy hatókörrel aktív. Egy alkalmazás telepítése előtt az aktuális PHP-környezetet kell ellenőrizni; az open_basedir önmagában nem bizonyít teljes körű izolációt.

Mit jelent a disable_functions lista?

A disable_functions lista olyan PHP függvényeket tartalmaz, amelyek biztonsági okokból le vannak tiltva.

A publikus profil nem rögzít állandó függvénylistát. Egy alkalmazás kompatibilitásának megítélésekor az aktuális PHP-környezetben kell ellenőrizni a tényleges beállítást.

Hogyan hozható létre új adatbázis az XCP-ben?

Új adatbázis létrehozása az xHOSTING Control Panel (XCP) felületén néhány lépésben elvégezhető.

A létrehozás folyamata:

  • belépés az XCP-be
  • adatbázisok kezelése menüpont megnyitása
  • új adatbázis létrehozása opció kiválasztása
  • adatbázisnév és hozzá tartozó felhasználó megadása
  • jelszó beállítása vagy automatikus generálása

A létrehozott adatbázis azonnal használható webalkalmazásokhoz vagy egyedi fejlesztésekhez.

Milyen adatbázis-típusok támogatottak?

A publikus webtárhelyprofil az adatbázisok számát rögzíti, de nem nevez meg konkrét adatbázismotort vagy motorverziót.

Az aktuálisan támogatott típust és verziót az XCP felületén kell ellenőrizni, majd összevetni a használni kívánt alkalmazás követelményeivel.

Az adatbáziskeret domainenként vagy profilonként értendő?

A teljes webtárhelyprofilban összesen 5 adatbázis használható; ez nem domainenként ismétlődő keret.

Minden létrehozott adatbázis ebből a közös keretből foglal helyet, törlése pedig egy helyet felszabadít.

Elérhető-e webes adatbáziskezelő (pl. phpMyAdmin)?

Igen, az XCP biztosít webes adatbáziskezelő felületet, amely böngészőből érhető el.

A webes adatbáziskezelő lehetőséget ad:

  • táblák létrehozására és módosítására
  • adatok megtekintésére és szerkesztésére
  • SQL lekérdezések futtatására
  • adatbázis mentésére és importálására

A hozzáférés az adott adatbázishoz rendelt jogosultságokhoz kötött, így csak a saját adatbázisok kezelhetők.

Hogyan hozható létre új e-mail fiók az XCP-ben?

Új e-mail fiókot az xHOSTING Control Panel (XCP) e-mail kezelő felületén tudsz létrehozni.

Általános lépések:

  • lépj be az XCP-be
  • nyisd meg az E-mail / Postaládák (mailboxes) menüpontot
  • válaszd az Új postafiók létrehozása opciót
  • add meg a címet (pl. info@domain.tld) és a jelszót
  • mentsd a beállításokat

A profilban összesen 10 e-mail-fiók hozható létre. A fiók létrehozása után webmailen és levelezőkliensben is használható.

Mikor érdemes külön e-mail címet létrehozni, és mikor szükséges valódi e-mail fiók?

Röviden: ha a leveleket csak továbbítani szeretnéd egy másik postaládába, elegendő egy e-mail cím (alias vagy továbbítás). Ha külön bejelentkezéssel, saját tárhellyel rendelkező postaládára van szükség, akkor e-mail fiókot kell létrehozni.

Gyakorlati példák:

  • Továbbítás (alias): info@domain.hu → a levelek automatikusan a saját Gmail vagy más postaládába érkeznek.
  • Valódi e-mail fiók: külön bejelentkezés (IMAP/POP3), saját tárhely és jelszó, több eszközön használható postaláda.

Ez segít eldönteni, hogy valódi postaládára van szükséged, vagy elegendő egy egyszerű továbbítás.

Milyen kézbesítési és spamkockázata van a catch-all használatának?

Az egységes profilban elérhető catch-all (gyűjtőcím) minden, a domainen nem létező címre küldött levelet a megadott postaládába irányíthat.

A catch-all lényege:

  • minden, a domainre érkező, de nem létező címre küldött levél is kézbesül
  • a levelek egy megadott postaládába érkeznek (pl. catchall@domain.tld vagy admin@domain.tld)

Figyelem:

  • a catch-all gyakran több spamet vonz, ezért érdemes csak akkor bekapcsolni, ha tényleg szükséges
  • ha sok kéretlen levél érkezik, célszerű inkább konkrét címeket létrehozni vagy szűrést használni

Hogyan működik az e-mail-továbbítás az XCP-ben?

Igen. Az egységes profilban legfeljebb 20 e-mail-továbbítás használható.

Mire jó a továbbítás:

  • a levelek automatikusan átmennek egy másik címre (pl. gmailes címre)
  • hasznos, ha nem akarsz külön postaládát fenntartani, csak átirányítanád a leveleket

Javaslat:

  • ha sok levél várható, jobb postaládát használni, és onnan szabályokkal kezelni a forgalmat
  • körkörös továbbítás (A → B → A) kerülendő, mert kézbesítési hibát vagy végtelen hurkot okozhat

Hol kezelhetők az e-mail jelszavak és kvóták?

Az e-mail jelszavakat és (ha elérhető) kvótákat az XCP-ben, az adott postaláda részleteinél tudod kezelni.

Általában itt találod:

  • E-mail / Postaládák (mailboxes) lista
  • postaláda kiválasztása → Szerkesztés
  • Jelszó módosítása és kvóta beállítás

Biztonsági minimum:

  • használj hosszú, egyedi jelszót (javasolt: jelszókezelővel generált)
  • ha gyanús aktivitást látsz, azonnal cseréld a jelszót és nézd át a kliensbeállításokat

Hogyan működik a Let’s Encrypt tanúsítvány az XCP-ben?

Az XCP-ben a Let’s Encrypt lehetővé teszi, hogy a domainjeidhez ingyenes, automatikusan kiállított SSL/TLS tanúsítványt aktiválj.

Általános működés:

  • kiválasztod a domaint a tanúsítvány/SSL menüpontban
  • bekapcsolod a Let’s Encrypt igénylést
  • a rendszer egy technikai ellenőrzést végez (domain-ellenőrzés), majd kiállítja a tanúsítványt

Gyakori feltételek:

  • a domain DNS-e már az xHOSTING szerverére mutat
  • a webkiszolgálás elérhető (a validációt nem blokkolja tűzfal vagy hibás átirányítás)

Automatikusan megújulnak-e az SSL tanúsítványok?

Igen, a Let’s Encrypt tanúsítványok megújítása alapvetően automatikus, amennyiben a domain a megújítás időpontjában is sikeresen validálható.

Tipikus okok, amiért a megújulás elbukhat:

  • a domain már nem az xHOSTING-ra mutat
  • DNS hiba vagy hibás rekordok
  • a validációhoz szükséges HTTP/HTTPS elérés blokkolt
  • hibás vagy túl agresszív átirányítási szabályok

Ha a megújulás problémás, az XCP-ben jellemzően újraindítható/újraigényelhető a folyamat.

Mi az a HSTS, és mikor érdemes bekapcsolni?

A HSTS (HTTP Strict Transport Security) egy böngészőoldali biztonsági szabály, amely kikényszeríti, hogy a böngésző a domaint csak HTTPS-en keresztül érje el.

Előnyök:

  • csökkenti a „downgrade” és man-in-the-middle típusú támadások esélyét
  • a böngésző automatikusan HTTPS-re vált

Mikor érdemes bekapcsolni:

  • ha már biztosan működik a HTTPS minden aloldalon
  • ha nem használsz olyan külső erőforrást, ami csak HTTP-n érhető el

Figyelem:

  • HSTS mellett a hibás HTTPS beállítás „kizárhat” a webhelyből a böngésző cache miatt
  • először érdemes rövid max-age értékkel tesztelni, és csak utána emelni

Mit jelent az „add includeSubDomains” direktíva?

Az includeSubDomains egy biztonsági direktíva, amely a HTTPS-alapú működést nemcsak a fő domainre, hanem az összes meglévő aldomainre is kiterjeszti.

Gyakorlati jelentése:

  • minden aldomain kizárólag HTTPS-en keresztül érhető el
  • a böngészők automatikusan elutasítják a titkosítatlan (HTTP) kapcsolatot
  • csökkenti a „man-in-the-middle” támadások kockázatát

Fontos tudnivaló:

  • ez egyszeri művelet, amely az aktuálisan létező aldomainekre vonatkozik
  • ha később új aldomaineket hozol létre, a beállítást manuálisan frissíteni kell

Mit jelent az „add preload” direktíva?

A preload direktíva azt jelenti, hogy a domain felkerülhet a böngészők által használt HSTS preload listára.

Ez a gyakorlatban:

  • a böngészők már az első kapcsolatfelvételkor is csak HTTPS-t engedélyeznek
  • nincs lehetőség HTTP-s elérésre még átirányítás szintjén sem
  • extra védelmet ad az első kapcsolat során

Fontos megkötések:

  • a preload használatához az includeSubDomains is szükséges
  • a beállítás hosszú távú elköteleződést jelent HTTPS mellett
  • a preload listáról való eltávolítás időigényes és nem azonnali

Ezért a preload direktíva használata csak akkor ajánlott, ha biztos vagy benne, hogy minden aldomain hosszú távon HTTPS-en marad.

Mit jelent a biztonsági beállítások alkalmazása az összes aldomainre?

Ez azt jelenti, hogy a kiválasztott biztonsági szabályok (például HTTPS-kényszerítés, HSTS, includeSubDomains) nemcsak a fő domainre, hanem az összes meglévő aldomainre is érvényesek.

Előnyei:

  • egységes biztonsági szint minden aldomainen
  • kevesebb konfigurációs hiba
  • nagyobb védelem a véletlenül nyitva hagyott szolgáltatások ellen

Fontos tudni:

  • ez a beállítás nem automatikusan öröklődik a jövőben létrehozott aldomainekre
  • új aldomain hozzáadásakor a biztonsági beállításokat kézzel kell frissíteni
  • hibás vagy hiányos HTTPS-támogatás esetén egy aldomain elérhetetlenné válhat

Ajánlás:

  • csak akkor alkalmazd globálisan, ha minden aldomain megfelelően konfigurált
  • új aldomain létrehozása után mindig ellenőrizd a biztonsági beállításokat

Lehet-e saját tanúsítványt feltölteni?

Igen, ha rendelkezel saját SSL/TLS tanúsítvánnyal (például EV/OV vagy külső CA által kiállított tanúsítvány), azt az XCP-ben fel tudod tölteni.

Általában szükséges hozzá:

  • a tanúsítvány (CRT/PEM)
  • a privát kulcs (KEY)
  • esetleg köztes tanúsítvány lánc (CA bundle)

Javaslat:

  • ha nem muszáj külső CA, a Let’s Encrypt egyszerűbb és automatikusan megújul
  • saját tanúsítványt akkor érdemes használni, ha szervezeti igazolásra (OV/EV) vagy speciális megfelelésre van szükség

Hogyan működik a biztonsági mentés kezelése az XCP-ben?

Az egységes webtárhelyprofil tartalmaz biztonságimentés-funkciót, az aktuálisan elérhető kezelési lehetőségek pedig az xHOSTING Control Panel (XCP) felületén láthatók.

A publikus profil nem vállal meghatározott mentési gyakoriságot, megőrzési időt, célponttípust vagy garantált visszaállítást.

Hogyan ellenőrizhetők az aktuális mentési beállítások az XCP-ben?

Belépés után a mentési funkciókhoz tartozó XCP-felületen ellenőrizd, milyen beállítások és célpontok érhetők el ténylegesen az adott időpontban.

A publikus profil nem sorol fel garantált protokollokat, külső szolgáltatókat vagy célponttípusokat, ezért ezek elérhetőségét nem szabad feltételezni.

Garantált-e a mentések ütemezése vagy gyakorisága?

Nem. A publikus profil nem ígér automatikus, napi, heti vagy más rögzített gyakoriságú mentést.

Az aktuális lehetőségeket az XCP felületén kell ellenőrizni, a mentések meglétét és visszaállíthatóságát pedig rendszeresen próbával kell igazolni.

Ki felel az adatok rendszeres mentéséért?

A közösségi működési modellből adódóan az adatok rendszeres mentéséért elsődlegesen a Tag felel.

Ez a gyakorlatban azt jelenti, hogy:

  • a Tag feladata a saját mentési stratégia kialakítása
  • a Tag feladata a mentések ellenőrzése és a visszaállítás próbája
  • az xHOSTING nem vállal garantált, üzletszerű mentési kötelezettséget

Ajánlás:

  • kritikus adatok esetén mindig legyen több, egymástól független mentési példány
  • a mentések meglétét és használhatóságát időszakosan ellenőrizd

Milyen spam szűrést használ az xHOSTING?

Az xHOSTING több szintű, szerveroldali spam szűrést alkalmaz az e-mail forgalom védelmére.

A szűrés célja, hogy a nyilvánvaló kéretlen levelek már a kézbesítés előtt kiszűrésre kerüljenek, miközben a legitim üzenetek megbízhatóan megérkeznek. A rendszer figyelembe veszi többek között a feladó hírnevét, technikai hitelesítéseket és tartalmi jellemzőket.

Használ az xHOSTING SPF, DKIM és DMARC védelmet?

Az xHOSTING szerveroldali spam szűrése több rétegű védelmet alkalmaz.

A rendszer statisztikai elemzésen, adaptív (gépi tanulás alapú) pontozáson, valamint hitelesítési ellenőrzéseken (SPF, DKIM, DMARC) alapul. Ez lehetővé teszi, hogy a kéretlen levelek nagy része már a kézbesítés előtt kiszűrésre kerüljön.

Mit jelent az, hogy a spam szűrés „gépi tanulás alapú”?

A gépi tanulás alapú spam szűrés azt jelenti, hogy a rendszer statisztikai módszerekkel elemzi a levelek jellemzőit.

A szűrő figyelembe veszi többek között a levél tartalmát, fejlécadatait, küldési mintázatait és korábbi tapasztalatokat. Ezek alapján folyamatosan finomítja a pontozást, így idővel hatékonyabban különbözteti meg a valódi leveleket a spam üzenetektől.

Tanul-e a spam szűrő idővel?

Igen. A spam szűrő működése adaptív.

A rendszer a beérkező levelek mintázatai alapján folyamatosan javítja a felismerést. Ez azt jelenti, hogy a gyakran előforduló spam típusokat idővel egyre nagyobb pontossággal szűri ki, miközben csökkenti a téves riasztások (false positive) esélyét.

Hová kerülnek a spamnek minősített levelek?

A spamnek minősített levelek jellemzően nem kerülnek azonnal törlésre.

A rendszer a leveleket spam jelöléssel látja el, vagy elkülönített módon kezeli, így azok szükség esetén ellenőrizhetők. A pontos viselkedés a levelezési beállításoktól és a kliensoldali szűréstől is függ.

Előfordulhat, hogy egy valódi levél spamként kerül megjelölésre?

Igen, ritka esetben előfordulhat úgynevezett „false positive”, amikor egy legitim levél spamként kerül besorolásra.

Ez jellemzően hibásan konfigurált feladó domainek, hiányzó hitelesítések vagy szokatlan tartalmi minták esetén fordulhat elő. Ilyen helyzetben érdemes ellenőrizni a feladó technikai beállításait, illetve a levelezőkliensben engedélyezni a feladót.

Tehetek-e valamit a spam mennyiségének csökkentésére?

Igen. A spam mennyisége jelentősen csökkenthető tudatos beállításokkal.

Ajánlott lépések:

  • csak szükséges címeket használj, és ne tedd őket nyilvánossá;
  • használj külön címet regisztrációkhoz;
  • ellenőrizd, hogy a domain SPF, DKIM és DMARC rekordjai helyesen vannak beállítva;
  • használd a levelezőkliens saját szűrő- és szabályrendszerét.

A szerveroldali védelem és a felhasználói tudatosság együtt adja a legjobb eredményt.

Lehet-e teljesen spammentes e-mail szolgáltatást garantálni?

Nem. Teljes mértékben spammentes e-mail szolgáltatás nem létezik.

Az xHOSTING célja az, hogy a kéretlen levelek döntő többségét kiszűrje, miközben a valódi levelek megbízhatóan kézbesítésre kerülnek. A spam elleni védelem folyamatos egyensúlyt jelent a szigorúság és a kézbesítési biztonság között.

Kapcsolódik az xhosting.hu más, hasonló nevű szolgáltatókhoz?

Nem.

Az xhosting.hu nem áll kapcsolatban semmilyen más, hasonló nevű külföldi vagy belföldi tárhelyszolgáltatóval (pl. x10hosting).

Milyen feltételei vannak a .hu domain regisztrációnak?

A .hu domain regisztrációja feltételekhez kötött.

A domain igénylőjének az alábbi országok egyikének állampolgárának vagy ott bejegyzett jogi személynek kell lennie: Andorra, Albánia, Örményország, Ausztria, Azerbajdzsán, Belgium, Bosznia-Hercegovina, Bulgária, Csehország, Ciprus, Horvátország, Dánia, Észtország, Finnország, Franciaország, Németország, Georgia, Görögország, Magyarország, Írország, Izland, Olaszország, Liechtenstein, Litvánia, Luxemburg, Lettország, Észak-Macedónia, Málta, Monaco, Moldova, Montenegró, Hollandia, Norvégia, Lengyelország, Portugália, Románia, Szerbia, San Marino, Szlovénia, Szlovákia, Spanyolország, Svédország, Svájc, Törökország, Ukrajna.

Alternatív megoldásként akkor is jogosult lehet a regisztrációra, ha olyan gazdasági vagy egyéb tevékenységet folytat vagy indít, amely indokolja a .hu domain használatát.

A Nyilvántartó dokumentumokat kérhet be a jogosultság igazolására, és fenntartja a jogot a regisztráció elutasítására, ha a benyújtott dokumentumok nem megfelelőek vagy más okból nem fogadja el az igénylést.

A feltételek teljesítéséért minden esetben a felhasználó felel. Ha a regisztráció a feltételek nem teljesítése vagy a Nyilvántartó elutasítása miatt nem valósul meg, nincs visszatérítés.

Milyen feltételei vannak a .eu domain regisztrációnak?

A .eu domain regisztrációja feltételekhez kötött.

A domain igénylőjének az Európai Unió valamely tagállamában, Izlandon, Liechtensteinben vagy Norvégiában kell címmel rendelkeznie, vagy ezen országok valamelyikének állampolgárának kell lennie.

A Nyilvántartó igazolást kérhet az állampolgárságra vonatkozóan, különösen akkor, ha a regisztráló az Európai Gazdasági Térségen kívül rendelkezik lakóhellyel.

A feltételek teljesítéséért minden esetben a felhasználó felel. Ha a regisztráció a feltételek nem teljesítése vagy a Nyilvántartó elutasítása miatt nem valósul meg, nincs visszatérítés.

Milyen feltételei vannak a .fr domain regisztrációnak?

A .fr domain regisztrációja feltételekhez kötött.

A regisztrálónak és az adminisztratív kapcsolattartónak az Európai Unió valamely tagállamában vagy az alábbi országok egyikében kell címmel rendelkeznie: Izland, Liechtenstein, Norvégia, Svájc.

A támogatott országok és területek közé tartoznak például: Ausztria, Åland-szigetek, Belgium, Bulgária, Horvátország, Ciprus, Csehország, Dánia, Észtország, Finnország, Franciaország, Francia Guyana, Németország, Gibraltár, Görögország, Guadeloupe, Magyarország, Izland, Írország, Olaszország, Lettország, Liechtenstein, Litvánia, Luxemburg, Málta, Martinique, Mayotte, Hollandia, Új-Kaledónia, Norvégia, Lengyelország, Portugália, Réunion, Románia, Saint Pierre és Miquelon, Szlovákia, Szlovénia, Spanyolország, Svédország, Svájc, Francia Déli és Antarktiszi Területek, Wallis és Futuna.

A .fr domain trustee szolgáltatással is elérhető.

A feltételek teljesítéséért minden esetben a felhasználó felel. Ha a regisztráció a feltételek nem teljesítése vagy a Nyilvántartó elutasítása miatt nem valósul meg, nincs visszatérítés.

Milyen feltételei vannak a .it domain regisztrációnak?

A .it domain regisztrációja feltételekhez kötött.

A regisztráló lehet az Európai Unióban lakóhellyel rendelkező magánszemély, vagy az Európai Unióban bejegyzett, érvényes VAT számmal rendelkező szervezet.

A .it domain trustee szolgáltatással is elérhető.

A feltételek teljesítéséért minden esetben a felhasználó felel. Ha a regisztráció a feltételek nem teljesítése vagy a Nyilvántartó elutasítása miatt nem valósul meg, nincs visszatérítés.

Milyen feltételei vannak a .sk domain regisztrációnak?

A .sk domain regisztrációja feltételekhez kötött.

A regisztráló lehet bármely természetes vagy jogi személy, amennyiben postai címmel rendelkezik az Európai Unió valamely tagállamában, az Európai Gazdasági Térség valamely államában, vagy az Európai Szabadkereskedelmi Társulás valamely tagállamában.

A .sk domain trustee szolgáltatással is elérhető.

A feltételek teljesítéséért minden esetben a felhasználó felel. Ha a regisztráció a feltételek nem teljesítése vagy a Nyilvántartó elutasítása miatt nem valósul meg, nincs visszatérítés.

Van ingyenes játékszerver az xHOSTING-on?

Igen. Az xHOSTING kontrollált hozzáférésű, közösségi alapon ingyenes játékszerver hosztingot biztosít.

A szolgáltatás nem megvásárolható csomagként működik, hanem véges közösségi kapacitás alapján érhető el. A cél a stabil, átlátható működés és a kisebb játékos közösségek támogatása.

Milyen játékszerver típusok támogatottak?

A jelenlegi publikus keretek szerint az xHOSTING MTA, GTA5 (M) és ARK játékszervereket támogat.

A részletes erőforrás-keretek — például RAM, tárhely, CPU, maximális játékosszám, portok, mentések és adatbázisok — a főoldalon található támogatott játékszerver típusok táblázatban szerepelnek.

Van ingyenes GTA5 (M) szerver?

Igen, az xHOSTING a GTA5 (M) játékszervereket is támogatja, jóváhagyott közösségi hozzáféréssel. A pontos erőforrások itt találhatók.

A GTA5 (M) név a publikus oldalon szándékosan ezt a formát használja. A kiosztható kapacitás véges, ezért az elérhetőség mindig az aktuális közösségi erőforrásoktól függ.

Van ingyenes MTA szerver?

Igen, az xHOSTING MTA játékszervereket is biztosít közösségi alapon, meghívóval vagy jóváhagyott hozzáférési kérelemmel. A pontos erőforrások itt találhatók.

Az MTA szerverek kisebb közösségeknek, baráti játékhoz, fejlesztéshez és teszteléshez használhatók. A keretek célja nem a tömeges kiszolgálás, hanem a stabil működés.

Van ingyenes ARK: Survival Evolved szerver?

Igen, az xHOSTING ARK: Survival Evolved játékszervereket is biztosít közösségi alapon, meghívóval vagy jóváhagyott hozzáférési kérelemmel. A pontos erőforrások itt találhatók.

Az ARK szerverek korlátozott kapacitással érhetők el, ezért elsősorban kisebb közösségeknek, baráti játékhoz és teszteléshez ajánlottak.

Kinek kell hozzáférési kérelmet benyújtania?

Az xHOSTING véges erőforrásokra és közösségi bizalomra épül. Érvényes meghívóval regisztrálva a rendelési jogosultság azonnal megnyílik; meghívó nélküli regisztráció után viszont nem automatikus.

A hozzáférési kérelem a meghívó nélkül regisztráló felhasználóknál segít megelőzni a visszaéléseket, az erőforrások túlfoglalását és a túlterhelést. Ez nem akadály, hanem a stabilitás és a fenntartható működés egyik eszköze.

Kereskedelmi hosting szolgáltatás az xHOSTING?

Nem. Az xHOSTING nem klasszikus kereskedelmi tárhelyszolgáltató.

A közösségi webtárhely és játékszerver hoszting nem előfizetéses csomagként működik. A hangsúly a tanuláson, tesztelésen, fejlesztésen, hobbi projekteken és kisebb közösségek támogatásán van.

Mit jelent a GTA V RP megnevezés a GTA5 (M) keretben?

A GTA V RP a publikus oldalon a GTA5 (M) erőforrásmodell alá tartozó, szerepjáték jellegű GTA V multiplayer közösségi szervereket jelenti. A pontos keretek itt találhatók.

Ez nem külön kapacitáskategória: az elérhetőség a GTA5 (M) aktuális közösségi kapacitásától és a jóváhagyott hozzáféréstől függ.

Van DDoS védelem az xHOSTING-on?

Igen, az xHOSTING hálózati szintű DDoS-szűrést és szerveroldali tűzfalas védelmet használ.

Ez nem jelent korlátlan vagy garantált támadásvédelmet, de segít csökkenteni a támadási felületet, és javítja a webtárhelyek, valamint a játékszerverek stabil működését.

Mire használja az xHOSTING a regisztrációkor megadott adatokat?

Az xHOSTING a regisztráció során megadott adatokat nem használja visszaélésszerűen, nem értékesíti és nem kezeli a szükségesnél szélesebb célra.

Az adatok elsődleges célja a felhasználói fiók kezelése, a kapcsolattartás, a hozzáférési kérelmek elbírálása, valamint esetleges későbbi díjköteles szolgáltatások esetén a számlázási és adminisztratív kötelezettségek teljesítése.

A felhasználó bármikor kérheti adatainak törlését e-mailben vagy az ügyfélrendszerben indított Támogatási jegy útján. Jogszabályi megőrzési kötelezettség esetén az xHOSTING csak a kötelezően megőrzendő adatokat tartja meg a szükséges ideig.