All workflows

Showing runs from all workflows

234 workflow runs

Check Xray-core updates
completed successfully:
check xray-core#113:Scheduled
main
Nov 15, 202614s
Check Xray-core updates
completed successfully:
check xray-core#112:Scheduled
main
Nov 14, 202613s
Check Xray-core updates
completed successfully:
check xray-core#111:Scheduled
main
Nov 13, 202627s
Check Xray-core updates
completed successfully:
check xray-core#110:Scheduled
main
Nov 12, 202620s
Check Xray-core updates
completed successfully:
check xray-core#109:Scheduled
main
Nov 11, 202614s
Check Xray-core updates
completed successfully:
check xray-core#108:Scheduled
main
Nov 10, 202614s
Check Xray-core updates
completed successfully:
check xray-core#107:Scheduled
main
Nov 9, 202617s
Check Xray-core updates
completed successfully:
check xray-core#106:Scheduled
main
Nov 8, 202613s
Check Xray-core updates
completed successfully:
check xray-core#105:Scheduled
main
Nov 7, 202612s
Check Xray-core updates
completed successfully:
check xray-core#104:Scheduled
main
Nov 6, 202614s
Check Xray-core updates
completed successfully:
check xray-core#103:Scheduled
main
Nov 5, 202619s
v1.0.99: Keep the local NRPT container after removing our rule; 1.0.99 On Windows 10 (dnsclientpsprovider 10.0.19041) Remove-DnsClientNrptRule deletes the whole DnsPolicyConfig key together with the last rule. OpenVPN 3 only opens that key and never creates it, so the next OpenVPN connection after ToBeVPN disconnected failed with "cannot open NRPT base key" and lost its corporate DNS rule (RDP gateway by name). The apply and restore DNS scripts now recreate the empty local container when it is gone (al...
completed successfully:
build#177:Commita4c1f86pushedbyShoolife
v1.0.99
Nov 4, 202618m 52s
Check Xray-core updates
completed successfully:
check xray-core#102:Scheduled
main
Nov 4, 202615s
Check Xray-core updates
completed successfully:
check xray-core#101:Scheduled
main
Nov 3, 202613s
Check Xray-core updates
completed successfully:
check xray-core#100:Scheduled
main
Nov 2, 202616s
v1.0.98: Xray core 26.10.31 Xray-core withdrew v26.10.29 (the release and its tag are gone, so the sidecar download returned 404) in favour of v26.10.31, an urgent security update that turns MPTCP off by default. Pins and What's new updated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
completed successfully:
build#176:Commit1006b83pushedbyShoolife
v1.0.98
Nov 2, 202615m 25s
v1.0.98: One request at a time: primary first, fallback only after it fails As on Android, the bot API reads and the subscription requests no longer run primary and fallback in parallel after 400 ms. The primary gets 1.2 s; the fallback is sent only after it failed, timed out or answered 403 (or, for endpoints that need the data, any non-2xx), so the network never carries both requests at once. The fallback-first cooldown and the write rules are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthr...
failed:
build#175:Commit427a2edpushedbyShoolife
v1.0.98
Nov 2, 20264m 25s
v1.0.98: API fallback for sign-in; What's new and 1.0.98 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
cancelled:
build#174:Commitd5481dapushedbyShoolife
v1.0.98
Nov 2, 20262m 15s
PR #9: Фикс работы с фолбеком api
failed:
build#173:Pull request#9synchronizebyShoolife
fix-fallback-api
Nov 2, 20264m 24s
PR #9: Фикс работы с фолбеком api
failed:
build#172:Pull request#9openedbyzchk0
fix-fallback-api
Nov 2, 20264m 19s
Check Xray-core updates
completed successfully:
check xray-core#99:Scheduled
main
Nov 1, 202613s
Check Xray-core updates
completed successfully:
check xray-core#98:Scheduled
main
Oct 31, 202611s
v1.0.97: Random fallback extension, no needless fallback requests, admin privacy switch; 1.0.97 - Fallback subscription URL: {ext} in FALLBACK_SUBS_DOMAIN becomes one random extension per built fallback request (txt json css js html xml svg png jpg woff2, never php); templates without {ext} are unchanged - The hedged fallback is no longer sent when the primary answers within 400 ms, and an in-flight fallback is aborted once the primary wins; a failed primary still starts the fallback at once - A...
completed successfully:
build#171:Commit79bed1dpushedbyShoolife
v1.0.97
Oct 31, 202614m 56s
v1.0.96: Fallback subscription sends x-device-ref instead of x-hwid; 1.0.96 The fallback CDN answers 403 to a UUID in x-hwid. Every request to the fallback URL now goes through fallbackFetch, which drops x-hwid and sends the same id as x-device-ref: u1.<32 hex> (dashes removed, case kept); the fallback proxy restores x-hwid for Remnawave. Primary requests, including a primary retry after a failed fallback, keep x-hwid. A device id that is not a UUID never reaches the fallback, anonymously or replaced. ...
completed successfully:
build#170:Commit32e5793pushedbyShoolife
v1.0.96
Oct 31, 202618m 0s
v1.0.95: What's new 1.0.95: drop the new backup subscription item The CDN fallback rejects requests carrying the device's x-hwid with 403, so 1.0.95 keeps the previous fallback address. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
completed successfully:
build#169:Commitf0e3f9apushedbyShoolife
v1.0.95
Oct 31, 20269m 7s