IDNA và tên miền Unicode khi dùng proxy: A-label trước CONNECT

IDNA và tên miền Unicode khi dùng proxy là chuyện chuyển một tên miền có dấu như việtnam.vn thành dạng chỉ có chữ ASCII bắt đầu bằng xn--. Việc chuyển phải xong trước khi tên đó đi vào DNS, vào dòng lệnh gửi proxy và vào bắt tay TLS. Thư viện làm việc này khác nhau, và cùng một tên Unicode có thể ra hai tên ASCII khác nhau. ProxyVN chạy lab với mười tên miền thử, so ba cách mã hóa và gửi request qua proxy bằng requests, httpx, urllib và curl để xem proxy thực sự nhận được tên gì.

IDNA và tên miền Unicode khi dùng proxy: lớp nào quyết định hành vi

DNS, giao thức HTTP và trường SNI của TLS đều chỉ nhận tên miền bằng chữ ASCII. Tên miền tiếng Việt, tiếng Đức hay tiếng Nhật phải được chuyển sang dạng ASCII trước khi rời ứng dụng. Chuẩn quy định cách chuyển gọi là IDNA, viết tắt của Internationalized Domain Names in Applications.

U-label và A-label

RFC 5890 đặt tên cho hai dạng của cùng một nhãn. U-label là dạng Unicode người đọc thấy, ví dụ việtnam. A-label là dạng ASCII máy dùng, bắt đầu bằng tiền tố xn-- rồi tới chuỗi Punycode, ví dụ xn--vitnam-jk8b.

Một tên miền gồm nhiều nhãn ngăn bởi dấu chấm. Mỗi nhãn được chuyển riêng. Nhãn nào toàn chữ ASCII thì giữ nguyên. Tên việtnam.test thành xn--vitnam-jk8b.test, phần test không đổi.

Ai chuyển và chuyển ở đâu

Việc chuyển xảy ra trong ứng dụng, cụ thể là trong thư viện HTTP hoặc thư viện phân giải tên. Proxy không chuyển giúp. Proxy nhận chuỗi nào trong dòng request hoặc lệnh CONNECT thì dùng chuỗi đó để tra DNS.

Nếu ứng dụng gửi tên Unicode thẳng vào dòng lệnh, có ba khả năng: thư viện báo lỗi trước khi gửi, proxy từ chối vì dòng lệnh không hợp lệ, hoặc proxy tự xử lý theo cách riêng. Cả ba đều khó chẩn đoán nếu không biết bước chuyển nằm ở đâu.

Punycode làm gì

Punycode là cách viết một chuỗi Unicode bằng chữ cái, chữ số và dấu gạch ngang. Các ký tự ASCII trong nhãn được giữ nguyên ở đầu, theo sau là dấu gạch ngang và một đoạn mã hóa vị trí cùng giá trị của các ký tự còn lại. Với việtnam, phần vitnam được giữ, đoạn jk8b mã hóa chữ ệ và vị trí của nó.

Vì cách mã hóa này, hai tên chỉ khác một dấu như việtnam và viêtnam sẽ có phần đầu giống nhau và phần đuôi khác nhau. Nhìn A-label rất khó đoán ra tên gốc, nên mọi kiểm tra phải dùng thư viện giải mã chứ không dựa vào mắt.

Hai chuẩn cho cùng một việc

IDNA có hai thế hệ. IDNA2003 là chuẩn cũ, ánh xạ nhiều ký tự trước khi mã hóa, ví dụ ß thành ss, chữ hoa thành chữ thường. IDNA2008 là chuẩn mới, chặt hơn, giữ ß thành ký tự riêng và từ chối nhiều ký tự mà chuẩn cũ chấp nhận.

Tài liệu UTS 46 của Unicode định nghĩa một lớp ánh xạ để chuyển dần từ chuẩn cũ sang chuẩn mới, gồm bước hạ chữ hoa và chuẩn hóa ký tự trước khi áp IDNA2008. Trình duyệt hiện đại và nhiều thư viện dùng lớp này.

Cùng một tên Unicode, chuẩn cũ và chuẩn mới có thể cho ra hai A-label khác nhau, tức là hai tên miền khác nhau.

Tên miền tiếng Việt trong thực tế

Tên miền tiếng Việt có dấu dưới đuôi .vn được cấp từ nhiều năm, nhưng ít được dùng làm địa chỉ chính. Nhiều trang đăng ký tên có dấu để giữ thương hiệu rồi chuyển hướng về tên không dấu. Crawler vẫn gặp chúng trong liên kết, trong danh sách tên miền và trong dữ liệu đăng ký.

Ngoài tiếng Việt, crawler đi thị trường quốc tế gặp tên miền tiếng Trung, tiếng Nhật, tiếng Nga, tiếng Ả Rập nhiều hơn hẳn. Một số đuôi tên miền cấp quốc gia còn viết toàn bằng chữ bản địa. Xử lý IDNA đúng là điều kiện để crawler không bỏ sót hoặc nhân đôi các trang này.

Ranh giới với bài sửa lỗi tiếng Việt khi crawl

Bài sửa lỗi encoding tiếng Việt khi crawl xử lý chữ tiếng Việt trong nội dung HTML đã tải về, tức chuyện bảng mã của trang. Bài này chỉ xử lý tên miền trong URL, trước khi tải. Hai lớp Unicode này không liên quan nhau: trang có tên miền ASCII vẫn có thể lỗi font, trang có tên miền tiếng Việt vẫn có thể có nội dung đúng bảng mã.

Chuẩn hóa tên miền Unicode sang A-label trước DNS, CONNECT và TLS khi xét IDNA và tên miền Unicode khi dùng proxy

Phần này đi qua ba chỗ tên miền xuất hiện trong một request qua proxy và yêu cầu ở từng chỗ.

Chỗ thứ nhất: dòng request hoặc lệnh CONNECT

Với proxy HTTP và trang HTTP thường, ứng dụng gửi dòng request có URL đầy đủ, ví dụ GET http://xn--vitnam-jk8b.test/a HTTP/1.1. Với trang HTTPS, ứng dụng gửi CONNECT xn--vitnam-jk8b.test:443. Theo chuẩn HTTP, phần tên máy trong các dòng này phải là ASCII.

Proxy đọc tên trong dòng này để tra DNS và mở kết nối ra ngoài. Nếu nhận được A-label, proxy tra như mọi tên ASCII khác. Bài proxy tunnel là gì giải thích lệnh CONNECT.

Chỗ thứ hai: header Host

Header Host chứa tên miền của trang đích. Với trang HTTPS, header này đi trong đường hầm đã mã hóa, proxy không đọc được. Với trang HTTP, proxy có thể đọc và có proxy dùng Host thay cho tên trong dòng request. Header Host cũng phải là A-label.

Chỗ thứ ba: trường SNI trong TLS

Ba chỗ cần A-label

Khi bắt tay TLS với trang đích qua đường hầm, ứng dụng gửi tên trang trong trường SNI. Chuẩn TLS yêu cầu SNI là tên ASCII, tức A-label. Chứng chỉ của trang cũng ghi tên dạng A-label. Bài SNI là gì có chi tiết về trường này.

Nếu SNI và lệnh CONNECT dùng hai A-label khác nhau do hai thư viện mã hóa khác nhau, proxy sẽ mở đường tới một tên còn TLS xác minh một tên khác. Kết quả có thể là lỗi chứng chỉ không khớp tên, rất khó lần ra gốc.

Đường dẫn và tham số không dùng IDNA

IDNA chỉ áp cho phần tên máy. Đường dẫn và tham số trong URL có chữ tiếng Việt dùng cách mã hóa phần trăm theo UTF-8, ví dụ chữ ệ thành %E1%BB%87. Thư viện HTTP thường tự làm việc này. Trộn hai cách, ví dụ đưa Punycode vào đường dẫn hay mã hóa phần trăm tên máy, đều cho URL sai.

Khi crawler thu link từ trang web, tên máy có thể ở dạng Unicode và đường dẫn có thể ở dạng đã mã hóa hoặc chưa. Hàm chuẩn hóa nên xử lý hai phần riêng: tên máy qua IDNA, đường dẫn qua mã hóa phần trăm.

Quy tắc an toàn

Chuyển tên sang A-label một lần, ở một chỗ, bằng một thư viện, trước khi đưa vào bất kỳ đâu. Mọi chỗ khác dùng chuỗi A-label đã chuyển. Không để mỗi thành phần tự chuyển theo cách riêng.

