After switching to my own Mihomo override rules, my phone kept spinning when downloading apps from Google Play, but using the rules from the VPN service worked fine, which was very strange. So, I checked the Mihomo kernel logs.

1
2
3
4
5

play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using Static Resources[🇭🇰 Hong Kong 07]
play.googleapis.com:443 match GeoSite(GFW) using Node Selection[🇭🇰 Hong Kong 07]
play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using Static Resources[🇭🇰 Hong Kong 07]
play-fe.googleapis.com:443 match GeoSite(GFW) using Node Selection[🇭🇰 Hong Kong 07]
services.googleapis.cn:443 match GeoSite(CN) using Direct Connection[DIRECT]

(The above logs have been simplified.)

The Google Play services pre-installed on Chinese smartphones use the domain services.googleapis.cn instead of services.googleapis.com, and this domain is set to direct connection in most traffic routing rules. Yes, that’s where the problem lies. Modifying the rules to route this domain through a proxy solves the issue!

…Or does it?

1
2
3

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using Leakage[🇭🇰 Hong Kong 07]
rr2---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using Leakage[🇭🇰 Hong Kong 07]
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com:443 match Match using Leakage[🇭🇰 Hong Kong 07]

Wait, why do these strange domains appear every time I download an app from the Play Store? After some research online, a new world opened up.

Ångströ: The Opposite Yet Similar Counterpart to Google

Seeing xn--ngstr-lra8j.com, those familiar with domain names will know that this is PunyCode encoding, which decodes to ångströ.com. Anders Jonas Ångström was a Swedish physicist and a pioneer in spectroscopy.¹ The ångström (Å) is a unit of length named in his honour, where $ 1 Å = 10^{-10} m = \frac{1}{10} nm $. It is commonly used to describe very short distances, such as atomic and molecular sizes or the wavelength of light. It represents an extremely small scale, especially in physics and chemistry for fine measurements.

Although Google’s name is not directly derived from “Googol,” it was inspired by the term. “Googol” is a mathematical term representing $10^{100}$, a 1 followed by 100 zeros, an extremely large number often used to denote vast quantities in computer science.

In terms of naming philosophy, Google and Ångströ, two seemingly opposite technological concepts, exhibit a fascinating symmetry. The former originates from the creative adaptation of the mathematical term “Googol,” while the latter stems from the reimagining of the physical unit “Ångström.” These artistically transformed names resemble the double helix of technological civilization: Google embodies the ambition to navigate the vast digital universe, while Ångströ hints at the meticulous crafting of atomic-scale technological landscapes. When these creatively altered professional terms meet in Silicon Valley, they form a perfect cognitive coordinate system—pointing to the limits of human information processing while heralding the grand journey of technological civilization towards both the macro and micro scales.

Introduction to Cryptography: The Patterns of Google’s Infrastructure Domains²

OK, enough. Now let’s turn our attention back to Google’s infrastructure. First, let’s look at some complete connection domains:

1
2
3

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com
rr5---sn-i3b7knzs.xn--ngstr-lra8j.com

These seemingly random strings are actually the result of some simple cryptographic encryption. Let’s break down the core components.

City Name Conversion Rules

Taking rr1---sn-j5o76n7z as an example, the key information segment is the 8 characters after sn-: r1---sn-[123][45][6][78]. The first three characters, in this case j5o, represent the city name, derived from the IATA code of the city’s main airport through a cryptographic transformation.

First, construct a 5 * 7 alphanumeric table:

1
2
3
4
5
6
7

Row0: 1 0 2 3 4
Row1: 5 6 7 8 9
Row2: a b c d e
Row3: f g h i j
Row4: k l m n o
Row5: p q r s t
Row6: u v w x y

Rotate this table counterclockwise, starting from the bottom-left corner of the new table, and copy the data from the original table in the order “left to right, top to bottom” into the new table in the order “bottom to top, left to right.”

After rotation, we get the following table:

1
2
3
4
5
6
7
8
9

| 6 d k r y |
| --------- |
| 5 c j q x |
| 4 b i p w |
| 3 a h o v |
| 2 9 g n u |
| 0 8 f m t |
| --------- |
| 1 7 e l s | 

The 5*5 section in the middle of the table, enclosed by lines, is the final cipher table, containing 25 characters representing letters a to y in order from left to right, top to bottom. For example, the IATA code for Shanghai Hongqiao International Airport is sha. We can use this table to get the encrypted ciphertext:

• s is the 19th letter in the alphabet. Counting from left to right, top to bottom in the cipher table, the 19th character is n.
• h is the 8th letter in the alphabet. Counting from left to right, top to bottom in the cipher table, the 8th character is i.
• a is the 1st letter in the alphabet. Counting from left to right, top to bottom in the cipher table, the 1st character is 5.

The encrypted ciphertext is ni5.

Conversely, going back to the original city name j5o, we can reverse-engineer the plaintext from the cipher table:

• j is the 3rd character in the cipher table, which corresponds to c.
• 5 is the 1st character in the cipher table, which corresponds to a.
• o is the 14th letter in the alphabet, which corresponds to n.

The decrypted plaintext is can, which is the IATA code for Guangzhou Baiyun International Airport. Clearly, the server we connected to is located in Guangzhou.

What if Google had a server in Zurich, and Zurich Airport’s IATA code is zrh, which includes the letter z? Our cipher table only goes up to y. Don’t worry, Google has considered this issue—z corresponds to 1 in the cipher table.

Here’s the code representation of these rules:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

table = "5cjqx4bipw3ahov29gnu08fmt1"
def iata2cipher(iata):
    global table
    iata = iata.upper()
    cipher = ""
    for element in iata:
        index = ord(element) - 65
        cipher += table[index]
    return cipher
  
def cipher2iata(cipher):
    global table
    cipher = cipher.lower()
    iata = ""
    for element in cipher:
        index = table.find(element)
        iata += chr(65 + index)
    return iata
  
# print(iata2cipher(input("IATA:")))
# print(cipher2iata(input("Cipher:")))

Server Group Number

The [45] and [78] positions, such as 76 and 7z, represent the server group (access point) number, composed of characters from the first column of the following table (separated by a line). The characters 7elsz6dkry represent 0123456789. Therefore, 76 translates to 05, and 7z translates to 04.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

  | 1 2 3 4 5 6
7 | 8 9 a b c d
e | f g h i j k
l | m n o p q r
s | t u v w x y
z | 0 1 2 3 4 5
6 | 7 8 9 a b c
d | e f g h i j
k | l m n o p q
r | s t u v w x
y | z

Here’s the Python representation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

codeTable = "7elsz6dkry"
def cipher2code(cipher):
    global codeTable
    cipher = cipher.lower()
    codeString = ""
    for element in cipher:
        index = codeTable.find(element)
        codeString += chr(index + 48)
    return codeString

# print(cipher2code(input("Cipher:")))

Similarly, encrypting numbers into ciphertext follows the same logic, which we won’t elaborate on here.

Supported Protocols

The [6] position indicates network protocol information:

• n: IPv6 (address range 0x000-0x3FF)
• u: IPv6 (address range 0x400-0x7FF)
• m: IPv4 only

For example:

• a5mekn7r, IPv6 prefix: 2607:f8b0:4007:a::/64, IPv4 prefix: 74.125.103.0/24
• a5m7zu7r, IPv6 prefix: 2607:f8b0:4007:407::/64, IPv4 prefix: 74.125.215.0/24
• a5mekm76, IPv4 only, prefix: 208.117.242.0/24

Correct Traffic Routing

Understanding the cryptographic patterns of Google’s infrastructure domains allows us to implement more precise traffic routing strategies. Currently, it’s known that Google’s CDN nodes in China are mainly located in Beijing (2x3), Shanghai (ni5), and Guangzhou (j5o). The corresponding domain characteristics can be identified using regular expressions:

1
2

rules:
  - DOMAIN-REGEX,^r+[0-9]+(---|\.)sn-(2x3|ni5|j5o)\w{5}\.xn--ngstr-lra8j\.com$,DIRECT

This rule will match all domains like rr1---sn-j5o76n7z.xn--ngstr-lra8j.com that belong to domestic CDNs and mark them for direct connection. For other Google domains not covered (such as play.googleapis.com), the original proxy rules will still apply.

In fact, the upstream GeoSite database v2fly/domain-list-community has already optimised the rules for Google Play’s domestic CDN nodes³. Simply enabling the GEOSITE,GOOGLE-PLAY@CN rule in Mihomo’s configuration will automatically implement intelligent traffic routing for domestic CDN direct connections and overseas domain proxies:

1
2
3

rules:
  - GEOSITE,GOOGLE-PLAY@CN,Direct Connection
  - GEOSITE,GOOGLE,Proxy Selection