Yerel Web Sitenizi Gerçek Bir Telefonda Nasıl Test Edersiniz?

Yerel bilgisayarda bir web sitesi geliştirirken ilk önizleme genellikle aynı bilgisayardaki tarayıcıda yapılır. Bu faydalıdır, fakat çok pratik bir soruyu tek başına cevaplamaz: site gerçek bir telefonda nasıl hissettiriyor?

Native mobil uygulama geliştirirken bu tür bir test akışı zaten beklenen bir şeydir. iOS uygulaması geliştiriyorsanız Xcode, simülatörler ve gerçek cihaz testleri sürecin doğal parçasıdır. Android tarafında da Android Studio, emülatörler ve USB ya da kablosuz cihaz debugging akışı genellikle normal geliştirme döngüsüne dahildir.

Web geliştirme ise çoğu zaman daha rahat başlar: localhost açılır, tarayıcı daraltılır, belki DevTools içindeki responsive mod kullanılır ve devam edilir. Bu pratik bir yöntemdir, fakat gerçek mobil problemleri projenin sonuna kadar saklayabilir. Daha iyi bir web geliştirme akışı, gerçek cihaz testini de yerel geliştirme sürecinin parçası haline getirmektir.

Bu rehber yalnızca Django için geçerli değildir. Aynı yöntem çoğu yerel web geliştirme teknolojisinde kullanılabilir: Django, Laravel, Rails, Express, Vite, Next.js, Flask, FastAPI ve daha fazlası.

Temel fikir basittir:

1. Bilgisayarın yerel ağ IP adresini bulun.
2. Geliştirme sunucusunu yalnızca 127.0.0.1 yerine 0.0.0.0 üzerinde çalıştırın.
3. Framework host doğrulaması yapıyorsa LAN hostuna izin verin.
4. Telefondan http://BILGISAYAR_IP:PORT/ adresini açın.

Bu yazıda Django test edilen örnek projedir, fakat ağ yöntemi framework bağımsızdır.

Bu kurulumda telefondan açılan son adres şudur:

http://192.168.1.113:8000/

Sizin IP adresiniz muhtemelen farklı olacaktır, ancak yöntem aynıdır.

1. Bilgisayarın Yerel Ağ IP Adresini Bulun

Telefon, bilgisayarınızdaki geliştirme sunucusuna ulaşmak için 127.0.0.1 adresini kullanamaz. Telefonda 127.0.0.1, telefonun kendisi anlamına gelir.

Bu yüzden ilk adım bilgisayarın LAN IP adresini bulmaktır.

Windows PowerShell üzerinde:

Get-NetIPAddress -AddressFamily IPv4 |
  Where-Object { $_.IPAddress -notlike '127.*' -and $_.IPAddress -notlike '169.254*' } |
  Select-Object InterfaceAlias, IPAddress, PrefixLength

Bu projede kullanılabilir ağ arayüzü şuydu:

Ethernet 3    192.168.1.113    /24

Bu, telefon aynı ağdaysa şu adresi kullanması gerektiği anlamına gelir:

http://192.168.1.113:8000/

2. Geliştirme Sunucusunu 0.0.0.0 Üzerinde Çalıştırın

Birçok geliştirme sunucusu varsayılan olarak 127.0.0.1 adresine bağlanır. Bu yalnızca aynı bilgisayardan gelen bağlantıları kabul eder.

Telefondan test etmek için sunucunun tüm ağ arayüzlerini dinlemesi gerekir:

0.0.0.0

Temel fark şudur:

127.0.0.1:8000   yalnızca bilgisayar
0.0.0.0:8000     yerel ağdan erişim mümkün

Komut, kullanılan teknolojiye göre değişir.

Django örnek projesi için:

$env:DJANGO_ALLOWED_HOSTS="127.0.0.1,localhost,192.168.1.113"
python manage.py runserver 0.0.0.0:8000

Diğer teknolojilerde komut farklı görünür, fakat fikir aynıdır:

# Vite / React / Vue / Svelte
npm run dev -- --host 0.0.0.0

# Next.js
next dev -H 0.0.0.0

# Express
app.listen(3000, "0.0.0.0")

# Laravel
php artisan serve --host=0.0.0.0 --port=8000

# Rails
bin/rails server -b 0.0.0.0

# Flask
flask run --host=0.0.0.0

# FastAPI
uvicorn main:app --host 0.0.0.0 --port 8000