Lưu tên miền trong cơ sở dữ liệu crawl theo dạng A-label, kèm cột U-label nếu cần hiển thị. Khi so trùng, so theo A-label. Như vậy việtnam.test và Việtnam.TEST không thành hai bản ghi khác nhau.

Thiết kế lab IDNA và tên miền Unicode khi dùng proxy: phiên bản và phép đo

Lab chạy ngày 29/10/2026 trên Windows 10, Python 3.12.10 với thư viện idna 3.20, requests 2.34.2, urllib3 2.8.0, httpx 0.28.1 và curl 8.13.0 bản đi kèm Windows có hỗ trợ IDN qua WinIDN.

Mười tên thử

Mười tên đều thuộc miền .test, miền dành riêng cho thử nghiệm, không trỏ tới máy thật. Danh sách gồm tên tiếng Việt thường, tên có chữ hoa, tên có chữ đ và hai tên tiếng Đức có ß. Phần còn lại là một chữ x trong vòng tròn, một A-label tự gõ, tên có é dựng sẵn, tên có dấu sắc tổ hợp tách rời và một biểu tượng cảm xúc.

Mỗi tên được chuyển bằng ba cách: bộ mã idna có sẵn trong Python, vốn theo IDNA2003; thư viện idna với IDNA2008 thuần; thư viện idna với IDNA2008 kèm lớp UTS 46.

Vì sao dùng miền .test

Miền .test được dành riêng cho thử nghiệm theo RFC 2606, không bao giờ trỏ tới máy thật trên Internet. Dùng miền này đảm bảo lab không vô tình gửi request tới tên miền của ai đó. Đây là điều quan trọng khi thử các tên dễ gõ nhầm.

Nhược điểm là không thử được bước tra DNS thật. Phần này được bù bằng proxy lab tự phân giải mọi tên .test về máy lab, đủ để kiểm tên nào đi tới proxy.

Proxy lab

Proxy HTTP lab chạy ở 127.0.0.1 cổng 9572, yêu cầu Basic auth, ghi log dòng request nhận được. Proxy này phân giải mọi tên kết thúc bằng .test về 127.0.0.1, nơi có trang đích lab ở cổng 9574. Nhờ vậy request với tên giả vẫn đi trọn đường.

Bốn công cụ gửi request qua proxy: requests với ba URL, httpx với hai URL, urllib.request của thư viện chuẩn với hai URL, curl với một URL. Log proxy cho biết mỗi công cụ đã gửi tên gì.

Kết quả kỳ vọng

Tên tiếng Việt thường cho cùng một A-label ở cả ba cách. Tên có ß cho kết quả khác nhau giữa IDNA2003 và IDNA2008. Tên chữ hoa bị IDNA2008 thuần từ chối. Proxy chỉ nhận A-label.

Tái lập IDNA và tên miền Unicode khi dùng proxy: luồng đúng và luồng lỗi có kiểm soát

Phần này đưa số liệu thật. Bảng đầu là kết quả chuyển tên, bảng sau là những gì proxy nhận được.

Bảng chuyển mười tên

Bảng: Bảng chuyển mười tên

Tên đầu vào	Bộ mã Python, IDNA2003	IDNA2008 thuần	IDNA2008 kèm UTS 46
việtnam.test	xn--vitnam-jk8b.test	xn--vitnam-jk8b.test	xn--vitnam-jk8b.test
Việtnam.TEST	xn--vitnam-jk8b.TEST	Lỗi: chữ V không được phép	xn--vitnam-jk8b.test
đặtphòng.test	xn--tphng-wta7sy26t.test	xn--tphng-wta7sy26t.test	xn--tphng-wta7sy26t.test
faß.test	fass.test	xn--fa-hia.test	xn--fa-hia.test
straße.test	strasse.test	xn--strae-oqa.test	xn--strae-oqa.test
ⓧ.test	x.test	Lỗi: ký tự không được phép	x.test
café.test	xn--caf-dma.test	xn--caf-dma.test	xn--caf-dma.test
a cộng dấu sắc tổ hợp, b	xn--b-tfa.test	Lỗi: chưa chuẩn hóa NFC	xn--b-tfa.test
😀.test	xn--e28h.test	Lỗi: ký tự không được phép	Lỗi: ký tự không được phép

