Tek bir Chrome penceresinde birden çok yalıtılmış çalışma alanı: teknik olarak nasıl çalışıyor
Tek pencerede yalıtım üst üste üç katmandır: oturum ve depolama, ağ yönlendirmesi, yaşam döngüsü. Çekirdek sanallaştırması değildir ve parmak izini değiştirmez.
Neden birkaç pencere açmak, birkaç hesabın aynı anda açık olması demek değil
Önce bir sezgiyi sökelim: pencere, yalıtım birimi değildir. Aynı profilde on pencere tek bir çerez deposunu, tek bir localStorage’ı ve tek bir HTTP önbelleğini paylaşır; site tek bir oturum görür. Gizli modda gerçekten ayrı bir depo vardır, ama yalnızca birdir ve pencereyle birlikte ölür, dolayısıyla on hesaba yetmez. Gerçek birim oturum kapsayıcısıdır: kendine ait çerez kümesi, kendine ait depolama ad alanı ve kararlı bir aidiyet haritası. Chrome’un kendi kapsayıcı API’si yoktur — istisna Firefox’taki contextualIdentities’tir — bu yüzden uzantı bunu oturum katmanında kendisi kurar: hangi sekmenin hangi kapsayıcıya ait olduğunu kaydeder, sonra istekleri ve sayfa depolamasını bu haritaya göre böler. CrispLogin de böyle çalışır: kapsayıcı, uzantının tuttuğu bir aidiyet kaydıdır, Chrome’un bir ilkel öğesi değil. Yalıtımın birimi süreç değil, oturumdur.
Birinci katman: çerezler neden birbirine karışmıyor
Hesaplar sanal bir çerez kavanozu ve sekme düzeyinde istek başlığı yeniden yazımı sayesinde ayrı kalır. Her kapsayıcı, uzantının içinde kendi çerez kayıtlarını tutar. İstek çıkmadan önce declarativeNetRequest’in bir session rule’u sekmeyi condition.tabIds ile eşler ve cookie başlığını tümüyle o kapsayıcının değerine ayarlar; yanıt dönünce webRequest Set-Cookie’yi gözler ve ilgili kavanoza yazar. Kavanozun çerezleri yol uzunluğu, ardından oluşturma zamanı sırasıyla dizip serileştirmesi gerekir; aksi hâlde başlık tarayıcının kendi göndereceğiyle eşleşmez.
En çok atlanan nokta ömür: tabIds yalnızca session rule’larda çalışır ve session rule’lar tarayıcı kapanınca ve uzantı güncellenince silinir. Bu yüzden kurallar her açılışta yeniden kurulmalıdır; atlanırsa belirti “yeniden başlatınca bütün çalışma alanları aynı hesap oluyor” şeklinde görünür. Sayfa depolaması ikinci yüzdür: document.cookie gerçek çerez deposunu okur ve localStorage’ın tek bir ad alanı vardır, bu yüzden MAIN world’deki bir betiğin okuma ve yazmayı kapsayıcı bazında vekâleten yapması gerekir. Bu, uygulama katmanı yalıtımıdır: aynı sitedeki iki hesabı ayırır, ama çekirdek parmak izine dokunmaz.
İkinci katman: vekil sunucu çalışma alanını nasıl izliyor
Chrome’da “sekme başına vekil sunucu” API’si yoktur. chrome.proxy.settings tüm profile uygulanır ve bir PAC betiğindeki FindProxyForURL(url, host) hiçbir zaman tabId almaz; declarativeNetRequest başlıkları değiştirip yönlendirme yapabilir, ama “üst vekili seç” diye bir eylemi yoktur. Uzantının yapabildiği, çalışma alanı → çıkış haritasını tutmak ve öndeki sekme değiştiğinde bu profil geneli yapılandırmayı yeniden yazmaktır.
PAC alan adına göre ayırabilir, ama girdisi sekme değil URL’dir: aynı site iki çalışma alanında açıkken PAC tek bir yanıt verir. Bu yüzden “on çalışma alanı, her biri kendi tünelinde” bir uzantıda mümkün değildir; garanti edilen “hangi çalışma alanı öndeyse çıkış onundur”. Çalışma alanı değiştirirken bir yeniden bağlanma görülmesinin nedeni de budur: vekil yapılandırması değişince kurulu bağlantılar yeniden kurulur. Sınır: bu katman çıkış IP’sini ve istek yolunu değiştirir, TCP/TLS parmak izini (JA3/JA4) değiştirmez; WebRTC, chrome.privacy.network.webRTCIPHandlingPolicy ile vekilsiz UDP’yi kapatarak sınırlanabilir, ama bu tüm tarayıcıya ait bir politikadır, çalışma alanı başına değil.
Üçüncü katman: bağ, sekme kapanınca ve tarayıcı yeniden başlayınca kalıyor mu
MV3’ün arka planı bir service worker’dır: 30 saniye olay gelmezse sonlandırılır ve modül düzeyindeki değişkenlerle bir closure içindeki her Map birlikte kaybolur. Bu yüzden “hangi sekme hangi çalışma alanına ait” bellekte tutulamaz; chrome.storage.session’a yazılır. Bu alan uzantı yüklü olduğu sürece bellekte kalır, worker geri dönüştürülüp yeniden uyandığında durur, tarayıcı yeniden başlayınca silinir. Dikkat: varsayılan olarak içerik betiklerine açık değildir; sayfa tarafının bağı okuması gerekiyorsa setAccessLevel açıkça çağrılmalıdır.
Böylece veri ikiye ayrılır: çalışma zamanı bağları session’da, yeniden başlatmayı atlatması gereken her şey — çalışma alanı listesi, vekil yapılandırması, anlık görüntü dizini — storage.local’da. Nedensellik zinciri dolaysız: bağ değişkende değil session’da durduğu için, worker uyandığında uzantı her sekmenin kime ait olduğunu hâlâ bilir ve bir çalışma alanının çerezlerini diğerinin sayfasına boşaltmaz. Yalnızca bellekte tutulsa, worker uyuduğu anda sonraki isteğin soracağı bir sahibi olmaz; bu da yinelenen gruplar ve yanlış kapsayıcıya yüklenen anlık görüntüler olarak görünür.
Dördüncü katman: site anlık görüntüsü neyi saklar, neyi geri yükler
Anlık görüntü başka bir soruyu yanıtlar: oturum durumunun taşınabilirliği, çalışma zamanı yalıtımı değil. Listede dördüncü sırada ama yalıtımın kendisinin parçası değil. Bir sitenin bir kapsayıcı içindeki çerezlerini ve o sitenin depolamasını serileştirip saklar, geri yüklerken bu kapsayıcının ad alanına boşaltır. İkisi diktir: yalıtım iki çalışma alanı aynı anda varken birbirine karışmamasını sağlar, anlık görüntü yeniden giriş yapmadan bir duruma dönmeyi sağlar. Tanecik tarayıcı değil sitedir: aynı kapsayıcıdaki iki site birbiriyle ilgisiz iki kayıttır.
Bu yüzden anlık görüntü bir kapsayıcıya ait olmak zorundadır — A’nın oturum durumunu B’ye boşaltmak iki hesabı tek hesaba birleştirir. Yapmadığını söylemek de aynı derecede önemli: uygulama katmanındaki oturum durumunu geri yükler, çekirdek düzeyinde parmak izini değil; platformun risk kontrollerini veya cihaz doğrulamasını aşma sözü de vermez. Kullanım: İç bağlantı: site anlık görüntülerinin pratikte kullanımı.
Birkaç profil açmaktan farkı ne
Chrome’da çoklu profil, depolama kök dizini düzeyinde fiziksel bir kesimdir: her profilin kendi çerez deposu, kendi depolaması, kendi uzantıları ve önbelleği vardır, yani yalıtım eksiksizdir. Bedeli dört eksende görünür: bellek — her profilin kendi ağ bağlamı ve işleme süreçleri vardır, üç profil yaklaşık üç kat kalıcı maliyet demektir; süreçler — süreç ağaçları ayrıdır; pencereler — bir profil bir penceredir, geçiş pencere değiştirmektir; parmak izi — profiller aynı çekirdeği ve aynı makineyi paylaşır, UA, Canvas ve yazı tipleri varsayılan olarak aynıdır. Daha sessiz bir maliyet de var: yer imleri, uzantılar ve geçmiş paylaşılmaz, üçten sonra her biri kendi yoluna gider.
Uzantı yolu bunu tersine çevirir: tek profil, tek pencere, paylaşılan süreçler ve çekirdek; karşılığında tek pencerede paralellik ve neredeyse sıfır ek maliyet — ödenen bedel çekirdek parmak izi katmanına ulaşamamaktır. Bunlar aynı şeyin iki kademesi değil, yalıtım tanesini kesmenin iki farklı yoludur. Ayrıntılı karşılaştırma: İç bağlantı: Chrome profilleri ve uzantı yalıtımı.
Yetenek sınırı: uzantı hangi katmanları kapsıyor, hangilerini kapsamıyor
Yukarıdaki sınırlar tek bir tabloda. Okuma biçimi “platform neyi denetliyor”: oturum ve çıkış için orta sütun, parmak izi tutarlılığı için sağ sütun. Yinelemek gerekirse: uzantı oturum katmanı yalıtımı yapar, bu antidetect tarayıcıyla aynı düzey değildir; onu “daha hafif bir antidetect” saymak riski yanlış okumaktır.
| Katman | Uzantının kapsadığı | Ulaşamadığı ya da bedeli |
|---|---|---|
| Çerezler ve oturum durumu | Kapsayıcıya göre ayrılır, anlık görüntüye serileştirilebilir | Çekirdek kapsayıcı bilmez; başlıklar yeniden yazılır ve kurallar kaybolursa hesaplar karışır |
| Sayfa depolaması | localStorage ve IndexedDB kapsayıcı bazında öneklenebilir veya vekillenebilir | Service worker, SharedWorker ve benzeri ayrı bağlamlar kendi kapsamını gerektirir |
| Çıkış IP’si | Çalışma alanına bağlı; öndeki değişince çıkış da değişir | Aynı anda tek ön çıkış; eşzamanlı tüneller yok |
| WebRTC | Vekilsiz UDP kapatılabilir (tüm tarayıcı politikası) | Çalışma alanı başına değil; medya yolları yine de vekili atlayabilir |
| TLS parmak izi | Hiçbiri | JA3/JA4 çekirdek ve ağ yığını tarafından belirlenir |
| Canvas / WebGL / Audio | Hiçbiri | İşleme çekirdekte olur; yeniden yazmak için API yok |
| Yazı tipi sayımı | Hiçbiri | Yalnızca sayfa JS’inde yama, ve bu algılanabilir |
| HTTP önbelleği | Hiçbiri | Önbellek profil düzeyindedir ve kapsayıcılar arasında paylaşılır |
Tablo tavanın nerede olduğunu da gösteriyor: uzantının yerine geçtiği şey, yalnızca ayrı giriş yapmak için istemci satın alma güdüsüdür, istemcinin kendisi değil. Hangi yolun seçileceği ayrı bir sorudur ve madde madde İç bağlantı: uzantı ve antidetect tarayıcı yazısında karşılaştırılır.
Sık sorulan sorular
Uzantının yaptığı çerez yalıtımı Chrome’un Partitioned Cookie özelliğiyle aynı şey mi?
Değil. Partitioned Cookie üst düzey siteye göre anahtarlanır, yani bir sitenin her üst düzey sayfa için tek kavanozu olur; cookies API’sindeki partitionKey yalnızca bu çerezleri okuyup yazmaya yarayan anahtardır ve tek bileşeni topLevelSite’tır, onunla yeni bölümler uydurulamaz. Çalışma alanının kavanozu kapsayıcıya göre ayrılır, bir sitenin istediği kadar olabilir ve defteri uzantı tutar. İlki tarayıcının gizlilik bölümlemesi, ikincisi uzantının oturum soyutlamasıdır.
Sekmeyi kapattıktan sonra çalışma alanının durumu kalıyor mu?
Üç durum var. Sekme gitti, bağ da onunla gider. Çalışma alanı tanımları — ad, vekil, anlık görüntü dizini — yeniden başlatmayı atlatması gereken verilerdir ve genellikle storage.local’da durur. Oturum durumu yalnızca anlık görüntü kaydettiyseniz geri gelir; yoksa yeniden giriş yapılır. storage.session içeriği tarayıcı kapanınca silinir, onu kalıcı katman saymayın.
Tek pencere yaklaşımı tarayıcı performansını etkiliyor mu?
Artış yalıtımdan değil sekmelerden gelir. İkinci bir tarayıcı başlatılmaz, çekirdek kopyalanmaz; maliyet kural eşleştirme ve başlık yeniden yazımıdır, istek başına sabit bir iştir. Gerçek maliyet sekme sayısında ve sayfaların kendisindedir: yirmi çalışma alanında takılan şey işleme, yalıtım katmanı değildir.
İki çalışma alanı aynı anda farklı çıkış IP’si kullanabilir mi?
Hayır. Vekil yapılandırması profil düzeyindedir ve uzantı onu yalnızca sekme değişirken yeniden yazabilir, bu yüzden herhangi bir anda kendi çıkışını kullanan tek çalışma alanı öndeki olandır; arkadakiler ya kurallarla engellenir ya doğrudan çıkar. Gerçek eşzamanlı tüneller için kendi ağ yığınına sahip bir istemci gerekir.
Kaynaklar ve son güncelleme
Metnin API davranışına değindiği yerlerde resmî belgeler geçerlidir. Uzantının yetenek sınırları Chrome sürümleriyle değişir; benimsemeden önce o günkü belgelere bakın.
- Chrome for Developers, chrome.declarativeNetRequest — session rule ömrü, condition.tabIds kapsamı ve cookie istek başlığında modifyHeaders: developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest
- Chrome for Developers, chrome.storage — session alanı bellekte durur, tarayıcı yeniden başlayınca silinir ve varsayılan olarak içerik betiklerine kapalıdır: developer.chrome.com/docs/extensions/reference/api/storage
- Chrome for Developers, chrome.cookies — partitionKey ve Partitioned Cookie (CHIPS) anahtar semantiği: developer.chrome.com/docs/extensions/reference/api/cookies
- Chrome for Developers, chrome.proxy — vekil ayarları tüm tarayıcı profiline uygulanır ve PAC yalnızca URL ile host alır: developer.chrome.com/docs/extensions/reference/api/proxy
- Chrome for Developers, The extension service worker lifecycle — 30 saniye boşta kalınca sonlandırma ve genel değişkenlerin worker ile kaybı: developer.chrome.com/…/service-workers/lifecycle
Son güncelleme: 11 Kasım 2026. Burada anlatılan, bu sınıf uzantıların genel uygulama yoludur; hangi API’lerin ve hangi veri konumunun kullanıldığı ürüne göre değişebilir ve ürünün iç işleyişi için kendi belgeleri geçerlidir.