Araçlar farklıdır, ağ prensibi aynıdır.

3. Framework Host Doğrulamasını Yönetin

Bazı frameworkler, sunucu 0.0.0.0 üzerinde çalıştığı anda LAN isteklerini kabul eder. Bazıları ise ek host doğrulaması yapar.

Django bu konuda daha sıkı örneklerden biridir. Gelen Host header değerini kontrol eder. Telefon http://192.168.1.113:8000/ adresini açtığında Django şunu görür:

Host: 192.168.1.113:8000

Bu host izinli değilse Django isteği reddedebilir.

Tek bir IP adresini doğrudan settings.py içine yazmak yerine, Django örnek projesi izinli hostları environment variable üzerinden okuyacak şekilde güncellendi:

import os
from pathlib import Path

ALLOWED_HOSTS = [
    host.strip()
    for host in os.environ.get("DJANGO_ALLOWED_HOSTS", "127.0.0.1,localhost").split(",")
    if host.strip()
]

Bu yaklaşım projeyi esnek tutar. Bugün IP adresi 192.168.1.113 olabilir; yarın farklı bir değer olabilir.

Başka bir framework kullanıyorsanız benzer ayarları arayın:

• allowed hosts
• trusted hosts
• host header validation
• dev server host allowlist
• telefon ayrı bir API çağırıyorsa CORS veya origin ayarları

İsimler değişir, fakat neden aynıdır: framework, telefonun kullandığı host adresine güvenmek zorunda olabilir.

4. Sunucunun Dinlediğini Doğrulayın

Sunucuyu başlattıktan sonra yalnızca localhost üzerinde çalışmadığını doğrulayın.

Windows üzerinde:

Get-NetTCPConnection -LocalPort 8000

Sonuç şuna benzer olmalıdır:

LocalAddress    LocalPort    State
0.0.0.0         8000         Listen

Bu projede sunucunun şu adreste dinlediği doğrulandı:

0.0.0.0:8000

Bu, firewall izin verdiği sürece LAN bağlantılarının sürece ulaşabileceği anlamına gelir.

5. Host Davranışını Test Edin

Örnek proje Django olduğu için host davranışı doğrudan test edildi.

İlk test, LAN hostuna izin verildiğinde ana sayfanın render edildiğini kanıtlar:

@override_settings(ALLOWED_HOSTS=["192.168.1.113"])
def test_lan_host_can_render_homepage_when_allowed(self):
    response = self.client.get(
        reverse("services:service_list"),
        HTTP_HOST="192.168.1.113:8000",
    )

    self.assertEqual(response.status_code, 200)
    self.assertContains(response, "Professional Cleaning Services")

İkinci test tersini kanıtlar: aynı host izinli değilse reddedilir.

@override_settings(ALLOWED_HOSTS=["127.0.0.1"])
def test_lan_host_is_rejected_when_not_allowed(self):
    response = self.client.get(
        reverse("services:service_list"),
        HTTP_HOST="192.168.1.113:8000",
    )

    self.assertEqual(response.status_code, 400)

Bu, Django örneğindeki güvenlik sınırını açıkça belgelendirir. Telefon URL’i yalnızca LAN hostu açıkça izinli olduğunda çalışır.

Başka bir frameworkte aynı davranışı farklı şekilde test edebilirsiniz. Örneğin geliştirme sunucusunun LAN URL’ine cevap verdiğini, API’nin origin değerini kabul ettiğini veya host allowlist içinde LAN IP adresinin bulunduğunu kontrol edebilirsiniz.

6. Test Paketini Çalıştırın

LAN host testleri eklendikten sonra tüm test paketi çalıştırıldı:

python manage.py test

Sonuç:

Found 13 test(s).
System check identified no issues (0 silenced).
.............
----------------------------------------------------------------------
Ran 13 tests in 0.834s

OK

Örnek proje artık hem normal web sitesi davranışı hem de yerel ağ erişimi için otomatik test kapsamına sahip.

7. Localhost, LAN ve TCP Erişimini Doğrulayın

Önce yerel bilgisayardan kontrol yapıldı:

Invoke-WebRequest -UseBasicParsing http://127.0.0.1:8000/

Sonuç:

localhost status=200 contains=True

Ardından aynı bilgisayardan LAN IP adresi kontrol edildi:

Invoke-WebRequest -UseBasicParsing http://192.168.1.113:8000/

Sonuç:

lan status=200 contains=True