Tên tiếng Việt viết thường cho cùng kết quả ở cả ba cách. Đây là tin tốt: phần lớn tên miền tiếng Việt không bị lệch giữa các thư viện, miễn là đã viết thường và đã chuẩn hóa.

Ca lệch nguy hiểm: ß

Một tên, hai kết quả

Tên faß.test cho fass.test theo IDNA2003 và xn--fa-hia.test theo IDNA2008. Đây là hai tên miền khác nhau, có thể thuộc hai chủ khác nhau. Ứng dụng dùng bộ mã cũ của Python sẽ kết nối tới fass, ứng dụng dùng thư viện idna hay trình duyệt mới sẽ kết nối tới xn--fa-hia.

Với tên miền tiếng Việt không có ký tự này, rủi ro thấp. Nhưng crawler đi nhiều nước, gặp tên tiếng Đức hay tiếng Hy Lạp, sẽ gặp ca lệch thật. Biết thư viện nào dùng chuẩn nào là đủ để tránh.

Ca bị từ chối: chữ hoa và dấu tổ hợp

IDNA2008 thuần từ chối Việtnam.TEST vì chữ hoa không nằm trong tập ký tự được phép. Lớp UTS 46 hạ chữ hoa trước nên chấp nhận và cho ra đúng A-label của dạng chữ thường. Bộ mã cũ của Python giữ nguyên TEST viết hoa ở nhãn ASCII, vẫn dùng được vì DNS không phân biệt hoa thường với chữ ASCII.

Tên có dấu sắc gõ tách rời khỏi chữ a, tức chữ a rồi ký tự dấu tổ hợp U+0301, bị IDNA2008 thuần từ chối vì chưa ở dạng chuẩn NFC. Dữ liệu cào từ trang web hoặc gõ bằng một số bộ gõ tiếng Việt có thể ở dạng tổ hợp như vậy. Lớp UTS 46 chuẩn hóa trước nên chấp nhận.

A-label tự gõ sai

Lab có một A-label ProxyVN tự gõ là xn--vitnam-3ya.test, định làm dạng mã hóa của việtnam. Giải mã ngược lại cho ra vüitnam.test, một tên khác hẳn. A-label đúng của việtnam là xn--vitnam-jk8b.

Bài học rất cụ thể: không bao giờ tự gõ hay tự đoán A-label. Luôn sinh bằng thư viện rồi giải mã ngược để kiểm. Một ký tự sai trong chuỗi Punycode cho ra tên miền khác mà không báo lỗi gì.

Thư viện nào theo chuẩn nào

Từ hai bảng của lab, có thể xếp công cụ theo chuẩn. Bộ mã idna có sẵn của Python theo IDNA2003. Thư viện idna trên PyPI theo IDNA2008, có tùy chọn UTS 46. requests và httpx dựa trên thư viện idna, nên cho kết quả IDNA2008. curl trên Windows dựa trên WinIDN của hệ điều hành và cho cùng kết quả với tên tiếng Việt.

urllib.request không tự chuyển khi đi qua proxy. Khi đi thẳng không qua proxy, http.client của Python sẽ chuyển tên bằng bộ mã cũ ở bước tra địa chỉ, nhưng ProxyVN chưa thử ca này trong lab. Cách an toàn là không để urllib tự xử lý tên Unicode.

Proxy nhận được gì

Proxy nhận gì

Bảng: Proxy nhận được gì

Công cụ	URL gửi	Proxy nhận	Kết quả
requests	http://việtnam.test:9574/a	http://xn--vitnam-jk8b.test:9574/a	200
requests	http://faß.test:9574/b	http://xn--fa-hia.test:9574/b	200
requests	A-label tự gõ sai	http://xn--vitnam-3ya.test:9574/c	200
httpx	http://faß.test:9574/h1	http://xn--fa-hia.test:9574/h1	200
httpx	http://việtnam.test:9574/h2	http://xn--vitnam-jk8b.test:9574/h2	200
urllib.request	http://faß.test:9574/u1	Không gửi	UnicodeEncodeError
urllib.request	http://việtnam.test:9574/u2	Không gửi	UnicodeEncodeError
curl	http://việtnam.test:9574/d	http://xn--vitnam-jk8b.test:9574/d	200

