![[Figure 1: Material Icons on the Google Analytics page failed to render correctly, and icon names are displayed as plain text]](https://media.shuijingwanwq.com/2026/09/1-13.png)
Recently, while using Google Analytics, I encountered an issue that initially seemed strange.
The pages loaded normally and the statistics displayed correctly, but many elements that should have appeared as icons showed up as plain text instead, such as:
arrow_drop_down
check_circleAt first, I suspected issues with Google Analytics itself, browser caching, or even the server.
After further investigation, I found that the problem was ultimately not with Google Analytics or the web server, but rather related to my current setup:
Clash Verge
+
Mihomo
+
Wstunnel
+
WireGuardSpecifically, there was an inconsistency between the DNS resolution location and the actual remote exit location within this network path.
Ultimately, I made a single small adjustment to the existing MetaCubeX v4 configuration:
remote-dns-resolve: true
dns:
- 1.1.1.1
- 8.8.8.8The issue immediately returned to normal.
This adjustment also resulted in the new:
MetaCubeX Minimalist Stable Edition v51. Google Analytics page anomalies first appear
The first issue I noticed was in Google Analytics.
The page itself loaded and the data displayed normally, but many icons turned into plain text.
For example, the following appeared directly on the page:
arrow_drop_down
check_circleNormally, these should be rendered as corresponding icons via the Material Icons font.
![[Figure 1: Material Icons on the Google Analytics page failed to render correctly, and icon names are displayed as plain text]](https://media.shuijingwanwq.com/2026/09/1-13-1024x498.png)
Therefore, the problem could quickly be narrowed down to:
The main page loads, but certain fonts or static resources used by Google Analytics fail to load.
2. Firefox Network shows Google Fonts requests failing
Next, I opened the Firefox Developer Tools:
F12
→ NetworkFiltered by:
fontImmediately, I could see multiple:
fonts.googleapis.comrequests failing.
The error was:
NS_ERROR_NET_RESETAnd the transferred size for all of them was:
0 bytes![[Figure 2: Multiple fonts.googleapis.com requests show NS_ERROR_NET_RESET in Firefox Network]](https://media.shuijingwanwq.com/2026/09/2-13-1024x498.png)
At this point, it was basically confirmed that:
The Google Analytics page itself is not broken; the real issue is that Google Fonts-related resources failed to load.
Because resources like Material Icons, Google Sans, and Roboto all depend on these requests, once the font CSS fails to load, the icon names may be displayed directly as plain text.
3. Clash logs prove Google traffic has hit the correct rule
Next, I checked the Clash Verge logs and searched for:
fonts.googleapis.comThe logs continuously showed:
[TCP] dial Proxy (match GeoSite/google)
127.0.0.1:xxxxx --> fonts.googleapis.com:443
error: context deadline exceeded![[Figure 3: Clash Verge has matched Proxy via GeoSite/google, but the connection to fonts.googleapis.com:443 keeps timing out]](https://media.shuijingwanwq.com/2026/09/3-15.png)
This is very important.
Because it proves that the:
GEOSITE,google,Proxyrule was actually matched correctly.
In other words, the problem this time was not that:
fonts.googleapis.com failed to match the Google rulebut rather:
Proxy has been matched
↓
but the connection to the target address times outSo continuing to adjust the Google rule order was no longer the main troubleshooting direction.
4. US server accesses Google Fonts normally
Since I maintain the WireGuard server in this environment myself, the next step was to log directly into the remote server for testing.
I executed:
curl -4 -I --connect-timeout 10 \
'https://fonts.googleapis.com/css2?family=Roboto'It returned normally:
HTTP/2 200Then I tested:
curl -4 -I --connect-timeout 10 https://www.google.com/It also returned:
HTTP/2 200![[Figure 4: The US server accesses fonts.googleapis.com and Google normally via IPv4]](https://media.shuijingwanwq.com/2026/09/4-10-1024x484.png)
At the time, the IPv6 test failed:
curl: (7) Couldn't connect to serverI initially considered whether IPv6 was involved in this anomaly.
However, subsequent testing proved that it was not the core cause of the problem.
The truly valuable conclusion was:
The US server itself can access Google Fonts perfectly fine via IPv4.
Therefore, we can rule out:
Google Fonts being entirely inaccessibleand:
an overall IPv4 network anomaly between the server and Google5. The remote server resolved a normal, accessible Google IP
Continuing on the server, I executed:
getent ahostsv4 fonts.googleapis.comThe resolution result at the time was:
142.251.40.106![[Figure 5: The US server resolves fonts.googleapis.com to 142.251.40.106]](https://media.shuijingwanwq.com/2026/09/5-9.png)
This address is accessible from the server.
Later, I also forced:
fonts.googleapis.comon my local machine via Clash to connect to this IP.
The result was that both the TLS handshake and the HTTP request succeeded:
TLSv1.3
HTTP/2 200This step was crucial.
Because it still used the same set of:
Clash
→ Wstunnel
→ WireGuard
→ US servernetwork path.
The only thing that changed was:
explicitly specifying the target IP.
And the request returned to normal.
Therefore, the likelihood of issues with WireGuard, Wstunnel, MTU, etc., had dropped significantly at this point.
What really needed to be confirmed next was:
When the IP is not manually specified, which target address does WireGuard actually connect to?
6. tcpdump captures another target address actually being accessed
To confirm this, I captured packets directly on the WireGuard server’s:
wg0interface.
I executed:
sudo tcpdump -ni wg0 -nn \
'tcp dst port 443 and tcp[tcpflags] & tcp-syn != 0'Then I re-accessed:
fonts.googleapis.comfrom the local machine.
The capture showed:
10.7.0.2:34156 > 120.232.233.161:443 Flags [S]Followed by continuous retries:
SYN
SYN
SYNBut no connection was ever established.
![[Figure 6: WireGuard server tcpdump captures the client actually connecting to 120.232.233.161:443 and continuously sending SYN]](https://media.shuijingwanwq.com/2026/09/6-5-1024x182.png)
This screenshot basically made the direction of the problem very clear.
The server itself resolves:
fonts.googleapis.com
↓
142.251.40.106and can access it normally.
However, when accessing the original domain through the current path, it actually connected to:
120.232.233.161And no connection was successfully established from the current remote exit to this address.
A more accurate understanding here is not simply to say:
DNS returned an incorrect IP.
Because GeoDNS, CDN, and regional scheduling can inherently return different addresses based on the query source.
The real problem is closer to:
The network environment where DNS resolution occurs is inconsistent with the network exit that ultimately makes the HTTPS request.
7. DNS resolution location is inconsistent with the actual network exit
The original access logic was actually close to:
Local network environment
↓
Resolves fonts.googleapis.com
↓
Obtains a target address
↓
Mihomo determines that this traffic needs to go through the remote path
↓
WireGuard
↓
US server exit
↓
Accesses the previously resolved addressThere is a potential issue here.
The DNS query is performed in the:
Local network environmentWhile the final HTTPS request is sent from the:
US remote exitFor ordinary domains, this difference often does not cause a noticeable impact.
But for services using:
GeoDNS
CDN
Regional scheduling
Edge nodesthe DNS query source can sometimes affect the final target address obtained.
Thus, it is possible that:
The address returned by DNS is suitable for the local network environmentbut:
the actual request is sent from a network exit in another regionultimately causing a connection anomaly.
This also explains why this configuration worked fine for a long time without any obvious issues.
Previously, even if DNS and the actual exit were not in the same location, as long as the resolved target address was still accessible from the remote server, this potential problem was completely unnoticeable.
This time:
fonts.googleapis.comhappened to expose this edge case.
8. Instead of adding special Google compatibility, enable WireGuard remote DNS
During troubleshooting, I initially considered another approach:
Specifically for:
geosite:googleadding a separate:
nameserver-policyto let Google domains use a separate overseas DNS.
This approach could handle the current problem.
However, after further checking Mihomo’s WireGuard configuration, I found a more direct and universal setting:
remote-dns-resolve: trueTherefore, I ultimately did not add new special DNS rules for Google.
Instead, I added the following to the WireGuard node:
remote-dns-resolve: true
dns:
- 1.1.1.1
- 8.8.8.8The complete addition is:
# 【关键】强制由 WireGuard 远端解析代理目标域名，避免本地 DNS 解析位置与实际出口位置不一致
remote-dns-resolve: true
# 远端 DNS：仅在 remote-dns-resolve: true 时用于代理目标域名解析
# 使用 Cloudflare DNS，并增加 Google DNS 作为兜底
dns:
- 1.1.1.1
- 8.8.8.8With this, the overall logic becomes:
Local machine
↓
Mihomo determines the domain needs to go through WireGuard
↓
WireGuard
↓
Target domain is resolved by the remote network environment
↓
Obtains a target address more suitable for the actual exit
↓
Establishes HTTPS connectionThe biggest difference from before is:
The local network environment no longer determines in advance which IP the remote traffic should ultimately access.
9. MetaCubeX v5 still adheres to minimal modifications
I did not redesign the entire DNS configuration this time.
v5 is still a minimal incremental version based on the previous v4.
I did not adjust:
MTU
Wstunnel structure
Other WireGuard parameters
Overall GEOSITE / GEOIP structure
Google routing rules
Existing fallback systemThe only core addition is:
remote-dns-resolve: true
dns:
- 1.1.1.1
- 8.8.8.8![[Figure 7: MetaCubeX v5 Git commit and the newly added WireGuard remote-dns-resolve configuration]](https://media.shuijingwanwq.com/2026/09/7-2.png)
This v5 update has been synced to GitHub:
shuijingwan/clash-configCorresponding Commit:
2448c55f800ea8d58b7b3562d341dae6c3d5a6d6Commit message:
feat: add WireGuard remote DNS resolutionThe repository continues to retain:
metacubex-v1.yaml
metacubex-v2.yaml
metacubex-v3.yaml
metacubex-v4.yaml
metacubex-v5.yamlTherefore, previous historical versions will not be affected.
10. Google Analytics returns to normal after the modification
After updating the configuration and reloading Mihomo, I executed again:
curl -v \
--proxy http://127.0.0.1:7897 \
--connect-timeout 10 \
'https://fonts.googleapis.com/css2?family=Roboto' \
-o /dev/nullIt now completes normally:
TLSv1.3
SSL certificate verified
HTTP/2 200Then I reopened Google Analytics.
The previously displayed:
arrow_drop_down
check_circleall reverted to normal icons.
In Firefox Network, the:
fonts.googleapis.comrelated requests all returned:
200The actual font files from:
fonts.gstatic.comalso all returned normally:
200![[Figure 8: After enabling WireGuard remote-dns-resolve, the Google Analytics page returns to normal, and all Google Fonts-related requests return 200]](https://media.shuijingwanwq.com/2026/09/8-1-1024x415.png)
At this point, a complete verification loop was formed for this issue.
11. This solution does not require the server to be located in the US
The actual server used this time is in the US.
But:
remote-dns-resolve: trueit does not depend on the server being in a specific country or region.
What really matters is:
The network environment where DNS resolution occurs should be kept as consistent as possible with the network exit that actually makes the requests.
Assuming the remote server is moved to another region in the future:
Local machine
↓
WireGuard
↓
New remote exit
↓
Target domain is resolved by the remote network environment
↓
Accesses a target address more suitable for the current exitThe logic still holds.
Therefore, compared to constantly adding separate DNS rules for specific services, this approach better aligns with my current principles for maintaining this configuration:
Address underlying consistency issues as much as possible, rather than continuously accumulating special compatibility rules for individual websites.
12. Lessons learned from this troubleshooting
On the surface, this problem was just:
Google Analytics icons displaying abnormallyBut after a complete investigation, the actual path was:
Google Analytics icon anomaly
↓
Firefox Network
↓
fonts.googleapis.com NS_ERROR_NET_RESET
↓
Clash logs
↓
GeoSite/google correctly matched to Proxy
↓
Remote server directly accesses Google Fonts normally
↓
Specifying the Google IP resolved by the remote server also works normally
↓
tcpdump
↓
Discovered WireGuard was actually connecting to another target address
↓
Confirmed a discrepancy between DNS resolution location and actual network exit
↓
WireGuard enables remote-dns-resolve
↓
Google Fonts returns HTTP/2 200
↓
Google Analytics fully returns to normalThere is another experience from this worth recording:
When encountering:
Website main body can open
+
Some resources continuously time out
+
Routing rules have been correctly matchedit is not necessarily the case that you should immediately suspect:
MTU
Browser cache
Web server
Overall remote server failureYou should also check an issue that is often easily overlooked:
Where the final target domain actually completes DNS resolution, and whether the network environment of the resolution is consistent with the actual request exit.
For services with GeoDNS, CDN, and regional scheduling capabilities, this is particularly worth noting.
13. Summary
MetaCubeX v4 has been relatively stable in previous practical use.
This upgrade to v5 was not because the original architecture needed to be redesigned, but because a new, real-world failure revealed that between:
Local DNS resolution
+
Remote network exitthere still exists a low-probability but genuinely possible edge case.
Ultimately, adding:
remote-dns-resolve: true
dns:
- 1.1.1.1
- 8.8.8.8allows WireGuard target domains to be resolved by the remote network environment.
This real-world test has resolved:
fonts.googleapis.com connection timeout
Google Analytics font loading failure
Material Icons displaying as plain textAt the same time, I did not redesign the entire DNS or routing system just for this one issue.
This configuration has now been organized into:
metacubex-v5.yamland synced to GitHub.
If I continue to encounter new real-world network issues in the future, I will still prioritize maintaining the current troubleshooting approach:
First confirm the real failure path, then make adjustments that are as minimal as possible while remaining universally applicable.
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan