Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: : download from https://tiup-mirrors.pingcap.com/timestamp.json failed:
[TiDB Usage Environment] Testing
[TiDB Version] v6.5.0
[Reproduction Path]
curl --proto ‘=https’ --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
[Encountered Problem: Phenomenon and Impact]
Execution:
curl --proto ‘=https’ --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
Then execute
tiup playground v6.5.0 --db 2 --pd 3 --kv 3 --host 192.168.197.130
[Resource Configuration] centos7
[Attachment: Screenshot/Log/Monitoring]
Successfully set mirror to https://tiup-mirrors.pingcap.com
Detected shell: bash
Shell profile: /root/.bash_profile
Installed path: /root/.tiup/bin/tiup
Have a try: tiup playground
[root@c7-node-1 tidb]# source /root/.bash_profile
[root@c7-node-1 tidb]# source /root/.bash_profile
[root@c7-node-1 tidb]# tiup playground v6.5.0 --db 2 --pd 3 --kv 3 --host 192.168.197.130
tiup is checking updates for component playground …timeout!
The component playground
version is not installed; downloading from repository.
Error: fetch /timestamp.json from mirror(https://tiup-mirrors.pingcap.com) failed: download from https://tiup-mirrors.pingcap.com/timestamp.json failed: Get “https://tiup-mirrors.pingcap.com/timestamp.json”: dial tcp: lookup tiup-mirrors.pingcap.com on 192.168.197.2:53: no such host
Tried the following methods, but the problem still cannot be resolved:
Change the command window to a directory other than .tiup, then re-execute the installation command. This command will not corrupt data. curl --proto ‘=https’ --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version]
[Reproduction Path] What operations were performed when the issue occurred
[Encountered Issues: Issue Symptoms and Impact]
[Resource Configuration]
[Attachments: Screenshots / Logs / Monitoring]
Please fill in the content according to the template.
Refer to this to troubleshoot the issue.
Before posting, I had already referred to the official TiDB guidance and finally resolved the issue. The solution is as follows: navigate to the home directory (in my case, /home/tidb), and then execute curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
. In other words, reinstalling tiup outside of the .tiup directory can solve the problem.
The issue is still not resolved.
How to solve this problem?
Can the server where tiup is located access this address?
What are these two IPs? Playground should just start a TiDB cluster locally for development purposes. If this IP is not the IP of the machine where tiup is located, there might be an issue. Try removing this parameter and see if it can start.
It is not caused by the IP.
What is the 197.2 IP in this error? Could you explain it? 
At least from my side, it looks fine:
I’m not very sure about this either, it’s in my virtual machine.
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.244.0.1 netmask 255.255.255.0 broadcast 10.244.0.255
inet6 fe80::7865:f3ff:fe36:637a prefixlen 64 scopeid 0x20
ether 7a:65:f3:36:63:7a txqueuelen 1000 (Ethernet)
RX packets 1121599 bytes 204651832 (195.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1110206 bytes 145116114 (138.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:db:b5:15:57 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.197.130 netmask 255.255.255.0 broadcast 192.168.197.255
inet6 fe80::20c:29ff:fe31:88da prefixlen 64 scopeid 0x20
ether 00:0c:29:31:88:da txqueuelen 1000 (Ethernet)
Really can’t find the problem
Does this operating system version meet the requirements?
Switching to 6.1.0 doesn’t work either.
It’s indeed absurd, can’t think of any reason 
Maybe check the /etc/hosts configuration.
Change DNS to 223.5.5.5 and 223.6.6.6 in /etc/resolv.conf