requests, httpx và curl đều chuyển sang A-label trước khi gửi proxy. Cả ba cho faß ra xn--fa-hia, tức theo IDNA2008. Không công cụ nào trong ba gửi tên Unicode thô tới proxy.

urllib.request khi đi qua proxy đặt nguyên URL Unicode vào dòng request và báo lỗi không mã hóa được sang ASCII. Request không được gửi. Ứng dụng dùng urllib phải tự chuyển tên sang A-label trước.

Request với A-label tự gõ sai vẫn ra 200, vì proxy lab phân giải mọi tên .test về cùng một máy. Trên Internet thật, request này sẽ đi tới vüitnam hoặc báo không tìm thấy tên miền. Proxy không biết tên anh em định gõ, nó chỉ đi tới tên anh em đã gửi.

Đọc log, gói tin và response để tách lỗi IDNA và tên miền Unicode khi dùng proxy

Lỗi tên miền Unicode hiện ra ở nhiều dạng. Phần này xếp các dạng thường gặp và nơi cần nhìn.

Bảng triệu chứng

Bảng: Bảng triệu chứng

Triệu chứng	Lớp gây lỗi	Cách kiểm
UnicodeEncodeError trước khi gửi	Thư viện không tự chuyển IDNA	Chuyển tay sang A-label
Proxy trả 400 Bad Request	Dòng request chứa ký tự không phải ASCII	Đọc log proxy
Proxy trả 502 hoặc lỗi DNS	A-label sai hoặc tên không tồn tại	Giải mã ngược A-label
Lỗi chứng chỉ không khớp tên	SNI và CONNECT dùng hai tên khác nhau	So tên trong CONNECT với SNI
Kết nối tới trang lạ	IDNA2003 và IDNA2008 cho hai tên khác nhau	Thử cả hai chuẩn
Hai bản ghi trùng trong cơ sở dữ liệu	Lưu tên chưa chuẩn hóa	Lưu A-label viết thường

Dòng đầu là ca urllib trong lab. Dòng thứ ba là ca A-label tự gõ sai. Dòng cuối là lỗi dữ liệu chứ không phải lỗi mạng, nhưng hay gặp nhất trong crawler.

Đọc log proxy

Log proxy là chỗ đáng tin nhất để biết tên nào thật sự được gửi. Trong lab, mọi dòng log đều có trường target chứa A-label. Nếu log proxy của anh em ghi chuỗi có ký tự lạ hoặc dấu hỏi, ứng dụng đã gửi tên chưa chuyển.

Với proxy thương mại không xem được log, có thể dựng một proxy lab tạm trên máy như ProxyVN làm, trỏ ứng dụng vào đó để xem dòng request. Bài định dạng proxy giúp đổi cấu hình qua lại nhanh.

Kiểm A-label bằng giải mã ngược

Mọi A-label trong danh sách crawl nên qua bước giải mã ngược bằng thư viện idna. Nếu giải mã báo lỗi, A-label không hợp lệ. Nếu giải mã ra tên khác tên dự định, A-label bị gõ sai. Bước này mất vài mili giây cho mỗi tên.

Trong lab, chuỗi xn--ttphng-5ya3c4k.test cũng là một A-label ProxyVN tự gõ, giải mã báo lỗi ký tự không được phép. Chuỗi đúng của đặtphòng là xn--tphng-wta7sy26t, do thư viện sinh ra.

Tên miền nhìn giống nhau

Unicode có nhiều ký tự trông giống chữ Latin, như chữ a của bảng chữ Cyrillic. Tên miền dùng các ký tự này có thể trông y hệt một tên quen thuộc nhưng có A-label khác hẳn. Đây là kiểu lừa đảo dựa trên hình dạng chữ.

Với crawler, rủi ro là lưu nhầm hai tên khác nhau như một, hoặc tin một liên kết trỏ tới trang thật trong khi nó trỏ tới trang giả. Lưu A-label giúp phát hiện: hai tên trông giống nhau sẽ có A-label khác nhau. Trình duyệt hiện A-label thay cho U-label khi phát hiện trộn bảng chữ đáng ngờ.

Đọc lỗi DNS

Khi proxy báo không phân giải được tên, đầu tiên giải mã A-label để chắc tên đúng. Sau đó tra DNS cho A-label từ máy anh em. Nếu máy anh em tra được mà proxy không tra được, có thể proxy dùng DNS khác. Bài DNS_PROBE_FINISHED_NXDOMAIN có cách xử lý lỗi không tìm thấy tên miền.

