Skip to content

Request headers (client → server)

Every subscription fetch carries these headers, so a panel can identify the device and bind a subscription to it (a routing-profile download carries only the User-Agent; geo-database downloads carry none):

Header Value
X-Hwid Stable device id. Computed once on first launch and never changes afterwards — not on app updates and not on reinstall. Shown in the app’s About screen; it is what addhw links compare against. Each client app has its own HWID scheme, so a device bound in another client is a different HWID for the panel.
X-Device-Os Android · iOS · macOS · tvOS · Windows · Linux
X-Ver-Os OS version string — e.g. 16, 18.6, 10.0.26200
X-Device-Model Device model — e.g. SM-S942B, iPhone16,2, PC
X-Device-Locale ru_RU etc. — device language and region
X-App-Version 2.0.5 (422) — marketing version + build in one string
X-App-Build 422 — build number alone — the value to gate on (Android 423+, Apple 313+, desktop 199+; older builds send only X-App-Version and the User-Agent)
User-Agent SMProxy/<version>/<build>-<OS> — e.g. SMProxy/2.0.5/422-Android. Use it when you want to serve different content to different builds

All header names are case-insensitive.

User-Agent — one format on every platform

SMProxy/<marketing version>/<build>-<OS>
Platform Example
Android SMProxy/2.0.5/422-Android
iOS / iPadOS SMProxy/2.0.9/312-iOS
macOS SMProxy/2.0.9/312-macOS
tvOS SMProxy/2.0.9/312-tvOS
Windows SMProxy/2.0.2/198-Windows
Linux SMProxy/2.0.2/198-Linux

It is sent on every subscription fetch and whenever a routing profile is downloaded by URL. The build number is what you gate on — the third segment grows on every release and never repeats, while the marketing version can stay the same across several builds. A panel that serves different content to different builds should parse it like this:

^SMProxy/[^/]+/(\d+)-(Android|iOS|macOS|tvOS|Windows|Linux)$