All Products
Search

This Product

    HTTPDNS:Cara Koneksi IP Langsung ke HTTPDNS Bekerja

    Document Center

    HTTPDNS:Cara Koneksi IP Langsung ke HTTPDNS Bekerja

    Last Updated:Nov 05, 2025

    1. Pendahuluan

    Dalam aplikasi mobile atau lintas platform, HTTPDNS sering digunakan untuk menghindari masalah seperti pembajakan DNS lokal dan polusi cache. Namun, tidak semua pustaka jaringan menyediakan antarmuka DNS Hook untuk integrasi. Koneksi IP langsung adalah solusi alternatif untuk skenario di mana Anda hanya dapat memodifikasi detail permintaan. Pertama, ambil hasil resolusi dari HTTPDNS. Kemudian, tulis ulang URL untuk menggunakan alamat IP langsung. Pastikan jabat tangan TLS dan perutean tetap menggunakan nama domain asli.

    Sebagai contoh, https://www.example.com menjadi https://1.2.3.4, tetapi header permintaan tetap mempertahankan Host: www.example.com.

    Topik ini berfokus pada skenario tipikal yang memerlukan koneksi IP langsung. Ini menjelaskan kondisi, masalah umum, dan solusi untuk membantu Anda memahami prinsip dasar pendekatan ini.

    2. Kapan menggunakan koneksi IP langsung

    Tentukan tingkat kontrol yang Anda miliki atas pustaka jaringan Anda untuk memutuskan apakah akan mengaktifkan koneksi IP langsung:

    • Memiliki DNS Hook atau Antarmuka Pemetaan Host-IP: Pustaka seperti OkHttp, libcurl, dan HarmonyOS Network Kit memungkinkan Anda menyuntikkan hasil HTTPDNS langsung ke antarmuka DNS. Anda kemudian dapat membuat permintaan menggunakan nama domain. Metode ini kompatibel dengan HTTPS, Server Name Indication (SNI), cookie, dan penggunaan kembali koneksi tanpa perubahan tambahan.

    • Tidak Memiliki DNS Hook, Tetapi Memiliki Kontrol API Permintaan: Jika pustaka jaringan tidak memungkinkan Anda mengganti DNS tetapi memungkinkan Anda menulis ulang detail seperti URL, header permintaan, kebijakan sertifikat, atau pengalihan, Anda dapat menggunakan koneksi IP langsung. Prosesnya melibatkan pengambilan alamat IP dari HTTPDNS, menulis ulang URL dengan alamat IP, dan menambahkan penanganan yang diperlukan untuk Host, sertifikat, proxy, dan cookie.

    • Sepenuhnya Tertutup: Jika pustaka jaringan tidak memiliki DNS Hook dan tidak ada titik kontrol API, seperti beberapa kernel WebView, koneksi IP langsung tidak memungkinkan. Sebaliknya, pertimbangkan untuk menggunakan SDK, DNS over HTTPS (DoH), proxy lokal, atau fitur spesifik vendor.

    Singkatnya, untuk pustaka jaringan "semi-terbuka" yang tidak mendukung DNS Hook, Anda dapat menggunakan koneksi IP langsung untuk berintegrasi dengan HTTPDNS.

    Penting

    • Cara H5 Berintegrasi dengan HTTPDNS: Saat JavaScript berjalan di browser, ia mengikuti Fetch Standard. Standar tersebut menetapkan bahwa Host adalah nama header terlarang. Oleh karena itu, untuk permintaan yang dibuat melalui API seperti XMLHttpRequest dan fetch(), skrip tidak dapat mengubah Host. Ini berarti Anda tidak dapat menggunakan koneksi IP langsung untuk berintegrasi dengan HTTPDNS. Dalam skenario ini, Anda harus mengandalkan lingkungan runtime, seperti WebView, CEF, atau Electron, untuk melakukan penanganan ini di lapisan host. Atau, gunakan proxy lokal atau solusi DoH.

    3. Masalah dan solusi

    Bagian ini pertama-tama memperkenalkan konsep jaringan terkait interaksi klien-server. Kemudian, menjelaskan masalah yang muncul dari penggunaan koneksi IP langsung dan solusinya.

    3.1 Konsep terkait semantik nama domain

    • Server Name Indication (SNI): SNI adalah ekstensi protokol Transport Layer Security (TLS). Klien memberi tahu server nama domain target selama jabat tangan. Ini memungkinkan server memilih sertifikat dan host virtual yang benar. SNI sangat penting dalam skenario IP bersama atau multitenancy. Misalnya, ketika node CDN melayani beberapa nama domain, SNI memastikan bahwa sertifikat HTTPS yang benar dikembalikan. Ini mengonfirmasi legitimasi dan keamanan koneksi.

    • Validasi Sertifikat CN/SAN: Selama jabat tangan TLS, klien secara ketat memvalidasi sertifikat HTTPS yang dikembalikan oleh server. Pustaka jaringan biasanya mengekstrak nama domain target dari URL. Ini menggunakan nama domain ini sebagai Common Name (CN) atau Subject Alternative Name (SAN) yang diharapkan. Kemudian, ia mengurai CN/SAN aktual dari sertifikat untuk perbandingan. Jika tidak cocok, koneksi ditolak atau dianggap sebagai koneksi tidak tepercaya dan tidak aman.

    • Header Host: Sejak HTTP/1.1, header Host adalah bidang wajib. Ini digunakan untuk membedakan situs target ketika beberapa situs di-host pada alamat IP dan port yang sama. Untuk server, ini adalah dasar utama bagi host virtual atau reverse proxy untuk merutekan permintaan dengan akurat. Untuk lapisan tengah, kunci cache, kebijakan otentikasi, dan aturan pembatasan laju sering kali didefinisikan pada level Host. Manajemen cookie sisi klien juga bergantung pada Host untuk isolasi domain. Jika Host dikonfigurasi dengan salah, status logon mungkin ditulis ke domain IP atau gagal digunakan kembali.

    3.2 Masalah yang diperkenalkan oleh koneksi IP langsung

    Seperti yang ditunjukkan pada gambar berikut, URL permintaan asli klien adalah https://www.example.com. Karena pustaka jaringan tidak menyediakan DNS Hook, Anda harus menulis ulang URL menjadi https://1.2.3.4 untuk menerapkan hasil resolusi DNS dari HTTPDNS. Ketika URL ditulis ulang untuk koneksi IP langsung, masalah berikut terjadi selama interaksi antara klien dan layanan target:

    image

    • Server Mengembalikan Sertifikat HTTPS Abnormal: Ketika nilai SNI yang diekstraksi oleh pustaka jaringan dari URL berubah dari www.example.com menjadi 1.2.3.4, server target tidak dapat menemukan sertifikat yang cocok. Itu hanya dapat mengembalikan sertifikat HTTPS default, yang menyebabkan jabat tangan gagal.

    • Klien Gagal Validasi Sertifikat HTTPS: Pustaka jaringan mengurai CN/SAN yang diharapkan sebagai 1.2.3.4 bukan www.example.com. Karena CN/SAN dalam sertifikat, seperti www.example.com atau *.example.com, tidak cocok dengan alamat IP, validasi TLS gagal dan jabat tangan tidak dapat diselesaikan.

    • Server Tidak Dapat Merutekan ke Layanan yang Dituju: Perangkat lunak server web seperti Nginx, Apache, dan server web lainnya mendukung host virtual. Fitur ini memungkinkan berbagai situs untuk diterapkan pada server fisik dan port yang sama. Permintaan dirutekan ke situs yang benar berdasarkan header Host. Saat klien mengekstrak Host yang diharapkan dari URL, Host tersebut berubah dari www.example.com menjadi 1.2.3.4. Hal ini menyebabkan server tidak dapat menemukan layanan yang sesuai dan mengembalikan kode status 404.

    • Manajemen Cookie Sisi Klien Gagal: Pustaka jaringan klien biasanya menyimpan Cookies berdasarkan header Host. Ia mengikat Cookie ke alamat IP spesifik 1.2.3.4 bukan nama domain www.example.com. Ini mencegah penggunaan kembali Cookies di bawah domain asli. Karena hasil resolusi untuk nama domain yang sama sering beralih ke alamat IP yang berbeda setelah cache kedaluwarsa, Cookies hanya dapat diikat ke alamat IP masing-masing. Ini mengarah pada hilangnya status logon dan ketidakmampuan untuk berbagi sesi. Ini juga dapat menyebabkan kegagalan kebijakan keamanan.

    • Koneksi Klien Tidak Dapat Digunakan Kembali: Pustaka jaringan modern umumnya mendukung penggunaan kembali koneksi HTTP berdasarkan Host untuk mengurangi overhead jabat tangan TCP dan meningkatkan efisiensi respons. Saat Anda beralih ke koneksi IP langsung, granularitas penggunaan kembali berubah dari nama domain www.example.com menjadi alamat IP 1.2.3.4. Koneksi yang ada tidak dapat dibagikan antara alamat IP yang berbeda, yang menciptakan overhead jabat tangan tambahan.

    3.3 Solusi untuk masalah koneksi IP langsung

    Masalah yang dijelaskan sebelumnya terjadi karena koneksi IP langsung menggunakan alamat IP yang diselesaikan oleh HTTPDNS. Untuk menyelesaikan masalah ini, Anda harus secara manual memulihkan informasi nama domain untuk SNI, validasi sertifikat, dan header Host HTTP. Ini memastikan tumpukan jaringan terus bekerja berdasarkan semantik nama domain.

    • Secara Manual Atur SNI: Panggil konfigurasi TLS/SNI atau API SocketFactory yang diekspos oleh pustaka jaringan untuk menulis nama domain asli ke dalam ekstensi SNI.

    • Secara Manual Atur CN/SAN untuk Validasi: Gunakan API validasi sertifikat yang disediakan oleh pustaka jaringan, seperti HostnameVerifier. Secara eksplisit lewati nama domain asli selama fase validasi TLS untuk memastikan perbandingan CN/SAN benar.

    • Secara Manual Atur Header Host: Gunakan API yang disediakan oleh pustaka jaringan untuk secara eksplisit mengatur Host: [nama domain asli]. Ini mencegah alamat IP ditulis ke header Host secara default.

      Catatan

      Proxy HTTP mengikuti absolute-form dari HTTP/1.1 (untuk informasi lebih lanjut, lihat origin-form). Baris permintaan membawa URL lengkap. Ketika URL ditulis ulang menjadi alamat IP, proxy sering kali memperlakukan IP ini sebagai host nyata. Bahkan mungkin membuang header Host yang ditetapkan oleh klien saat mengirim permintaan ke server asal. Ini dapat menyebabkan server asal mengembalikan kesalahan 404, kesalahan sertifikat, atau menolak permintaan. Dalam kebanyakan kasus, nonaktifkan HTTPDNS dalam lingkungan proxy.

    Pustaka jaringan yang berbeda mengekstrak SNI, domain validasi sertifikat, dan header Host dari URL dengan cara yang berbeda. API untuk memulihkan informasi domain ini juga bervariasi. Anda perlu menentukan solusi koneksi IP langsung berdasarkan pustaka jaringan tertentu. Berikut adalah solusi adaptasi koneksi IP langsung yang disediakan oleh HTTPDNS:

    • Android HttpURLConnection: Menggunakan HostnameVerifier/SSLSocketFactory untuk menimpa logika verifikasi TLS dan metode setRequestProperty untuk secara eksplisit mengatur header Host. Untuk informasi lebih lanjut, lihat Praktik Terbaik Menggunakan HTTPDNS dengan HttpURLConnection di Android.

    • iOS NSURLSession: Di URLSession:task:didReceiveChallenge:, lampirkan nama domain untuk validasi sertifikat, dan atur header Host saat membangun permintaan. Untuk informasi lebih lanjut, lihat Menggunakan HTTPDNS dalam Skenario Asli di iOS.

    • Unity HttpWebRequest: Gunakan ServicePointManager.ServerCertificateValidationCallback untuk menentukan validasi nama domain, dan gunakan request.Host = nama domain asli untuk menulis ulang header Host. Untuk informasi lebih lanjut, lihat Praktik Terbaik Kerangka Kerja Unity.

    Catatan

    Untuk solusi stack jaringan lainnya atau koneksi IP langsung, silakan hubungi Dukungan Teknis.

    4. Kesimpulan

    Koneksi IP langsung adalah solusi perbaikan untuk skenario di mana Anda tidak dapat menyesuaikan DNS. Kuncinya adalah mencatat nama domain asli. Anda juga harus memastikan bahwa semantik nama domain digunakan untuk tiga area utama: validasi sertifikat, SNI, dan header Host. Dengan mengikuti prinsip-prinsip ini, Anda dapat menggunakan hasil resolusi dari HTTPDNS dengan aman bahkan di pustaka jaringan semi-terbuka.