Lưu ý khi tra tay: lệnh tra DNS trên một số hệ điều hành không tự chuyển tên Unicode. Trong lab, getaddrinfo của Windows với tên faß.test báo lỗi tra cứu chứ không chuyển giúp. Luôn tra bằng A-label.

Xử lý IDNA và tên miền Unicode khi dùng proxy theo bằng chứng và checklist

Checklist IDNA

Phần này gom cách làm cụ thể cho crawler và ứng dụng gọi qua proxy.

Một hàm chuẩn hóa duy nhất

import idna
from urllib.parse import urlsplit, urlunsplit
 
def chuan_hoa(url):
    p = urlsplit(url)
    host = idna.encode(p.hostname, uts46=True).decode()
    netloc = host + (f":{p.port}" if p.port else "")
    return urlunsplit((p.scheme, netloc, p.path or "/", p.query, ""))
 
print(chuan_hoa("http://Việtnam.TEST:9574/a"))

Hàm dùng thư viện idna với lớp UTS 46, hạ chữ hoa và chuẩn hóa dấu trước khi mã hóa. Kết quả là URL chỉ có ASCII ở phần tên máy, dùng được với mọi thư viện HTTP. Hàm bỏ phần thông tin đăng nhập trong URL nếu có, vì crawler không nên lưu chúng.

Mọi URL trước khi vào hàng đợi crawl đi qua hàm này. Khi so trùng, so URL đã chuẩn hóa. Khi ghi log, ghi URL đã chuẩn hóa, có thể kèm U-label để người đọc dễ hiểu.

Chọn chuẩn rõ ràng

Không dùng bộ mã idna có sẵn của Python cho tên miền mới, vì nó theo IDNA2003. Tài liệu codecs của Python ghi rõ bộ mã này cài đặt RFC 3490, chuẩn cũ. Thư viện idna trên PyPI theo IDNA2008 và là thứ requests, httpx đang dùng.

Nếu crawler phải tương thích với hệ thống cũ dùng IDNA2003, ghi rõ điều đó và kiểm các tên có ß, ς hay ký tự có biến thể trước khi gửi.

Hiển thị cho người đọc

Báo cáo crawl gửi cho người đọc nên hiện U-label, vì xn--vitnam-jk8b không ai đọc được. Dùng idna.decode cho từng tên khi xuất báo cáo. Nếu giải mã lỗi, hiện nguyên A-label kèm ghi chú, đừng bỏ qua.

Trong log kỹ thuật, ghi A-label để khớp với log proxy và log DNS. Hai loại log dùng hai dạng khác nhau là bình thường, miễn có quy ước rõ.

urllib và thư viện tự viết

Với urllib.request, chuyển URL bằng hàm chuẩn hóa trước khi mở. Với thư viện socket tự viết, chuyển tên trước khi gọi getaddrinfo và trước khi đặt server_hostname cho TLS. Đây là hai chỗ dễ quên nhất.

Proxy SOCKS5

Trước khi đổi sang SOCKS5, kiểm thư viện đang dùng có tự chuyển tên khi gửi qua SOCKS hay không. Hành vi có thể khác với khi đi qua proxy HTTP, vì đường mã xử lý hai loại proxy thường tách riêng.

Với SOCKS5 kiểu socks5h, tên trang đích được gửi sang proxy trong gói bắt tay. Chuẩn SOCKS5 cho phép tên miền dạng chuỗi byte, nhưng proxy thường mong ASCII. Luôn gửi A-label. Với kiểu socks5 không có h, ứng dụng tự tra DNS, nên cần A-label cho getaddrinfo.

Kiểm dữ liệu cũ

Nếu cơ sở dữ liệu crawl đã có sẵn nhiều tên miền lưu dạng U-label hoặc lẫn lộn hai dạng, chạy một lượt chuyển toàn bộ sang A-label viết thường. Ghi lại các tên bị từ chối khi chuyển, đó thường là dữ liệu bẩn: khoảng trắng thừa, ký tự điều khiển, tên bị cắt giữa chừng.

