deepseek-ai/awesome-deepseek-agent
1
0
Fork 0
mirror of https://github.com/deepseek-ai/awesome-deepseek-agent.git synced 2026-11-05 01:07:37 +00:00
Code Issues 354 Projects Packages Wiki Activity

[GH-ISSUE #311] [docs] deepseek-tui: China endpoint api.deepseeki.com is a non-existent domain (typo) #106

New issue
Open
opened 2026-10-26 09:45:31 +00:00 by bsakaguchi · 3 comments
bsakaguchi commented 2026-10-26 09:45:31 +00:00
Owner
Copy link

Originally created by @axiaoge2 on GitHub (Jul 22, 2026).
Original GitHub issue: https://github.com/deepseek-ai/awesome-deepseek-agent/issues/311

Problem / 问题

In docs/deepseek-tui.md (line 71) and docs/deepseek-tui.zh-CN.md (line 71), the DEEPSEEK_BASE_URL row tells users to use
https://api.deepseeki.com for the "China endpoint":

| DEEPSEEK_BASE_URL | API base URL — defaults to https://api.deepseek.com; use https://api.deepseeki.com for the China
endpoint |

This is wrong on two counts:

  1. api.deepseeki.com is a typo (extra i) and the domain does not resolve: 
    $ nslookup api.deepseeki.com
*** Non-existent domain
$ nslookup api.deepseek.com
Addresses: 36.159.70.231, 120.226.37.16   # resolves fine
  2. DeepSeek has no separate "China endpoint." The official API base URL is only https://api.deepseek.com.

Impact / 影响

Any user who sets DEEPSEEK_BASE_URL=https://api.deepseeki.com as instructed will get DNS/connection failures on every
API request — the tool cannot reach DeepSeek at all.

Suggested fix / 修复建议

Remove the misleading "China endpoint" clause entirely (or, if a China-region URL genuinely exists, replace it with the
correct one). The row should simply read:

| DEEPSEEK_BASE_URL | API base URL — defaults to https://api.deepseek.com |

Both the English and zh-CN files need the same fix.

Originally created by @axiaoge2 on GitHub (Jul 22, 2026). Original GitHub issue: https://github.com/deepseek-ai/awesome-deepseek-agent/issues/311 ## Problem / 问题 In `docs/deepseek-tui.md` (line 71) and `docs/deepseek-tui.zh-CN.md` (line 71), the `DEEPSEEK_BASE_URL` row tells users to use `https://api.deepseeki.com` for the "China endpoint": > | `DEEPSEEK_BASE_URL` | API base URL — defaults to `https://api.deepseek.com`; use `https://api.deepseeki.com` for the China endpoint | This is wrong on two counts: 1. **`api.deepseeki.com` is a typo** (extra `i`) and the domain does not resolve: ``` $ nslookup api.deepseeki.com *** Non-existent domain $ nslookup api.deepseek.com Addresses: 36.159.70.231, 120.226.37.16 # resolves fine ``` 2. **DeepSeek has no separate "China endpoint."** The official API base URL is only `https://api.deepseek.com`. ## Impact / 影响 Any user who sets `DEEPSEEK_BASE_URL=https://api.deepseeki.com` as instructed will get DNS/connection failures on **every** API request — the tool cannot reach DeepSeek at all. ## Suggested fix / 修复建议 Remove the misleading "China endpoint" clause entirely (or, if a China-region URL genuinely exists, replace it with the correct one). The row should simply read: > | `DEEPSEEK_BASE_URL` | API base URL — defaults to `https://api.deepseek.com` | Both the English and zh-CN files need the same fix. ---
bsakaguchi commented 2026-10-26 09:45:32 +00:00
Author
Owner
Copy link

@nightcityblade commented on GitHub (Jul 22, 2026):

Hi, I'd like to work on this. I'll submit a PR shortly.

<!-- gh-comment-id:5048132247 --> @nightcityblade commented on GitHub (Jul 22, 2026): Hi, I'd like to work on this. I'll submit a PR shortly.
bsakaguchi commented 2026-10-26 09:45:32 +00:00
Author
Owner
Copy link

@asswgksb-commits commented on GitHub (Jul 29, 2026):

‏سلام عليكم

<!-- gh-comment-id:5117579369 --> @asswgksb-commits commented on GitHub (Jul 29, 2026): ‏سلام عليكم
bsakaguchi commented 2026-10-26 09:45:32 +00:00
Author
Owner
Copy link

@jdstark4 commented on GitHub (Aug 23, 2026):

Adding a registration detail that I think raises the priority here.

The issue body reads api.deepseeki.com as a non-existent domain, which scopes the impact to connection failures. That holds for the api. subdomain, but the parent domain is registered and live:

$ dig +short deepseeki.com A
34.42.184.201
$ dig +short api.deepseeki.com A
(no A record)

whois deepseeki.com: GoDaddy, Creation Date 2025-01-27, expiry 2027-01-27, NS05/NS06.DOMAINCONTROL.COM.

So this isn't a permanently dead hostname — it's a third-party-owned domain currently one A record away from resolving. The row sits directly below DEEPSEEK_API_KEY, so anyone who followed the instruction has DEEPSEEK_BASE_URL pointing at a domain they don't control with a live API key in the adjacent variable. Today that fails closed. If the owner points api at a host, it fails open, silently, for every config still carrying it.

The registration date is 2025-01-27, one week after the R1 launch.

This doesn't change the proposed fix — remove the clause — but it argues for doing it sooner, and for adding a line telling anyone who already set the variable to unset it. For what it's worth, CodeWhale's own source describes the host as a "Legacy typo hostname ... recognized ... for backward compatibility" (crates/tui/src/config/models.rs), though docs/REBRAND.md still lists it as a "China fallback".

Verified as of 2026-08-23.

<!-- gh-comment-id:5387179584 --> @jdstark4 commented on GitHub (Aug 23, 2026): Adding a registration detail that I think raises the priority here. The issue body reads `api.deepseeki.com` as a non-existent domain, which scopes the impact to connection failures. That holds for the `api.` subdomain, but the parent domain is registered and live: ``` $ dig +short deepseeki.com A 34.42.184.201 $ dig +short api.deepseeki.com A (no A record) ``` whois `deepseeki.com`: GoDaddy, Creation Date 2025-01-27, expiry 2027-01-27, NS05/NS06.DOMAINCONTROL.COM. So this isn't a permanently dead hostname — it's a third-party-owned domain currently one A record away from resolving. The row sits directly below `DEEPSEEK_API_KEY`, so anyone who followed the instruction has `DEEPSEEK_BASE_URL` pointing at a domain they don't control with a live API key in the adjacent variable. Today that fails closed. If the owner points `api` at a host, it fails open, silently, for every config still carrying it. The registration date is 2025-01-27, one week after the R1 launch. This doesn't change the proposed fix — remove the clause — but it argues for doing it sooner, and for adding a line telling anyone who already set the variable to unset it. For what it's worth, CodeWhale's own source describes the host as a "Legacy typo hostname ... recognized ... for backward compatibility" (`crates/tui/src/config/models.rs`), though `docs/REBRAND.md` still lists it as a "China fallback". Verified as of 2026-08-23.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
pull-request
Mirrored from GitHub Pull Request

No labels
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/awesome-deepseek-agent#106
No description provided.