2026-03-02 04:22:30
I finally replaced my old comment setup and moved everything to a new system built by myself.
The result is simple: my blog is now fully running on Cloudflare.
This post explains why I migrated from Artalk, what I built, and how the migration worked.
Artalk is a great project, and it worked well for me for a long time. I used it as a reference while redesigning my own system.
But I wanted tighter control over:
So instead of extending Artalk, I built a focused API-first comment service for my own use case.
The current architecture is intentionally minimal.
The frontend is custom, integrated into my Hugo theme, and styled to keep the previous reading experience close to what I had before.
No separate admin panel or heavy UI dependency in the backend. The Worker exposes clean endpoints for posting comments, listing comments, and stats.
Each comment keeps parent_id, root_id, and depth, and public listing supports page-based pagination.
AUTO_APPROVE controls default behavior:
AUTO_APPROVE=false: new comments are pendingAUTO_APPROVE=true: new comments are approved immediatelyIn both modes, Telegram notifications are sent.
Approve / Spam / Delete
Spam / Delete
Reserved admin emails are blocked from public submission, so regular users cannot pretend to be the site owner.
Avatar URLs are generated from email via Gravatar hash.
For network metadata, the system uses api.ipinfo.es and stores country, ASN, and related fields in D1. Country display uses full country name and a separate country code for flags.
API timestamps are normalized to include timezone offsets, so old imported comments and new comments use a consistent format.
I migrated historical comments from an Artalk export file (.artrans) into D1.
High-level process:
.artrans to D1-compatible SQL with a converter script.This gave me a smooth transition without losing old threads.
I wanted one platform for everything.
Now the entire blog stack is inside Cloudflare:
No extra VM, no extra database vendor, no mixed ops stack.
This system is built for my blog first, but the architecture is reusable.
The most important part for me is that I now control the full comment pipeline end to end: data model, moderation workflow, frontend behavior, and deployment.
Migrating from Artalk was straightforward once the converter and D1 migrations were in place.
2026-02-14 14:46:19
现在正在 湘南新宿ライン 的 Green Car，前段时间从「上野（御徒町）」去「房総半島」玩，奇怪的发现我来回支付的价格不一样，而且最关键的是完全违背常理。
其中在「錦糸町」出站，支付了 ¥167，之后从「錦糸町」入站直接到「富浦」出站，支付了 ¥1980，合计 ¥2147。
直接从「富浦」入站，到「御徒町」出站，支付了 ¥2310。
细心的朋友已经发现问题了。我连续计费从头坐到尾的价格竟然比出站之后重新入站更贵。也就是说你坐的路程越长，单价并不一定更低，这完全违背了基本常识。
这是一个非常经典的 JR 运费计算"Bug"（其实是由于运费区间的阶梯定价机制造成的）。
简单来说，你"出站再进站"的操作，正好让你避开了一个昂贵的运费跳档。
这里是具体的数学拆解：
1. 核心原因：运费的"阶梯"跳得太高了
JR 东日本的运费是按里程分段计价的。随着距离增加，每一段的价格会跳涨。你正好处于一个临界点上：
锦糸町 > 富浦 的距离大约是 118 km
御徒町 > 锦糸町 的距离大约是 4.4 km
2. 连续计费的陷阱
当你不出站，直接从 富浦 > 御徒町 时，里程是累加的：
3. 算一笔账
| 方式 | 价格计算 | 总价 |
|---|---|---|
| 分段买 | 1,980 (长途) + 167 (短途) | 2,147 日元 |
| 连续买 | 升级到下一档运费 | 2,310 日元 |
差价原因：
JR 的运费表里，从"101-120km"升级到"121-140km"这一档，价格一口气涨了 330 日元 (2,310 - 1,980)。
而你实际多坐的那段路（锦糸町-御徒町）单独买只需要 167 日元。
因为 330 > 167，所以被系统"自动升级"到下一档反而更贵，手动拆开反而便宜。这在 JR 的运费体系中属于一种已知现象，通常发生在长途旅行刚好卡在某个运费区间边缘，再多坐几公里就会触发"大额跳档"的时候。
2026-01-05 21:48:57
日本的 SAKURA Internet Inc. (AS9370) 即使在近些年大不如前，但仍然因为其 IP 质量（接近日本家庭宽带），再加上无限流量，备受玩家喜爱。当然这家的机子也并不好买，需要日本的真实地址，以及日本的手机号。
主播在大概半年之前注册了一个 SAKURA 和 WebARENA Indigo 帐号，一直在使用 SAKURA VPS，一直存在的问题就是从中国到日本根本跑不满限速的 100Mbps。因为存在国际 QoS 的问题。
这个方案也一样适用于 Indigo。简单来说，就是用一台主流的商宽 VPS (比如 GreenCloudVPS) 和 SAKURA 建立 GRE 隧道，然后将国际入站的流量先到 GreenCloudVPS，再从 GreenCloudVPS 的 GRE Tunnel 到 SAKURA，这样就能绕过 SAKURA 的国际 QoS 了。
玩 GRE Tunnel 的前提是你的云服务商没有禁用 Protocol 47。
在两个服务器上加载 GRE module：
sudo modprobe ip_gre
echo "ip_gre" | sudo tee -a /etc/modules
例如服务器 A 公网 IP：23.191.8.1，服务器 B 公网 IP：23.191.8.2。内网地址：10.0.0.1 和 10.0.0.2。
接下来在服务器 A 上添加一个 GRE 接口：
nano /etc/network/interfaces
auto tun-gre
iface tun-gre inet static
address 10.0.0.1
netmask 255.255.255.252
pre-up ip tunnel add tun-gre mode gre remote 23.191.8.2 local 23.191.8.1 ttl 255
post-up ip link set dev tun-gre mtu 1450
post-down ip tunnel del tun-gre
在服务器 B 上同样添加 GRE 接口：
nano /etc/network/interfaces
auto tun-gre
iface tun-gre inet static
address 10.0.0.2
netmask 255.255.255.252
pre-up ip tunnel add tun-gre mode gre remote 23.191.8.1 local 23.191.8.2 ttl 255
post-up ip link set dev tun-gre mtu 1450
post-down ip tunnel del tun-gre
测试 GRE Tunnel 是否成功：
在服务器 A 上：
ping 10.0.0.2
像我这样就是成功了，而且两个服务器之间有着非常优秀的网络质量。
ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=1.79 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=1.80 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=1.89 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=1.83 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=1.77 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=1.88 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=1.68 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=1.87 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=1.81 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=1.92 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=1.71 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=1.77 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=1.99 ms
64 bytes from 10.0.0.2: icmp_seq=14 ttl=64 time=1.71 ms
^C
--- 10.0.0.2 ping statistics ---
14 packets transmitted, 14 received, 0% packet loss, time 13021ms
rtt min/avg/max/mdev = 1.680/1.814/1.987/0.083 ms
最后只要配置 nftables 将流量从服务器 A 的 GRE Tunnel 转发到服务器 B 的 GRE Tunnel 即可。
nano /etc/nftables.conf
#!/usr/sbin/nft -f
flush ruleset
table ip my_proxy_forward {
# 处理入站 DNAT
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
# 将发往 A:32767 的流量转发到 B 的隧道地址 10.0.0.2
tcp dport 32767 dnat to 10.0.0.2
udp dport 32767 dnat to 10.0.0.2
# 将发往 A:26002 的流量转发到 B 的隧道地址 10.0.0.2
tcp dport 26002 dnat to 10.0.0.2
udp dport 26002 dnat to 10.0.0.2
}
# 处理出站 SNAT (Masquerade)
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
# 确保回程流量通过隧道：
# 当流量发往 B 的隧道 IP 时，将源地址改为 A 的隧道 IP (10.0.0.1)
ip daddr 10.0.0.2 oifname "tun-gre" masquerade
}
}
最后启动 nftables 即可
sudo nft -f /etc/nftables.conf
2025-11-19 20:27:50
To prevent my server IP from being blocked by the GFW (Great Firewall), I wanted to ensure that my server is only accessible from outside mainland China. The most effective way to achieve this is by adding firewall rules to block all inbound traffic from Chinese IP addresses.
While iptables with xt_geoip has been a popular choice for years, nftables is the modern replacement in the Linux ecosystem. However, nftables lacks built-in support for GeoIP or MMDB (MaxMind Database) lookups out of the box. To bridge this gap, we need a way to generate nftables-compatible IP sets from a GeoIP database.
In this post, I’ll share a tool I built to automate this process: Auto Update MMDB. It automatically fetches the latest GeoLite2 data, extracts Chinese network ranges, and generates the necessary nftables configuration files.
I created a simple Go utility called auto-update-mmdb. It performs the following tasks:
GeoLite2-Country.mmdb.nftables set files (cn4.nft and cn6.nft).nftables to apply the changes.You can find the source code on GitHub: missuo/auto-update-mmdb.
First, we need to install the tool. You can build it from source using Go:
git clone https://github.com/missuo/auto-update-mmdb.git
cd auto-update-mmdb
go build -o /usr/local/bin/auto-update-mmdb
Once installed, you can run it manually to generate the initial IP sets:
sudo /usr/local/bin/auto-update-mmdb
This will create the following files:
/usr/share/GeoIP/GeoLite2-Country.mmdb/etc/nftables.d/cn4.nft/etc/nftables.d/cn6.nftIP addresses change over time, so it’s important to keep the database updated. We can use a systemd timer to run the update daily.
Create a service file /etc/systemd/system/auto-update-mmdb.service:
[Unit]
Description=Auto Update GeoLite2 MMDB
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/auto-update-mmdb
And a timer file /etc/systemd/system/auto-update-mmdb.timer:
[Unit]
Description=Auto Update GeoLite2 MMDB Daily
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
Enable and start the timer:
sudo systemctl daemon-reload
sudo systemctl enable --now auto-update-mmdb.timer
Now that we have the IP sets ready, we can use them in our nftables configuration.
Edit your /etc/nftables.conf. You need to include the generated files and then reference the sets (@cn4 and @cn6) in your rules.
Here is a complete example that blocks traffic from China on a specific port (e.g., 2333), while allowing other traffic:
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
# Import the generated IP sets
include "/etc/nftables.d/cn4.nft"
include "/etc/nftables.d/cn6.nft"
chain input {
type filter hook input priority 0;
# Allow loopback and established connections
iifname "lo" accept
ct state established,related accept
# Block SSH (port 22) from China
tcp dport 22 ip saddr @cn4 drop
tcp dport 22 ip6 saddr @cn6 drop
# Block China IPs on port 2333 (TCP & UDP)
tcp dport 2333 ip saddr @cn4 drop
udp dport 2333 ip saddr @cn4 drop
tcp dport 2333 ip6 saddr @cn6 drop
udp dport 2333 ip6 saddr @cn6 drop
# Allow everything else by default
accept
}
}
If you want to block all inbound traffic from China, you can simplify the rules:
# Drop all traffic from China
ip saddr @cn4 drop
ip6 saddr @cn6 drop
After modifying the configuration, restart nftables to apply the rules:
sudo systemctl restart nftables
By combining nftables with a simple automation tool, we can effectively manage geolocation-based firewall rules without relying on legacy tools or complex dependencies. This setup ensures your server remains inaccessible from specific regions while keeping the IP database up-to-date automatically.
2025-09-29 16:40:43
IDP 是 International Driver’s Permit 的缩写，也就是我们常说的“国际驾照”。它被全世界范围内的大部分国家认可，也就是说你有了 IDP 就可以在全世界大部分国家租车和开车。然而中国人几乎无法获得 IDP，原因稍后我会说。淘宝上常见的 IAA 严格意义上只不过是一个高级的翻译件而已，并没有什么用，另外请注意大部分的代办 IDP 都是给你办的假的，请不要浪费钱，更不要使用假的 IDP。
存在两种 IDP 的原因是因为存在两种道路交通公约，分别是 1949 年的《日内瓦道路交通公约》和 1968 年的《维也纳道路交通公约》。大部分国家都加入了 1949 年的公约，中国没有加入，中华民国（台湾）加入了。
大部分国家只承认 1949 年的日内瓦公约的 IDP，而 1968 年的维也纳公约的 IDP 认可度比较低，1949 年的 IDP 有效期为一年，而 1968 年的 IDP 有效期为三年。
目前可知的情况是使用 1968 年的 IDP 并不能在日本开车，但是在韩国可以。
If you plan to drive in Japan, you will need an international driver’s license based on the Road Traffic Convention of September 19, 1949 (Geneva Convention).
以上来自 NIPPON RENT A CAR 的官网。
原因其实也很简单，当初中国并没有加入日内瓦道路公约，只有签约国才有资格签发 IDP。而中华民国（台湾）加入了日内瓦道路公约，所以台湾人可以获得 IDP。更有趣的是中华民国（台湾）加入了两个公约，可以任意选择需要有效期更长的 1968 年 IDP 或是有效期一年的 1949 年 IDP。更特别的是台湾驾照在日本租车开车仅需日文翻译件。
中国人获得 IDP 的方式只有去海外，比如之前的去济州岛考韩国驾照换 IDP，现在已经走不通了。又或者在中国驾照换香港驾照，香港驾照再换澳洲驾照，澳洲驾照再换 IDP，现在似乎也已经走不通的。目前可行的是，中国驾照在美国的部分州换美国驾照，再去 AAA 换 IDP（似乎只能签发 1949 年版本），仅需 $20。有些国家对于 IDP 的签发有身份要求，好在 AAA 只是一个协会，并不在乎你是什么身份，另外值得一提的是 NJ 的 MVC 也并不关心你是什么身份，即使是非法移民也拥有同等的获得驾照的权利。
灰色部分是不承认 IDP 的国家和地区。（非洲和南美洲部分地区以及中国大陆不能使用 IDP 开车）
2025-08-02 18:12:17
我的好朋友面条都给我想好了这篇文章的链接，看来是不写不行了。
在整个台湾仅有两家 Apple Store，分别是 Apple Taipei 101 和 Apple Xinyi A13。两家店走路仅需 650 米，大约仅需 9 分钟。前段时间刚好飞到了台北。我的 iPhone 16 Pro 因为进水需要使用 AppleCare One 换机。
第一天我预约了 Apple Xinyi A13 的维修，到店之后小哥服务态度挺不错，表示可以帮我看看能不能处理好。后面他拿进去处理了一下之后告诉我可以充电了，拿了一个充电器给我演示了一下，确实可以充电了。他告诉我，台湾这边比较严格，如果镜头没有明显的起雾，还可以充电一般是不会给换机的。我表示理解，就直接回去了。但是一到酒店发现充了一会开始发热，且自动关机了。我又预约了当日的 Apple Taipei 101，因为 Apple Xinyi A13 当日已经预约满了。
到了 Apple Taipei 101 之后，有一个小哥过来，他看了一眼在 Apple Xinyi A13 的 Case 之后，听完我的描述，直接告知我你的手机必须要返厂，需要寄回新加坡，大概需要等待 7-14 天，无法选择店内维修。且告诉我在台湾这边所有的外版设备都必须要返厂。这个时候我就提出了质疑，我问他是不是没有外版设备在店内换机的先例，他说没有，如果你是台版机子可以直接店内换机，外版不行。而我的好朋友 SteveYi 的机子就是日版在台湾售后直接当场换机。他听完之后给我的解释是，他不知道，他说一切都是系统做的判断，他给我展示他的 iPad 无法选择店内维修。我显然并不认可他的解释。后面这个小哥非常不耐烦，让我跟他的主管谈，后面有一个女主管从里面出来和我聊，女主管也是一样的说辞。她说，你的设备刚好被抽中了，必须要返厂，无法做店内维修，我问她 Apple 的售后系统决定设备怎么维修是抽签买彩票的吗？她解释说只是举个例子。最关键的是，我在 Apple Taipei 101 之后，他们甚至都没有做任何的检测，连我的手机都没有碰一下就要我返厂。而按照 Apple 的规定，任何进水的机子是没有维修的必要，只能换机处理，所以所谓的返厂只不过就是强行让你多等两周而已。后面在我的坚持下，女主管说拿进去看一下试纸有没有变色，她说一般 iPhone 会有两个试纸，一个在内部一个在外部，如果有变色说明已经进水。结果折腾一圈回来跟我说你的设备由于没有卡槽，没有外部试纸，所以内部试纸有没有变色也不确定。然后告知我，刚刚测试过了，现在可以充电了。我让她拿个充电器过来试一下，结果刚插上 10-20 秒，就无法充电了，故障已经在她面前清晰复现。她说她再帮我尝试一下能不能申请换机，然后跟我说还是无法店内维修。最搞笑的是，我刚进店描述的故障，第一个工作人员压根没有写到 Case 里面，导致我跟这个主管，以及后来她从里面喊出来的工程师各自描述了一遍，那个女主管说的最搞笑的一句话是，我没有看到这个故障复现，所以你的手机没有问题。到最后，我选择退让一步，我说可以返厂，但是我需要提供备用机，她表示无法提供备用机。我问，返厂之后后面可以让我的朋友 Pick up 吗，她也表示不行。最后就这么不了了之了。直到我走出 Apple Store 的时候，已经是 22:50 了，已经超出了关门时间 50 分钟，他们宁愿跟我来回扯几个小时的谎言，也不愿意换机。
第二天我又去了 Apple Xinyi A13，过了一晚上 iPhone 已经彻底无法开机，但是我不确定是不是没电了。到了 Apple Store 之后，小哥拿出了 MagSafe 无线充电器让我尝试一下是否可以充电。结果充了十几分钟似乎仍然无法开机，应该是真的彻底坏掉了。因为我前一天就已经来过这家店，小哥去询问他的主管应该如何处理。结果这个中年大叔过来直接跟我说，您的设备在台湾无法提供售后服务，我们已经确认过了确实提供不了。我问他依据是什么，他给我找出了美国的 AppleCare 官网的一句小字，“Service coverage outside the country of purchase of your AppleCare plan is not guaranteed.”，他给我翻译说这句话的意思是 您的设备在台湾无法提供售后服务。我让他逐个单词给我翻译哪里写了在台湾无法售后。他说就是这里这样写了，一直就指着这句话，复读 “您的设备在台湾无法提供售后服务，我们已经确认过了确实提供不了”。后面我让他叫一个别的同事过来，给我翻译一下这句话是什么意思。他喊了他的搭班主管过来，那是一个比较年轻的主管，就直接让他给我去处理换机的申请。并且让员工拿出美版换台版部分功能可能不可用的协议签署。后面我和那个年轻的主管聊了很多，他也没有刁难，后面就花了几分钟就解决问题了。
最搞笑的事情是因为我前一天在 Apple Taipei 101 走之前要求他们给个说法。结果第二天我在 Apple Xinyi A13 完成换机之后，Apple Taipei 101 的主管给我回电了，说已经看到我解决了问题，恭喜我在 A13 完成了换机。我反问她为什么 A13 可以直接店内维修完成换机而你们不行，她说她也不知道，确实无法绕过系统限制。我问她你不是说我的设备被抽中了必须要返厂吗。她说她真的不知道，系统让她只能返厂。后面也懒得跟她废话了，真的是满嘴谎言。
后面我和台湾的朋友说起这件事情，他跟我说 Apple Taipei 101 的服务态度特别差，Apple Xinyi A13 就要好一些。他甚至向 行政院消費者保護會線上申訴系統 提交了投诉。最终 Apple 的工作人员回电表示他们的服务没有任何问题，直接挂断了电话，不接受任何多余的沟通。所以，台湾的 Apple Store 不仅是烂，而且是拿它没什么办法，即使是台湾人都拿它没办法，政府机构根本无法监管。而我认为的 Apple Taipei 101 明明是可以为我提供便利，却因为我不是台湾人，硬是要我多等待两周，而 Apple Xinyi A13 的主管也是一样，明明手机的已经进水变成砖块了，硬是要找官网的那句 Not Guaranteed 来搪塞我。我去过大陆地区上海和杭州的多家 Apple Store，我去过美国的多家 Apple Store，也去过日本东京和京都的多家 Apple Store，我从来没有遇到过 Apple 竟然会提供如此差劲的服务。
There are only two Apple Stores in all of Taiwan: Apple Taipei 101 and Apple Xinyi A13. The two stores are only about a 9-minute, 650-meter walk apart. I happened to be in Taipei recently when my iPhone 16 Pro needed a replacement under AppleCare+ due to water damage.
On the first day, I made an appointment for repair at Apple Xinyi A13. When I arrived, the staff member who assisted me was quite friendly and said he would see what he could do. After taking my phone to the back for a bit, he returned and told me it could now be charged. He demonstrated with a charger, and indeed, it was charging. He explained that regulations in Taiwan are quite strict; if there’s no obvious fogging in the camera lens and the device can still charge, they generally won’t approve a replacement. I understood and left. However, as soon as I got back to my hotel, the phone started overheating while charging and then shut down automatically. I then booked an appointment for the same day at Apple Taipei 101, as Xinyi A13 was fully booked.
Upon arriving at Apple Taipei 101, a male employee approached me. After glancing at the case file from Xinyi A13 and listening to my description, he immediately informed me that my phone had to be sent back to the factory in Singapore for repair, which would take about 7-14 days, and that an in-store repair was not an option. He also claimed that in Taiwan, all devices purchased abroad must be sent back to the factory. At this point, I questioned him, asking if there was truly no precedent for an internationally purchased device being replaced in-store. He said no, stating that if my device were a Taiwanese model, it could be replaced on the spot, but not for an international one. This contradicted the experience of my good friend SteveYi, whose Japanese-model iPhone was replaced directly in-store in Taiwan. When I mentioned this, his explanation was that he didn’t know and that “the system makes all the decisions.” He even showed me his iPad to prove he couldn’t select the in-store repair option. I was obviously not convinced by his explanation. The employee became very impatient and told me to speak with his manager. A female manager then came out to talk to me, and she repeated the same script. She said my device was “randomly selected” to be sent back to the factory and that an in-store repair was impossible. I asked her if Apple’s repair-determination system was like a lottery. She claimed it was just an example. Most importantly, during my entire time at Apple Taipei 101, they didn’t perform a single diagnostic test—they didn’t even touch my phone before demanding I send it to the factory. According to Apple’s own policy, any water-damaged device is not to be repaired, only replaced. Therefore, the so-called “factory repair” was just a tactic to force me to wait an extra two weeks.
After I insisted, the female manager said she would take the phone in to check if the liquid contact indicator had changed color. She explained that iPhones typically have two indicators, one internal and one external. A color change would confirm water damage. After a while, she returned and told me that because my device has no SIM card slot, it lacks an external indicator, so they couldn’t be sure if the internal one had been triggered. She then announced, “We just tested it, and it can be charged now.” I asked her to bring a charger to test it. Sure enough, just 10-20 seconds after plugging it in, it stopped charging. The malfunction had clearly reproduced right in front of her. She said she would try again to apply for a replacement but came back saying an in-store repair was still not possible. The most ridiculous part was that the first employee hadn’t even documented the malfunction I initially described in the case file, forcing me to repeat the story to the manager and later to an engineer she called from the back. The manager’s most absurd statement was, “I did not see the malfunction reproduce, so there is no problem with your phone.”
In the end, I decided to compromise. I said I could agree to the factory shipment, but I would need a loaner phone. She refused, stating they couldn’t provide one. I asked if a friend could pick up the phone for me after the repair. She refused that as well. The situation ended in a stalemate. By the time I walked out of the Apple Store, it was 10:50 PM, 50 minutes past their closing time. They would rather spend hours telling me lies than replace my device.
The next day, I went back to Apple Xinyi A13. Overnight, my iPhone had completely died and wouldn’t turn on, though I wasn’t sure if it was just out of battery. At the store, the staff member gave me a MagSafe charger to see if it would charge wirelessly. After more than ten minutes, it still wouldn’t turn on; it was truly dead. Since I had been there the day before, the employee went to ask his manager how to proceed. A middle-aged man came over and told me directly, “We cannot provide after-sales service for your device in Taiwan. We have already confirmed this.” I asked him for the basis of this claim. He pulled up the US AppleCare website on his device and pointed to a line of fine print: “Service coverage may be restricted to the country of purchase.” He translated this for me as, “Your device cannot be serviced in Taiwan.” I asked him to translate, word for word, where it said it couldn’t be serviced in Taiwan. He just kept pointing at the sentence and repeating, “It says right here that we cannot provide service for your device in Taiwan. We have confirmed this.” I then asked him to get another colleague to translate the sentence for me. He called over his fellow manager, a younger man, who immediately proceeded to process the replacement for me. He had an employee bring out a waiver to sign, acknowledging that a US-model replacement might have different features than a Taiwanese one. I had a long chat with the younger manager, who was reasonable and didn’t give me any trouble. The whole issue was resolved in just a few minutes.
The most laughable part came later. Because I had demanded an explanation before leaving Apple Taipei 101 the previous night, their manager called me back the next day after I had already completed the replacement at Xinyi A13. She said she saw that my issue had been resolved and congratulated me on getting the replacement at A13. I asked her why A13 could do an in-store replacement when they couldn’t. She claimed she didn’t know and that she really couldn’t bypass the system’s restrictions. I asked, “Didn’t you say my device was ‘randomly selected’ and had to be sent to the factory?” She just kept saying she truly didn’t know and that the system forced her to choose the factory option. I couldn’t be bothered to argue with her anymore; her words were just a stream of lies.
Later, I told a Taiwanese friend about this. He said that the service at Apple Taipei 101 is notoriously bad, while Apple Xinyi A13 is much better. He had even filed a complaint with the Consumer Protection Committee of the Executive Yuan. In the end, an Apple representative called him back, stated that their service was flawless, and promptly hung up, refusing any further discussion. So, the Apple Stores in Taiwan aren’t just bad; you’re powerless against them. Even local Taiwanese people can’t do anything about it, as government agencies seem unable to regulate them. It’s my belief that Apple Taipei 101 could have easily helped me but deliberately tried to make me wait two weeks simply because I wasn’t Taiwanese. The manager at Apple Xinyi A13 was just as bad, trying to use the “not guaranteed” clause to brush me off even when my phone was a water-damaged brick. I have been to many Apple Stores in mainland China, in cities like Shanghai and Hangzhou, in the United States, and in Tokyo and Kyoto in Japan. I have never encountered such shockingly poor service from Apple.