Son olarak TCP portu kontrol edildi:

Test-NetConnection -ComputerName 192.168.1.113 -Port 8000

Sonuç:

TcpTestSucceeded: True

Bu noktada geliştirme sunucusu doğru arayüzü dinliyor, örnek framework LAN hostuna izin veriyor ve port cevap veriyor.

8. Siteyi Telefonda Açın

Aynı Wi-Fi veya yerel ağa bağlı bir telefonda şu adresi açın:

http://192.168.1.113:8000/

Sayfa açılıyorsa aynı yerel web sitesini gerçek bir mobil cihazdan görüyorsunuz demektir.

Açılmıyorsa şunları kontrol edin:

• Telefon ve bilgisayar aynı ağda mı?
• Geliştirme sunucusu yalnızca 127.0.0.1 üzerinde değil, 0.0.0.0 üzerinde mi çalışıyor?
• Framework host doğrulaması yapıyorsa bilgisayarın LAN IP adresine izin veriyor mu?
• Windows Firewall ilgili process veya porta gelen bağlantıya izin veriyor mu?
• Ağ private/trusted mı, yoksa izole bir guest Wi-Fi mı?
• Frontend ayrı bir API çağırıyorsa o API de telefondan erişilebilir mi?

9. Bu Neden Önemli?

Tarayıcıdaki responsive mod faydalıdır, fakat yine de bir yaklaşımdır. Gerçek telefon, masaüstü tarayıcı araçlarının kaçırabileceği detayları gösterebilir:

• Dokunma alanlarının boyutu
• Gerçek font render davranışı
• Mobil tarayıcı arayüzü
• Ağ gecikmesi
• Scroll davranışı
• Sticky header veya form çevresindeki layout problemleri
• Gerçek cihaz klavyesinin davranışı

LAN erişimi, deploy etmeden önce yerel siteyi gerçek cihazda test etmeyi mümkün kılar. Bu küçük bir kurulum değişikliğidir, fakat geri bildirim kalitesini ciddi şekilde artırır.

Bu yaklaşım web geliştirmeyi, mobil uygulama geliştirmede zaten beklenen test disiplinine yaklaştırır. Bir web sitesini telefonda test etmek için Xcode veya Android Studio gerekmez, fakat yerel bir cihaz test yoluna ihtiyaç vardır. Geliştirme sunucusunu kendi telefonunuzdan açmak bunu çok düşük maliyetle sağlar.

Özellikle aktif geliştirme sırasında faydalıdır:

• Mobil boşluk ve hizalama sorunlarını müşteri görmeden yakalayabilirsiniz.
• Navigasyon, butonlar, formlar ve sticky header gibi alanları gerçek dokunma girdisiyle test edebilirsiniz.
• Tasarımın mobil tarayıcı arayüzü içinde hala iyi hissettirip hissettirmediğini görebilirsiniz.
• Yerel API çağrılarının ve frontend davranışının masaüstü tarayıcı dışında da çalıştığını doğrulayabilirsiniz.
• Dokümantasyon, QA veya müşteri güncellemeleri için gerçek ekran görüntüleri alabilirsiniz.

Önemli olan zamanlamadır. Mobil test son cilalama adımı olmamalıdır. Web sitesi hâlâ geliştirilirken yapılmalıdır.

10. Müşteri Aynı Ağda Değilse Ne Yapılır?

LAN yönteminin net bir sınırı vardır: 192.168.1.113 özel bir ağ adresidir. Yalnızca aynı yerel ağa bağlı cihazlarda çalışır.

Müşteri sizin Wi-Fi veya yerel ağınızda değilse şu adresi açamaz:

http://192.168.1.113:8000/

Uzaktaki bir müşteri için public veya paylaşılan bir erişim yolu gerekir. Yaygın seçenekler şunlardır.

Seçenek 1: Geçici Tünel

Hızlı bir demo için Ngrok, Cloudflare Tunnel, Tailscale Funnel veya LocalTunnel gibi bir tünel aracı kullanılabilir.

Fikir şudur:

local port 8000 -> public HTTPS tunnel URL -> müşteri tarayıcısı

Örnek:

ngrok http 8000

Müşteri şuna benzer bir URL alır:

https://example-subdomain.ngrok-free.app

Bu genellikle yerel çalışmayı uzaktaki bir müşteriye göstermenin en hızlı yoludur. Kısa demolar, tasarım incelemeleri ve hızlı geri bildirim oturumları için uygundur.

Dikkatli kullanın:

• Tüneli yalnızca ihtiyaç olduğunda açık tutun.
• Gerçek secret değerlerini veya production verilerini açığa çıkarmayın.
• HTTPS tünel URL’lerini tercih edin.
• Araç destekliyorsa basic authentication ekleyin.

Seçenek 2: Özel Ağ veya VPN

Siteyi public olarak açmadan uzaktan erişim vermek istiyorsanız Tailscale, ZeroTier veya geleneksel VPN gibi özel ağ araçları kullanılabilir.

Müşteri kontrollü bir özel ağa katılır ve geliştirme sunucunuzu bu özel rota üzerinden açar.

Bu public tünele göre daha güvenlidir, fakat müşterinin bir şey kurmasını veya yapılandırmasını gerektirir.

Şu durumlarda iyi çalışır:

• müşteri teknikse,
• erişim yalnızca onaylı kişilerle sınırlı olmalıysa,
• proje public olarak erişilebilir olmamalıysa,
• düzenli özel incelemeler gerekiyorsa.

Seçenek 3: Staging Deployment

Müşteri onayı, QA ve gerçekçi testler için çoğu zaman en profesyonel seçenek staging ortamıdır.

Laptop’ınızı dışarı açmak yerine projeyi staging ortamına deploy edersiniz:

Git repository -> staging server -> staging URL -> müşteri incelemesi

Örnek:

https://staging.example.com

Staging ortamı şu durumlarda daha iyidir:

• müşteri tekrar tekrar erişecekse,
• birden fazla kişi siteyi inceleyecekse,
• gerçek HTTPS/domain davranışı gerekiyorsa,
• deployment logları isteniyorsa,
• sabit bir URL gerekiyorsa,
• inceleme süreci günler veya haftalar sürecekse.

Bu proje için PostgreSQL ve environment variable desteği olan yönetilen bir platform iyi bir staging hedefi olur.

Seçenek 4: Router Port Forwarding

Teknik olarak router port forwarding ayarlayarak bilgisayarınızı doğrudan dışarı açabilirsiniz.

Bu genellikle şu anlama gelir:

public router IP -> forwarded port -> local computer -> dev server

Müşteri demoları için çoğu durumda en zayıf seçenektir.

Kaçınma nedenleri:

• ev veya ofis IP adresi değişebilir,
• HTTPS otomatik değildir,
• firewall kuralları kırılgan olabilir,
• bilgisayarınızın açık kalması gerekir,
• geliştirme sunucusu daha doğrudan dışarı açılır,
• açık portu unutmak kolaydır.

Bunun yerine tünel, özel ağ veya staging deployment kullanmak daha sağlıklıdır.

Karar Tablosu

Kural basittir: kendi cihazlarınız için LAN erişimini, hızlı uzaktan demolar için tüneli, ciddi müşteri incelemesi için staging ortamını kullanın.

Sonuç

Yerel bir web sitesini telefondan açmak için üç şeyin aynı anda doğru olması gerekir:

1. Bilgisayarın LAN IP adresi bilinmelidir.
2. Geliştirme sunucusu 0.0.0.0 üzerinde dinlemelidir.
3. Framework host doğrulaması yapıyorsa LAN hostuna izin verilmelidir.

Bu projede çalışan telefon URL’i şudur:

http://192.168.1.113:8000/

Kurulum framework testleri, HTTP kontrolleri ve TCP port kontrolü ile doğrulandı. Django test edilen örnekti, fakat yöntem yerel web geliştirme için geniş şekilde uygulanabilir.

Ağınız dışındaki müşteriler için LAN URL’i yeterli değildir. Hızlı demolar için geçici tünel, kontrollü erişim için özel ağ, profesyonel müşteri incelemesi için staging deployment kullanın.

Evidence

• Yerel ağ IP adresi 192.168.1.113 olarak tespit edildi
• Geliştirme sunucusu 0.0.0.0:8000 üzerinde başlatıldı
• Django örnek projesinde 127.0.0.1, localhost ve 192.168.1.113 hostlarına izin verildi
• Localhost isteği 200 döndürdü
• LAN IP isteği 200 döndürdü
• 192.168.1.113:8000 için TCP testi başarılı oldu
• Test paketi geçti: 13 test
• Uzaktaki müşteri erişimi için tünel, VPN/özel ağ, staging ve production deployment seçenekleri kavramsal olarak belgelendi