Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Other Aqua Proxy: Fix connection issues on OS X 10.6 – 10.9.
- Thread starter Wowfunhappy
- Start date
-
- Tags
- networking software
- Sort by reaction score
DurltazorOSXPower
macrumors member
@Wowfunhappy good afternoon man, i try recopile your aquaproxy from i386, but this missing dylib
insert_dylib --inplace libWowfunhappyLegacySupport.dylib Aqua-HTTP-Proxy
insert_dylib --inplace libMacportsLegacySupport.dylib Aqua-HTTP-Proxy
insert_dylib --inplace libWowfunhappyLegacySupport.dylib Aqua-IMAP-Proxy
insert_dylib --inplace libMacportsLegacySupport.dylib Aqua-IMAP-Proxy
please, you can receive me ?
insert_dylib --inplace libWowfunhappyLegacySupport.dylib Aqua-HTTP-Proxy
insert_dylib --inplace libMacportsLegacySupport.dylib Aqua-HTTP-Proxy
insert_dylib --inplace libWowfunhappyLegacySupport.dylib Aqua-IMAP-Proxy
insert_dylib --inplace libMacportsLegacySupport.dylib Aqua-IMAP-Proxy
please, you can receive me ?
libMacportsLegacySupport.dylib comes from the MacPorts project. Make sure to compile for 32 bit.
libWowfunhappyLegacySupport.dylib is a dylib containing this, but it shouldn't be necessary with the older version of Go already necessitated for 32 bit support.
I will get to this myself at some point, but "at some point" might be next summer.
DurltazorOSXPower
macrumors member
maverick28
macrumors 6502a
Wikipedia stopped delivering the content.
Code:
10/01/26 23:21:17,060 com.apple.lookupd[3604]: CFNetwork SSLHandshake failed (-9824)
10/01/26 23:21:39,227 com.apple.lookupd[3604]: CFNetwork SSLHandshake failed (-9824)
10/01/26 23:24:48,568 com.apple.lookupd[3604]: CFNetwork SSLHandshake failed (-9824)
10/01/26 23:35:11,543 com.apple.lookupd[3604]: CFNetwork SSLHandshake failed (-9824)maverick28
macrumors 6502a
FYI, someone named nilFinx has created a fork of Aqua Proxy with additional features, which he calls LiquidProxy. I haven't used it myself and I don't understand everything he added, but I can tell that his goal is to make it feasible to run LiquidProxy on one device and then access it from a different device. So, you could run LiquidProxy on a Linux box and then access it from an ancient iOS device, or a PowerPC Mac.
github.com
I still recommend Aqua Proxy for the simple case, where you have a Mac running OS X 10.6 – 10.9 and you want to just install a package that will make HTTPS issues go away.
GitHub - nilFinx/LiquidProxy: An improved AquaProxy fork for servers with better experience
An improved AquaProxy fork for servers with better experience - nilFinx/LiquidProxy
github.com
I still recommend Aqua Proxy for the simple case, where you have a Mac running OS X 10.6 – 10.9 and you want to just install a package that will make HTTPS issues go away.
There is a webpage for that at https://recycledplist.space/projects/liquidproxy/
The other main new thing I see is "genericTCP" proxy which allows you to mitm protocols that normally don't support proxy, by basically hardcoding incoming port to outgoing domain/port mappings.
The other main new thing I see is "genericTCP" proxy which allows you to mitm protocols that normally don't support proxy, by basically hardcoding incoming port to outgoing domain/port mappings.
iPodNano3
macrumors regular
since approximately yesterday, wikipedia's api has been blocking requests (403) with AppleDictionaryService in the user agent header. as a result, wikipedia results no longer show up in dictionary. removing/changing the user agent fixes this issue. is this change possible in aquaproxy?
Code:
GET /w/api.php?action=opensearch&search=apple&limit=1 HTTP/1.1
Host: en.wikipedia.org
User-Agent: AppleDictionaryService/208
Connection: close
Proxy-Connection: close
Pragma: no-cache
Cache-Control: no-cache
Code:
Unauthorized request. Please contact bot-traffic@wikimedia.org to request unblocking. Reference: 80be951.Thanks.
It's definitely something I can update AquaProxy to allow for (I'm on a break next week and will have a bit of time for this), but before we start fighting Wikipedia, I wonder if you could try reaching out to bot-traffic@wikimedia.org? Say that you're using an old copy of Apple's Dictionary app and are getting this message from their API.
maverick28
macrumors 6502a
To insert my two cents, content loading has been screwed in Mojave's Wiki-Dictionary, too. It displays an article's textual body; however, it falters on pictures. The defect manifests regularly, although the pictures suffer in random order. When the failures occur, Charles shows these connections as dropped ones. Additionally, the Response HTML view contains the following message, which suggests it be reported to "a Web Admin":
For some reason, media resource requests are now categorised as intrusive. This reason could be the echo of the advanced warning from the Wikipedia authorities that I received several days ago as a registered member (not a dev). Here it is:
Currently, the form of the request's headers is
HTML:
Request served via cp3078 cp3078,
Varnish XID 57298864
Upstream caches: cp3078
intError: 429, Too many requests (76af2b0) at Sat, 14 Mar 2026 11:56:32 GMT
Sensitive client information
IP address: 95.101.60.87For some reason, media resource requests are now categorised as intrusive. This reason could be the echo of the advanced warning from the Wikipedia authorities that I received several days ago as a registered member (not a dev). Here it is:
As previously announced, we have started rolling out new global API rate limits across our APIs to help ensure fair and sustainable access to Wikimedia resources.
We have just enabled the first set of limits, which apply to anonymous requests from bots and unauthenticated requests from web browsers. See the documentation on mediawiki.org for more information. This has now been updated with actual limits for anonymous requests and authenticated bot requests that do not come from WMCS. We are still finalizing the initial limits for User-Agent only (e.g. InstantCommons) and authenticated browser requests.
As a next step, rate limits for logged in users will follow in early April. The concrete limits will be communicated beforehand. Access for clients running in WMCS and accounts that have a bot flag will not be affected by this change. However, all developers are advised to familiarize themselves with the new limits and follow the best practices outlined in the documentation.
We have just enabled the first set of limits, which apply to anonymous requests from bots and unauthenticated requests from web browsers. See the documentation on mediawiki.org for more information. This has now been updated with actual limits for anonymous requests and authenticated bot requests that do not come from WMCS. We are still finalizing the initial limits for User-Agent only (e.g. InstantCommons) and authenticated browser requests.
As a next step, rate limits for logged in users will follow in early April. The concrete limits will be communicated beforehand. Access for clients running in WMCS and accounts that have a bot flag will not be affected by this change. However, all developers are advised to familiarize themselves with the new limits and follow the best practices outlined in the documentation.
Currently, the form of the request's headers is
| GET /upload.wikimedia.org/wikipedia/commons/thumb/1/1c/Germanic_%E2%80%93_Romance_language_border_map_%28early_Middle_Ages_%E2%80%93_early_twentieth_century%29.svg/500px-Germanic_%E2%80%93_Romance_language_border_map_%28early_Middle_Ages_%E2%80%93_early_twentieth_century%29.svg.png HTTP/1.1 | |
| Host | lookup-api.apple.com |
| Accept | image/png,image/svg+xml,image/*;q=0.8,video/*;q=0.8,*/*;q=0.5 |
| Accept-Language | en-us |
| Connection | keep-alive |
| Accept-Encoding | br, gzip, deflate |
| User-Agent | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) AppleDictionaryApplication/203.16.12 |
Last edited:
iPodNano3
macrumors regular
try setting a Referer header to http://localhost/. for some reason i found that this bypasses the restrictions. no clue why this works.
@iPodNano3 Just wondering if you ever reached out to that Wikipedia email? As I said I'd very much like to not fight them; I'd like to know what they want us to do.
Last edited:
maverick28
macrumors 6502a
You mean adding a new header named "Referer"? If you do, then what does its exact form need to be? Is it a request or a response header?
I sent a letter three days ago. No response, as of now.
Last edited:
maverick28
macrumors 6502a
OK, I figured out how, but adding "Referer" didn't help. It actually rendered all images blank (this is Mojave, not Mavericks).
So far, fails in Mavericks too. The latter was hit harder. It won't load articles at all.
macOS makes two requests to fetch Wiki data. One is to the host "lookup-api...", the other "en.wikipedia.org". Yours seems to store a different structure. The headers are swapped places, and so are the methods: speaking of "en.wikipedia.org", your GET is my CONNECT. Some headers are absent with me (Pragma, Cache-Control). It's messy.
So far, fails in Mavericks too. The latter was hit harder. It won't load articles at all.
macOS makes two requests to fetch Wiki data. One is to the host "lookup-api...", the other "en.wikipedia.org". Yours seems to store a different structure. The headers are swapped places, and so are the methods: speaking of "en.wikipedia.org", your GET is my CONNECT. Some headers are absent with me (Pragma, Cache-Control). It's messy.
Last edited:
iPodNano3
macrumors regular
from what i can see, you don't have ssl proxying enabled with wikipedia. right click on the host name https://en.wikipedia.org and enable ssl proxying. to clarify, the header needs to be added to the wikipedia request, lookup-api is just a server in the middle to give dictionary the wikipedia url and doesn't care about headers.
import the attached rewrite set into charles proxy, and it should do it for you as long as you have ssl proxying with maps.wikimedia.org, upload.wikimedia.org, and *.wikipedia.org.
Last edited:
maverick28
macrumors 6502a
Thank you, your rewrite rules were a success. The misunderstanding arose because your suggestion was incomplete; it did not mention the other hosts and header.
maverick28
macrumors 6502a
And, continuing the subject of communication with the Wikipedia team, I received a response. However, it didn't bring anything that would open the road to new opportunities: it was a blank confirmation that they imposed a rate limit on clients' user agents to combat bot activity.
This was probably why unsetting the user agent string worked.
The error you're seeing is due to our rate-limiting on media requests. We need to ensure media files are available to everyone, which limits the ceiling of access we can provide generally to individual user agents. To protect the availability of our image serving infrastructure, we're rate-limiting access to media resources on a per-client basis.
Please review our user-agent policy (https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_User-Agent_Policy) that should allow for a higher number of requests if your client adheres to the described guidelines.
Please review our user-agent policy (https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_User-Agent_Policy) that should allow for a higher number of requests if your client adheres to the described guidelines.
This was probably why unsetting the user agent string worked.
I actually think that’s helpful! So we should make Aqua Proxy send a user agent like "Apple Dictionary via Aqua Proxy”. No spoofing or trickery, just updating to follow their policies as requested.
maverick28
macrumors 6502a
Lion's Wikipedia won't load images (none whatsoever) even with the rewrite rules applied. Text is OK.
dictionary should be following the 301 redirect. Does it try to fetch that redirected resource?
iPodNano3
macrumors regular
thats weird. i can see it says Complete in the request to upload.wikimedia.org. do you have ssl proxying with that host enabled? does it just display the blue square with a question mark in dictionary?
maverick28
macrumors 6502a
Yes, upload.wikimedia.org is SSL-proxied. The 301 request's cURL is
I searched for another entry and got a mixture of good and bad requests (including "too many requests"):
Bash:
curl -H "Host: upload.wikimedia.org" -H "User-Agent: " -H "Proxy-Connection: close" -H "Referer: http://localhost/" http://upload.wikimedia.org/wikipedia/commons/thumb/2/25/Maximilian_gA_1497.jpg/250px-Maximilian_gA_1497.jpgI searched for another entry and got a mixture of good and bad requests (including "too many requests"):
iPodNano3
macrumors regular
hmm, too many requests should be bypassed if the referer header is present. are you sure its on the requests?