Sau khi chuyển, đếm lại số tên khác nhau. Nếu con số giảm, nghĩa là trước đó đã có bản ghi trùng do khác dạng viết. Lab cho thấy chỉ riêng chữ hoa và dấu tổ hợp đã đủ để một tên thành hai hoặc ba bản ghi.

Lượt chuyển này nên chạy một lần rồi thêm kiểm tra vào bước nhập dữ liệu mới, để dữ liệu không bẩn lại.

Giới hạn suy luận của bài

Lab dùng miền .test và proxy lab tự phân giải, không tra DNS thật, không kết nối tới tên miền IDN thật. Phần SNI và chứng chỉ lấy theo chuẩn, chưa thử bắt tay TLS với tên IDN. Hành vi của từng thư viện ghi theo phiên bản ngày 29/10/2026.

curl trên Windows dùng WinIDN của hệ điều hành. Bản curl trên Linux dùng libidn2, có thể cho kết quả khác ở các ca biên. Trình duyệt chưa được thử trong bài.

Checklist IDNA và tên miền Unicode khi dùng proxy

• Chuẩn hóa mọi URL bằng một hàm duy nhất trước khi crawl.
• Dùng thư viện idna với UTS 46, không dùng bộ mã IDNA2003 của Python.
• Lưu và so trùng theo A-label viết thường.
• Không tự gõ A-label, luôn sinh bằng thư viện và giải mã ngược để kiểm.
• Với urllib và mã socket tự viết, chuyển tên tay trước khi gửi.
• Kiểm log proxy để chắc proxy nhận A-label.
• Tra DNS thủ công bằng A-label.
• Cẩn thận với ký tự có biến thể như ß giữa hai chuẩn.

Khi crawler đã chuẩn hóa tên miền đúng, phần còn lại là đường đi ổn định qua proxy. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5; anh em có thể mua proxy giá rẻ tại trang chủ ProxyVN để chạy các trang có tên miền tiếng Việt.

Câu hỏi thường gặp về IDNA và tên miền Unicode khi dùng proxy

Tên miền .vn tiếng Việt có dùng được với proxy không?

Được, miễn ứng dụng chuyển sang A-label trước. Proxy xử lý A-label như tên ASCII thông thường.

Có cần lo nếu chỉ crawl tên miền ASCII?

Không cần lo phần chuyển tên. Nhưng URL thu từ trang web có thể chứa tên Unicode trong liên kết, nên hàm chuẩn hóa vẫn nên có.

Trình duyệt hiện tên Unicode, crawler lưu A-label, có sao không?

Không sao. Đó là hai dạng của cùng một tên. Lưu A-label để so trùng, hiển thị U-label cho người đọc.

Proxy có cần cấu hình gì cho tên miền Unicode không?

Không. Proxy chỉ cần nhận A-label, việc này do ứng dụng lo. Proxy tự viết cũng nên từ chối dòng request có ký tự ngoài ASCII thay vì đoán cách xử lý.

Vì sao Việtnam viết hoa vẫn ra cùng A-label?

Lớp UTS 46 hạ chữ hoa trước khi mã hóa. Tên miền không phân biệt hoa thường, nên đây là hành vi đúng.

A-label có phân biệt chữ hoa không?

Không. XN--VITNAM-JK8B và xn--vitnam-jk8b là cùng một tên. Nhưng nên lưu thống nhất bằng chữ thường để so chuỗi trực tiếp, khỏi phải gọi hàm so không phân biệt hoa thường ở mọi chỗ trong mã.

Tên miền có biểu tượng cảm xúc có dùng được không?

IDNA2008 không cho phép. Một số nhà đăng ký tên miền vẫn bán tên như vậy dưới một số đuôi, nhưng nhiều thư viện sẽ từ chối, như lab cho thấy.

IDNA và tên miền Unicode khi dùng proxy và những điều cần nhớ

IDNA và tên miền Unicode khi dùng proxy là việc của ứng dụng, proxy chỉ đi tới đúng tên ASCII nó nhận. Lab cho thấy requests, httpx và curl tự chuyển sang A-label, urllib qua proxy báo lỗi, còn ß cho hai tên khác nhau giữa chuẩn cũ và mới. Chuẩn hóa một lần bằng thư viện idna, lưu A-label, kiểm log proxy. Cần proxy ổn định khi xử lý IDNA và tên miền Unicode khi dùng proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.